The permission boundary behind every agent action

What leaders need to know

An agent that reads content it did not write, holds authority to act, and can move data between the two will eventually be given instructions by an attacker. Prompt-level defences reduce how often that succeeds; they do not make it impossible. The controls that hold are the ones the model cannot talk its way past: the identity the agent acts under, the authority delegated to that identity, the scope of the tools it can reach, and the confirmations required before consequential actions. These should be designed explicitly and written in a form that can be tested.

Three properties, one problem

Simon Willison’s description of the “lethal trifecta” is a direct statement of the named concept: an agent that combines access to private data, exposure to untrusted content and a way to communicate externally can be induced to leak that data, because the untrusted content can contain instructions and the model cannot reliably distinguish them from the user’s. The OWASP Top 10 for Large Language Model Applications lists prompt injection as its first entry and “excessive agency”, meaning more functionality, permissions or autonomy than the task requires, as a distinct risk in its own right. The two combine: injection supplies the malicious instruction, excessive agency supplies the means to act on it.

The practical consequence is that the question “how do we stop the model from being fooled?” has a ceiling, and the question “what can the agent do if it is fooled?” does not. Enterprise security has been here before. Zero-trust architecture, as described in NIST SP 800-207, starts from the assumption that no request is trusted by virtue of where it comes from, and evaluates each one against identity and policy. Agents are a new kind of requester, and the same discipline applies.

Identity: who is the agent, right now?

Most agents in early deployment borrow a person’s credentials or run under a shared service account with broad rights. Both make the authority question unanswerable. The first design step is to give the agent an identity of its own, distinct per deployment and ideally per workflow, so that its actions can be attributed, its permissions scoped, and its access revoked without affecting anyone else.

The second step is delegation. When an agent acts for a person, the system needs to know that the person delegated that authority, for what, and for how long. A delegation model answers questions such as:

• Can the agent read this record because the user could, or because the agent’s own identity can?
• When the agent calls another agent, does the second agent inherit the first’s authority, the user’s, or its own?
• What happens to in-flight work when the user’s session ends or their access changes?

Written down, these are usually short. Left implicit, they are usually wrong.

Tool scoping: what can the agent reach?

Tools are how agents acquire authority, and they tend to accumulate. A useful review asks, for each tool, four questions. Is the permission the tool carries the minimum for the workflow, or the maximum that was convenient? Can the tool’s description be altered by something the agent reads, including by a third-party server? Which calls are consequential enough to require a confirmation a person can see? And does the tool validate its arguments, or does it trust the model to supply sensible ones?

The Model Context Protocol’s security guidance is worth reading even by teams that do not use the protocol, because it names concrete failure modes: servers acting as a confused deputy that pass through a client’s authority, token passthrough, and session identifiers used as if they were credentials. These are ordinary web-security problems appearing in a new place, and the remedies are ordinary too: separate the agent’s credentials from the user’s, validate at the boundary, and do not let a description that the model reads carry more trust than the content it came from.

Confirmation: when should a person be in the loop?

Not every action needs a confirmation, and an agent that asks constantly will be routed around. The design question is which actions are consequential and hard to reverse, and for those, what the person must see in order to give an informed yes. A confirmation that shows the person a summary the agent wrote is weaker than one that shows the actual parameters of the action, because the summary can be shaped by the same content that shaped the action.

Confirmation also interacts with delegation. If the agent acts for a user and the user confirms, the record should show both identities. If the agent acts for the organisation with no user present, the confirmation route needs an owner, which is an operating-model decision as much as a technical one.

Making boundaries testable

An authority model is only useful if it can be checked after every change. The practice that works is to write each intended boundary as a statement that can be exercised:

• The agent acting for user A cannot retrieve records owned by user B through any tool.
• No tool available to the agent can send data to an external destination other than the allow-listed ones.
• A tool description supplied by a third-party server cannot change which tools the agent may call.
• Any action in the “consequential” list produces a confirmation showing its real parameters before it executes.

Each statement becomes a test in the same harness that evaluates the agent’s task behaviour. When a tool is added or a permission changes, the tests either still pass or they identify precisely what moved.

Isolation as the backstop

Identity and tool scoping bound what the agent may do through sanctioned routes. Isolation bounds what it can do through unsanctioned ones: an agent that executes code, browses or operates a computer needs an environment whose filesystem, network egress and secrets are constrained regardless of what the model decides. Isolation is the control that holds when the others have been misconfigured, which is why it is worth assessing separately rather than assuming a platform provides it.

What this does not resolve

None of this makes prompt injection harmless; it makes its consequences bounded, which is a different and more achievable goal. It also does not remove the need for prompt-level and detection controls, which reduce frequency and provide signal. And a written authority model is only as good as the review that checks it against the deployed system. That review, rather than the model’s assurances, is where confidence should come from.