Why static review stops too early

Scanning code and dependencies before deployment catches many issues. It does not catch what an agent decides at runtime. An agent's behavior is a function of its prompt, its tools and its context, and any of the three can change after the scan finished. A previously safe environment becomes risky when the agent receives new context, picks a tool it had not used before or reaches a destination nobody listed.

The ecosystem is also too large to review by hand. When the Linux Foundation announced the Agentic AI Foundation in December 2025 and MCP moved under its governance, the release counted more than 10,000 published MCP servers. Every one of those servers brings tool descriptions, credentials and runtime behavior into an agent workflow. Review before trust is necessary. It is not where control ends.

Risk between approved connections

Consider a simple chain: Agent A calls Agent B, which queries an MCP server, which invokes a tool that accesses a database. Each hop in that chain is a trust decision. If authorization is evaluated only per connection or service, the composed action may not receive an adequate check. Four failure modes follow from that.

Cascading permissions

Agent A has access to your email. Agent B has access to your code repository. If B accepts A’s requests without checking delegated scope, A may be able to use B’s repository access. Multiply that by a few hundred agents, each with its own tool connections, and the permission graph stops being something a human can read.

Identity and attribution

When an agent sends an email, deploys code or modifies a database, who is responsible? The user who configured it, the agent framework or the MCP server that provided the tool? Without an identity for the acting agent and a record of the human it acts for, there is no audit trail that spans the chain.

Supply chain at agent scale

Every MCP server an agent connects to is a dependency and every tool is an attack surface. Tool poisoning, where a server manipulates agent behavior through crafted tool descriptions, can steer an agent toward unintended actions. Its impact depends on the tools, credentials and destinations available to that agent.

Rug pulls and mutation

An MCP server that was safe yesterday might not be safe today. Invariant Labs documented in April 2025 that a malicious server can change a tool description after the client has already approved it. Servers can also add tools, change behavior or be compromised outright. A point in time assessment cannot hold against an ecosystem that changes daily.

Policy checks before a tool call

The fix is to move the decision to the moment of action. Before an agent's tool call executes, something deterministic has to answer four questions with data it can verify, not with a guess about intent.

Who is acting, and for whom. The identity of the agent instance making the call and the identity of the human or service it acts on behalf of. A shared service account answers neither. Policy needs both, because the same tool call can be legitimate for one principal and forbidden for another.

Which tool, with which parameters. Not "the agent may use the database server" but "this agent may run a read only query against this schema". The tool name is the coarse part. The arguments carry the risk: the path being written, the SQL being run, the recipient of the message, the command passed to a shell.

Where the action goes. The destination host, the filesystem path, the repository or the network range. An outbound HTTP call to an internal metrics endpoint and one to an unknown domain are the same tool call from the model's point of view. They are not the same decision.

How much, and within what scope. Rate limits per agent and per tool, and the delegated scope the human actually granted. An agent that is allowed to send one summary email is not allowed to send four hundred, and a scope granted for a single task should not survive into the next one.

The goal is not to stop useful work. It is to make the approved path explicit so that requests outside it are denied or held for review rather than executed by default.

Why per invocation, not per connection

Policy has to be evaluated per invocation, not per connection. That isn't a luxury. It's the baseline. The MCP authorization specification says in its first sentence that it "provides authorization capabilities at the transport level"; it is optional, and it is defined for HTTP transports only, with stdio servers told to take credentials from the environment. That design answers "may this client talk to this server?" It does not answer "may this agent run this tool with these arguments right now?" A bearer token can carry scopes and expire or be revoked. The server must enforce those permissions for each request; transport authorization alone does not define every application-specific parameter constraint.

Connection level trust is also what makes the chain above dangerous. Each link was authorized. The composed action was not. Per-invocation evaluation is an important checkpoint: the identity, the tool, the arguments and the destination arrive together, and the decision can be made on all of them.

What has to be recorded after

An enforced decision also needs a record that the team can review. After every evaluated call, the environment should return evidence that policy was applied and what happened next. Four fields make that record useful.

  • The request as the policy engine saw it: agent identity, delegated principal, tool, arguments and destination.
  • The decision: allowed, denied or held for review, and the rule that produced it.
  • The policy version in force at that moment, so a later change to the rules cannot rewrite what was permitted in the past.
  • Integrity metadata, such as a signed hash chain with a trusted checkpoint, so reviewers can detect changes. A hash stored beside a mutable record alone does not prevent an attacker from replacing both.

These fields establish the authorization context. Add correlated execution results to show what happened next. Before changing a rule, review whether a denied request was legitimate and whether the proposed permission is necessary.

What this means for defenders

Treat every agent tool call as a policy decision, not a network event. Inventory the MCP servers and tools your agents can reach, then write the allowed path for each one in terms of identity, tool, arguments, destination and rate. Deny by default outside that path and route exceptions to a human. Pin tool definitions and alert on change, because approval of a description is not approval of its next version. And insist on evidence with integrity metadata; integrity metadata strengthens the record, alongside access controls, retention and corroborating telemetry.

This is the model I am building into Oktsec Control: a deterministic policy layer that evaluates each invocation on facts it can verify before it runs and returns signed evidence after. The security infrastructure has to be built alongside the agents, not after the first wave of incidents.