An agent that can call an MCP server, run a shell command, read a repository, or delegate work to another agent has crossed an important line: it no longer only produces text. It can request effects in other systems.
That makes “which tools are available?” the wrong first security question. The harder question is: what sits between a model’s request and a real effect—and does that control still hold when the workspace, executor, permission state, or delegated agent changes?
The answer is Capability mediation. It is an architectural pattern in which every meaningful agent capability passes through an explicit control point before execution and, when needed, again before the result enters model context. The control point can allow, deny, narrow, transform, log, rate-limit, or require approval for an operation. It evaluates the request in its actual execution context rather than treating a tool declaration as a permanent grant.
Plain English: A tool is not permission. Capability mediation is the layer that turns an agent’s request into either a tightly constrained real action or no action at all.
This is not a new security principle dressed up for AI. It applies the logic of a Reference monitor: a mediation point that must see security-relevant accesses, resist tampering, and make decisions from policy. Agent systems make the idea more awkward in practice because there may be several mediators: an agent runtime, an MCP gateway, a remote executor, a sandbox, and an identity service. A design is only as strong as the path that bypasses all of them.
Why this matters now
The Model Context Protocol (MCP) separates tools, resources, and prompts as different capabilities. Its specification also requires implementers to provide user consent and authorization controls for data access and operations. MCP specification That separation is useful, but protocol discovery is not an enforcement architecture.
Codex 0.151.0, released August 29, makes the operational problem visible. Extensions can inspect or replace MCP tool results before those results reach the model. The release also preserves restored permission profiles across TUI turns, prevents /cd from weakening sandbox restrictions, uses the remote executor’s actual home directory, operating system, and path conventions for sandbox enforcement, counts nested subagent token usage against root-goal budgets, and prevents stale Guardian classifications from authorizing actions after permission state changes. Codex 0.151.0
These are not one feature called “security.” They are failures at different moments in an agent tool lifecycle: discovery, invocation, execution, result return, delegation, and state change. The durable lesson is that a single approval dialog or an allowlist at startup cannot carry the whole burden.
How mediation works
Start with discovery. An agent may learn about tools when an MCP server connects, when a local project supplies configuration, or when an optional server becomes available. Discovery should answer what can be described to the agent, not what it may execute. Codex 0.151.0, for example, added a configurable grace period for discovering tools from optional MCP servers. Codex 0.151.0 Availability is operational state; it is not authority.
At invocation, the mediator receives a proposed operation: tool name, arguments, caller identity, task, current permission profile, workspace trust level, and target server or executor. It validates the request against policy. Crucially, it can perform Authority attenuation: expose less power than the backing system possesses. A repository tool might be narrowed to one checkout and read-only paths. A deployment tool might accept only a staging environment. A network tool might be limited to named destinations. A delegated agent might receive a smaller capability set and a fixed budget.
The decision must include Context binding. This means binding an authorization decision to facts that actually matter: the session, current policy version, agent or subagent, executor identity, operating system, home directory, path rules, and sandbox state. A cached “allowed” result without these bindings is dangerous. If a user changes permissions, switches executor, or enters an untrusted workspace, a formerly valid classification may no longer be valid.
Plain English: “Allowed earlier” is not the same as “allowed here, now, for this executor.” Security decisions need enough context to expire when that context changes.
Then comes execution. A Sandbox limits an executor’s ambient power: what files, processes, or network destinations it can reach even if code goes wrong. It is essential, but it is not enough. A sandbox generally cannot express that delete_issue is allowed only for issues created by this task, or that a package installer may use only an internal registry. Invocation mediation supplies those semantic, argument-level rules; the sandbox supplies a backstop when they fail.
After execution comes Result mediation. Tool output is not automatically trustworthy merely because the call was allowed. It can contain secrets, huge payloads, misleading instructions, malformed data, or an error that needs to remain structured. A result mediator can bound size, redact defined sensitive values, preserve structured errors, label data as untrusted, or reject output before it becomes model-visible context. Codex’s new extension point to inspect or replace MCP results is an example of this boundary. Codex 0.151.0
Finally, account for delegation and time. A child agent is not a clean accounting boundary if it spends the parent’s resources or acts toward the parent’s goal. Codex’s root-goal accounting for nested subagent tokens illustrates one part of a Root task budget. Codex 0.151.0 A practical budget can also cover elapsed time, delegation depth, number of tool calls, spend, and classes of side effects. It should be enforced at the mediator, not merely requested in a prompt.
What it is not
Capability mediation is not Authentication. Authentication establishes who or what is making a request. It may be necessary input to policy, but it does not decide whether this particular operation is safe in this context.
It is not merely Authorization, either. Authorization is the allow-or-deny decision. Mediation is the larger arrangement that ensures decisions happen on every relevant path and can include argument validation, execution constraints, output handling, budgets, and audit records.
It is also not a claim that every system needs a pure object-capability design. In object-capability systems, holding an authority-bearing reference is central to access. An agent platform can use scoped credentials, identities, policies, or a combination. What matters here is that authority is explicit, reducible, and checked at the point it becomes effect.
MCP authorization guidance makes a related boundary clear: clients must handle resource-specific tokens, and token passthrough to downstream services is forbidden because unvalidated forwarding can create confused-deputy and trust-boundary failures. MCP authorization MCP security practices A mediator should therefore obtain or exchange credentials for the intended resource, not blindly relay whatever credential happened to arrive upstream.
A practical engineering example
Consider a hypothetical internal coding agent asked to update a service and open a pull request. It can read a repository, run tests in a remote executor, query an issue tracker through MCP, and ask a release subagent to assess deployment risk.
A weak implementation publishes all four tools to the model and lets each tool enforce its own local rules. That creates gaps. The issue tracker can return a comment containing instructions aimed at the model. The remote executor may have different paths from the controller. The release subagent may make more calls than the parent’s budget anticipated. A permission approval cached before the user switched repositories may survive too long.
A mediated design begins by assigning the task a root identifier and a limited capability set. Repository access is read/write only under the checked-out project root; shell execution runs in a sandbox configured from the remote executor’s real environment; issue-tracker calls get a resource-specific credential with only the needed scope; and the subagent gets read-only repository access plus a token and time allocation drawn from the root budget.
Each proposed call records the requested operation, the effective narrowed capability, relevant context, policy version, decision, and result disposition. The mediator rejects a write outside the project root before process execution. It blocks a changed credential from reusing an old approval. It tags issue-tracker text as untrusted before placing it into context and applies defined size limits. If a policy change revokes deployment access, future requests must be re-evaluated; long-running work may need separate cancellation handling.
Plain English: Build tools as powerful backend services, but hand each agent only the smallest, short-lived slice of power needed for the current task.
This does not require one giant policy service. A filesystem wrapper, a command launcher, an MCP proxy, and a subagent scheduler can each mediate their own boundary. But they need shared concepts: task identity, trust state, policy version, budget, audit schema, and a deliberate rule for revocation. Otherwise distributed controls disagree in precisely the cases attackers and production failures find.
Where it breaks
The first failure mode is incomplete coverage. If an agent can start a subprocess directly while its shell tool is mediated, the direct path defeats the design. So can alternate MCP clients, inherited credentials, cached handles, or state injected into the model outside the result boundary. Map effectful paths before writing elaborate policies.
The second is confusing content safety with access control. Result mediation can mark or filter untrusted text, but it does not prove that text is true or harmless. Prompt injection, sensitive-data handling, and data-flow controls remain separate problems.
Third, over-transformation can be harmful. Redacting output may hide diagnostics. Converting structured errors to prose can deprive the agent and operator of the information needed to recover. Preserve machine-readable failure information where it is safe to do so; Codex’s preservation of structured MCP tool and resource errors in app-server responses points in that direction. Codex 0.151.0
Finally, revocation is not instantaneous magic. A newly denied future call is straightforward. A token already issued, a job already running, or a subprocess already spawned may require credential expiry, cancellation, process control, and downstream cooperation. State changes must invalidate cached decisions, but the system must also define what happens to in-flight authority.
What you can do this week
Trace one agent workflow from tool discovery to the final model-visible result. Mark every place it can read data, mutate state, spend money, consume substantial compute, or delegate work. For each boundary, ask: what identity and context does the decision use; can the capability be narrowed; what happens after policy changes; and can this path bypass the intended mediator?
Next, choose one high-value tool and wrap it. Keep the first policy simple: narrow arguments, bind approval to task and executor context, set a budget, log a decision record, and handle output as untrusted input. Test transitions, not only static cases: change workspace trust, change permissions, switch executors, and retry a cached request.
The goal is not to make an agent harmless. It is to make its real authority legible, limited, and revocable enough that engineering teams can reason about it.
Today's AI trends
Codex turns tool handling into a lifecycle problem. Codex 0.151.0 adds result interception while also tightening permission persistence, sandbox context, stale authorization handling, and nested-agent budgets. Release The practical implication is to review agent controls as connected lifecycle boundaries rather than independent tool settings.
Gemini CLI makes restricted workspaces reduce MCP availability. Its August 29 nightly release enforces fail-closed workspace trust and filters MCP servers in restricted mode. Release For internal coding agents, an untrusted repository should automatically remove capabilities instead of relying on remembered user choices.
LangChain’s MCP adapter keeps operational controls visible. The 1.4.0a2 alpha introduces an MCPAdapter for turning MCP servers into tools while leaving authentication, caching, timeouts, and related behavior with FastMCP clients; multi-server configurations namespace tools by server. Release Normalizing a protocol is useful, but transport and credential policy still belong in the application architecture.