Complete Mediation

Saltzer and Schroeder’s complete-mediation principle is deceptively simple: check every access to every object every time, with no cached bypass. In 1975 the principal concern was a Unix process that cached the result of a capability check from session start and continued to use it even after the underlying permission was revoked. Fifty years later the failure mode is structurally identical, but the object being accessed is a tool API, the principal is a non-deterministic language model, and the window between an authorisation being granted and it being abused can be a single tool call.

For agents the principle is more demanding than it was for processes, for a reason that had no analogue in 1975: intent can change mid-session. When a human opens a file, their goal is stable. When an agent begins a task, its effective goal is generated at runtime from its current context, and that context can be rewritten by any text the agent ingests. A session that started as “summarise these quarterly reports” can become “exfiltrate the payroll table” after one injected document lands in the context window. The authorisation that was correct at session start is no longer correct at step 40. Checking once is not checking at all.

Complete mediation for agents therefore means a chokepoint gateway through which every tool call passes, with a policy check against the current task, not the original session claim. A sub-agent cannot rely on the orchestrator’s word that it is authorised; it must carry its own credential that the gateway verifies independently. Credentials must expire with the task, not the session: a token minted for “create one support ticket” has no business being used for a read-all-tickets call ten steps later, even if the model’s context claims they are related. Every call, every time, against current context.

Scenario: permission accumulation

An orchestrator runs a long research workflow. At step 3 it requests read access to a customer database to answer a specific query. At step 15 it requests write access to a shared document. At step 40 it needs to send an email. If each of these permissions is granted and stays in context (the common pattern where a session-scoped token accumulates all granted rights), the agent at step 40 holds an effective superset of everything it was ever granted: read on the database, write on documents, and email access. An injection at step 35 can now exercise the full accumulated set. A gateway that re-checks every call against the current task’s declared scope refuses the database read when the current task is email composition, because the task context has changed.

Scenario: the trusted sub-agent hop

An orchestrator delegates a financial query to a data-retrieval sub-agent and, to save latency, passes along its own bearer token as a “convenience.” The sub-agent uses that token to make calls the gateway would have refused for the sub-agent’s own scoped credential. The orchestrator’s wider rights launder through the delegation hop. Complete mediation requires the sub-agent to present its own credential and have that credential checked independently at the gateway. “The orchestrator said it’s OK” is a trust assertion that should mean nothing to the policy engine; only the sub-agent’s own cryptographic identity and its assigned task scope determine what it may do.

How it fails

• An agent accumulates permissions across a long session; later calls exercise rights granted for an earlier, different task.
• A sub-agent trusts the orchestrator’s delegation claim without an independent check at the gateway; the orchestrator becomes a single point of privilege laundering.
• Credentials persist in the context window or memory across task boundaries, so the next task inherits the previous one’s rights by accident.
• A tool gateway checks identity at connection establishment and caches the result, so a mid-session intent-flip is never re-examined.

Why the mapped controls work

A tool-gateway chokepoint is the architectural enforcement of complete mediation. There is one place where every tool call passes, and that place performs a fresh policy evaluation on every request. There is no path around it, so the check cannot be skipped. Scoped short-lived tokens per task, issued via RFC 8693 token exchange, ensure that a credential’s scope is bound to a specific declared task and its TTL matches the task duration; the token is simply invalid for a different task or after the task ends, so accumulated permission is structurally impossible. Expiry and revocation checked on every call close the gap that Saltzer and Schroeder identified in 1975: a cached authorisation that has since been revoked cannot be exploited because revocation is checked at the moment of use, not just at issuance.

A concrete example: a task token for “create one support ticket” might be shaped as {"sub":"user-42","act":"support-agent-7","scope":"tickets:create","task":"T-1081","exp":1748952000}. The scope field is enforced by the gateway on every call and the exp is checked against the clock, so an attempt to call tickets:read_all or to use the token after task completion is rejected without any model involvement.

First steps

1. Introduce a single tool-gateway service (e.g. an OPA-backed sidecar or a purpose-built API gateway) that every agent tool call passes through, and confirm in a test that calls bypassing it are rejected at the network layer.
2. Issue a per-task RFC 8693 token at the start of each agent task with a TTL matched to the expected task duration (start with 15 minutes and adjust), and configure the gateway to reject calls made with an expired or out-of-scope token.
3. Audit your current session-start authorisation checks: for each one, verify that the result is not cached. Run a test that revokes a permission mid-session and confirm the next tool call is refused within one certificate TTL.