Reference architecture

Secure Tool Execution

An execution boundary for untrusted model proposals, typed validation, authorization, credentials, sandboxing, egress, approvals, and verification.

18 minVerified 2026-07-214 primary sources
A governed production AI reference architecture with observable, secured service boundaries.

Architecture

An execution boundary for untrusted model proposals, typed validation, authorization, credentials, sandboxing, egress, approvals, and verification.

Intent and policy
Validated request
Controlled execution
Independent verification
Telemetry and response
Conceptual teaching model synthesized from:OWASP Top 10 for LLM ApplicationsModel Context Protocol Architecture and Tools SpecificationOAuth 2.0 Security Best Current PracticeZero Trust Architecture

The architecture separates intent, policy, state, execution, evidence, and response. Each boundary has one accountable owner and an observable contract. Probabilistic components may propose or classify; deterministic software owns permissions, budgets, state transitions, and release conditions.

Architecture claim
Representative test
Production signal
Decision gate
Review or rollback
Conceptual teaching model synthesized from:OWASP Top 10 for LLM ApplicationsModel Context Protocol Architecture and Tools SpecificationOAuth 2.0 Security Best Current PracticeZero Trust Architecture

Decisions

| Decision | Required evidence | Review trigger | |---|---|---| | Treat model output and tool output as untrusted at different boundaries. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change | | Normalize and authorize exact parameters immediately before execution. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change | | Keep durable credentials outside model context. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change | | Verify effects through authoritative state, not tool prose. | Versioned test, trace, or architecture record | Material workload, provider, policy, or data change |

Alternatives and trade-offs

A centralized control plane simplifies policy and evidence collection but can become a latency and availability dependency. Distributed enforcement reduces central bottlenecks but requires consistent identity, versions, and audit semantics. Prefer the smallest boundary that can enforce the invariant and prove the outcome.

Failure modes

  • Schema validation is mistaken for authorization.
  • Containers mount host credentials or unrestricted networks.
  • Approval tokens do not bind parameters.
  • Tool output injects new instructions into the agent loop.

Operational checklist

  • [ ] Unknown fields and ambiguous identifiers are rejected.
  • [ ] Policy fails closed and carries tenant identity.
  • [ ] Sandboxes restrict filesystem, process, network, and resources.
  • [ ] Egress destinations and payloads are governed.
  • [ ] Consequential actions have independent postcondition checks.

Connected practice

Sources

  • owasp-llm
  • mcp-specification
  • oauth-security-bcp
  • nist-zero-trust