Execution plane / Tier 2 / 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.
- 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
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
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
Architectural recommendation, not a research finding.
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
- 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
Tool and standards snapshot · last reviewed approximately mid-2026
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.