Permissions

The three-layer permission model: every tool call passes through three narrowing gates before it executes. Each layer catches what the others cannot — defense in depth.

flowchart TB
    A([Agent · its tools + mcp_servers]):::ext
    L1[Connection layer<br/>mcp_servers allowlist —<br/>which server classes the agent may reach]:::cls
    L2[Capability layer<br/>tools allowlist — catalog filtered<br/>before the LLM sees it; a hidden tool<br/>cannot be hallucinated]:::cls
    L3[Runtime layer<br/>security-tier gate +<br/>egress/DLP · approval · audit]:::gate
    X([Tool executes in-process,<br/>inside the agent's container]):::ext
    A --> L1
    L1 --> L2
    L2 --> L3
    L3 --> X

    classDef cls fill:#8FA68A,stroke:#2D2D2D,stroke-width:1.5px,color:#1A1A1A
    classDef gate fill:#B87333,stroke:#2D2D2D,stroke-width:2px,color:#FFFFFF
    classDef ext fill:#D5C3B0,stroke:#2D2D2D,stroke-width:1.5px,color:#1A1A1A

The capability layer is the quietly decisive one: because a disallowed tool never appears in the schema, the model cannot call it — whole classes of misbehavior are prevented, not caught after the fact. The runtime layer then gates by tier:

Tier	What happens
Standard	Executes immediately; basic audit record
Elevated	Executes; full arguments + result captured
Restricted	Blocks for human approval before executing

Around all three sit the per-run tool_defaults argument layer and the egress/DLP and audit hooks that wrap every execution.

→ §07 — MCP Architecture · §17 — ADR 4 · the live Security Log audit record · tiers per tool in the Tool Reference