Execution plane / Phase 2
Tool, Skill & Sandbox
What can the system actually do?
The action surface: typed tool contracts, packaged skills, an explicit read-versus-write authority model, and isolation strong enough for code the model wrote.
Use this harness in my journey →- Tool contracts with typed inputs, outputs and error semantics
- Skills as packaged, versioned capability (SKILL.md and equivalents)
- Read-versus-write authority classification for every tool
- Sandboxing for generated code and untrusted execution
- Idempotency, dry-run and rollback for side-effecting tools
- Tool catalogue, ownership and deprecation
Accountable owner
AI Engineering, with Security Engineering co-signing write authority
- Head of AI Engineering — accountable owner
- Tool platform engineer — contracts, catalogue, versioning
- Application security engineer — sandbox posture and review
- SRE — blast radius, rate limits, rollback
- Business system owner — approves write access to their system
Ownership and phase are architectural recommendations, not assessed results.
invoked by the orchestrator
write actions require the approval gate
transported over MCP and A2A
classical models called as tools
identity, scoping and supply-chain controls
isolation primitives from the platform
tool spans and error telemetry
Ship read-only tools in the pilot. Every write tool should arrive with an approval path, an idempotency key and a rollback story — no exceptions in phase 2.
Signals to watch
- Tool error and timeout rate by tool
- Share of write tools behind an approval gate (target 100%)
- Blocked unsigned or unscanned tool loads
- Sandbox escape attempts detected
- Rollback success rate for reversed actions
Tool manifests and implementations can improve in isolation. Preserve least privilege, idempotency, containment and verified external outcomes.
How governed change crosses the architecture ↗Failure modes
- Excessive agency: broad write scopes granted for convenience
- Supply-chain risk in third-party skills — one audit found roughly 36% flawed and 76 outright malicious
- Sandbox escape, or no sandbox at all for generated code
- Side effects repeated on retry because idempotency was never designed in
- Tool descriptions themselves acting as an injection vector
Existing tool and standards snapshot · approximately mid-2026. Examples, not required dependencies; verify current versions before adoption.
Open source
- Firecracker microVMs (roughly 125–150 ms start)
- gVisor
- Kata Containers
- WebAssembly runtimes such as Wasmtime (under 5 ms start, weaker native library support)
- E2B or Daytona sandboxes
- Agent Skills (SKILL.md)
- JSON Schema for tool contracts
Managed
- Managed code-interpreter sandboxes
- Vendor tool catalogues and connector suites
Standards
- MCP tool definitions
- Agent Skills open standard
- Default-deny egress, ephemeral filesystem, no host secrets in the sandbox
Sandbox choice is a real trade-off: microVMs give the strongest isolation at around 125–150 ms of start latency, WebAssembly starts in under 5 ms but constrains native libraries. Pick per tool class, not once for the platform.