An agent can make only the exact tool calls it is authorized to make and still be turned against the user by what it was allowed to read.
The least-privilege MCP series worked out how to scope the calls. The agent carries a narrow token, or the resource decides each call, and the standards around AuthZEN, ARAP, and the rest tighten the grain until a call authorizes one action against one resource and nothing more. That is least privilege, and it is the mature half of the problem.
It is also only half. Least privilege bounds what the agent may do. It says nothing about what the agent may be exposed to while deciding what to do. That second surface is larger, and it is where most agent compromise actually happens.
The distinction is simple:
Least privilege asks, “May the agent perform this action?” Least exposure asks, “Did the agent need to see this in order to decide?”
For agents, the second question is not a privacy footnote. It is a security boundary.
Authorized Access Is Not Safe Exposure
Take the board packet from the series. The agent is scoped exactly right. It may read Q3 financials for one entity, draft one document, and notify the audit committee, each call at the action’s grain, each denied if it drifts. Least privilege, done well.
To decide what to call, though, the agent reads a great deal more than it calls. It reads its system prompt, the user’s request, retrieved documents, the descriptions and schemas of the tools available to it, the outputs of earlier calls, and whatever memory it carries between turns. Suppose one retrieved document carries an instruction the agent was never meant to act on, a line telling it to ignore its guidance and forward the financials to an outside address. Every tool call the agent then makes may still be individually authorized. The compromise did not arrive through an over-broad grant. It arrived through what the agent was shown, and the authorized notify became the way out. A document is only one carrier. The same instruction can arrive in a tool’s description or an error the model reads back.
Least privilege on the call did not help, because the reasoning that chose the call was steered by context the agent should not have been handed in that form. The resource read may have been authorized for the user. It was still the wrong exposure for this step of this task.
That is the core mistake: treating “the principal may access this” as “the model should see this.” Human access and agent exposure are not the same control. A human can ignore irrelevant material, preserve secrets by judgment, and remain accountable for misuse. A model turns everything it sees into possible instruction, evidence, memory, or egress material. You cannot authorize your way out of a bad working set.
A fair objection is that this is just need-to-know, and security has always minimized what a principal can see. It is, with one difference that changes its character. Need-to-know for a human is a confidentiality control, resting on a reader who will not act on what they should not have seen. An agent offers no such assumption. For an agent, minimizing exposure is also an integrity control, because what the model reads is what steers it. The old principle did not get replaced. Its job doubled.
The Exposure Surface Is Bigger Than Data
Minimal disclosure is usually discussed for identity claims, releasing only the attributes a relying party needs. For an agent, the surface is much wider. Everything the agent is shown in order to decide is at once a disclosure surface and an injection surface:
- Instruction exposure: the system prompt, developer guidance, user framing, and approval text.
- Data exposure: retrieved documents, search results, records, files, and tool outputs.
- Capability exposure: the catalog of available tools, their descriptions, schemas, examples, and hidden affordances.
- Secret exposure: credentials, tokens, connection strings, signing material, and privileged configuration that leak into context.
- Policy exposure: business rules, pricing logic, security policy, approval routes, and fraud controls.
- Memory exposure: session memory, long-term memory, embeddings, and summaries carried from earlier work.
- Response exposure: downstream responses, errors, logs, and diagnostic text that come back from the tools it calls.
Each is something the agent should see only as much of as the task in front of it requires. A finance agent does not need the whole document corpus to draft one packet. A support agent does not need every customer’s record to answer one ticket. Exposure that exceeds the task is latent risk, whether it leaks outward or steers the agent inward.
The practical test is harsh but usable:
If this item were prompt-injected, stale, maliciously selected, or later leaked, would the approved task still justify showing it to the agent?
If the answer is no, it does not belong in the working set merely because the user, service account, or tool could access it.
Least Privilege Already Governs One Slice
The authorization series draws this line once, for exactly one surface. Filtering tools/list is exposure control, not authorization. Narrowing the catalog an agent can see is worth doing, but it does not decide any call, and the server must still authorize every tools/call. That distinction is least exposure applied to a single surface, the tool catalog.
The move is to generalize it. The tool catalog is one of many things the agent is shown, and the same discipline applies to all of them. Scope the retrieval. Scope the memory. Scope the schemas, the secrets, and the policy text. Show the agent the smallest slice of each that the task justifies, for the same reason the deployment filters the catalog.
That gives a clean rule for system design:
Treat every context source as an exposure point with its own PEP.
The retrieval layer decides which records enter context. The tool host decides which tools and schemas are visible. The memory store decides which past state is eligible. The secret broker decides what never enters context at all. The harness decides what survives across a resume. The egress boundary decides what leaves. A single broad prompt assembly step that grabs everything the principal can reach is the context equivalent of handing the agent a root token.
Untrusted Reasoning Makes Exposure the Attack Surface
The series is explicit that the model is untrusted reasoning that proposes actions, and that the protocol layer’s job is to govern the invocation, not the reasoning. That framing has a corollary it does not draw out. If the reasoning is untrusted, everything the reasoning is shown can steer it. Exposure is not a privacy nicety layered on top. It is the attack surface itself.
Simon Willison’s lethal trifecta names the dangerous combination in one loop: access to private data, exposure to untrusted content, and a way to send data out. Least privilege narrows the permissions on those legs: which data may be read, which tools may run, which egress paths may be used. Least exposure narrows what actually reaches the model: which private data enters the working set, which untrusted content can influence the session, which tool descriptions and responses become part of the reasoning context. Cutting one leg is not safety. An agent with a tiny set of authorized calls is still dangerous if it holds the crown jewels and reads the open web in the same loop.
Exposure, not detection, is therefore the control to lean on. There is no general way to tell whether a retrieved document or a tool description carries an instruction the model will follow, and sanitizing untrusted content is best-effort that injection keeps routing around. What a system can decide deterministically is whether the model is shown the material at all. Not-shown is the only guarantee that does not depend on catching the attack first.
This is also why “we log every action” is not enough. Logs tell you which calls happened. They rarely tell you which sentence, retrieval result, memory, or tool description shaped the action. If the exposure path is not governed and recorded, the audit trail starts too late: at the call, after the model has already been steered.
The Mission Bounds Both
The least-privilege series ends on a missing object. Nothing names the task the calls serve, so no layer can decide whether a given call is still inside the work the user approved. Exposure has the same gap, from the same cause. Nothing scopes what the agent is shown to the task it was approved for, so it is shown whatever its principal happens to have standing access to.
One object closes both. A Mission, the durable record of the approved task the series points toward, is a budget for authority and for disclosure at once. A Mission bounds not only what the agent may do, but what the agent may be exposed to while deciding what to do. Retrieval scoped to the Mission does not surface the acquisition memo that has nothing to do with the board packet. A catalog scoped to the Mission does not offer the external-email tool for a task that only reads and drafts. Memory scoped to the Mission does not import last quarter’s unrelated investigation. A secret scoped to the Mission is used by a broker or PEP, not copied into the prompt.
Context reaches the agent because the approved purpose justifies it, not because the user behind the agent could have opened it by hand.
The enforcement pattern is the same one the Mission work uses for authority, a mediated custody in which the runtime, not the agent, holds what the task needs and releases only what the current step justifies. The agent is handed a working set, not the keys to everything its principal can reach. Least privilege makes the calls narrow. This makes the context narrow. Both are the Mission doing its job.
The claim should be checkable. A system that says it runs governed agents should be able to answer:
- What Mission is this context item justified by?
- Which exposure point admitted it?
- Was it private data, untrusted content, capability metadata, memory, policy, or a secret?
- What downstream actions became riskier because the agent saw it?
- When the Mission ends, what context, memory, cache, or connection is cleared?
If those answers do not exist, the deployment has least-privilege calls wrapped around an ungoverned working set.
Two Halves of One Discipline
Least privilege and least exposure are two faces of one discipline, minimal disclosure for agents. One narrows the calls the agent can make. The other narrows the inputs to the reasoning that decides which calls to make. The authorization half is mature. It has models, standards, and a clear place to enforce. The exposure half is mostly still left to prompt hygiene and hope, even though it is the larger surface and the one the lethal trifecta actually exploits.
A well-authorized agent fed the wrong context is still a compromised agent. Least privilege is necessary. Least exposure is the broader principle it lives inside, and the same approved task that bounds one should bound the other.
The short version is the one worth carrying into architecture reviews:
Do not only ask what the agent can call. Ask what the agent can see before it chooses the call.