Permissions: The Least-Privilege Agent

The lethal trifecta

The best mental model for this comes from June 2025, and it names three ingredients:

1. access to your private data,
2. exposure to untrusted content,
3. the ability to communicate outwards — in a way that can carry data out.

Any two are safe. All three together are not.

This also gives you the practical translation of least privilege: you do not have to lock everything down — cutting one leg is enough. If the agent can read private data and look at untrusted content but cannot call outwards, there is no channel for exfiltration. If it can call outwards and sees private data but only reads from trusted sources, there is nobody to instruct it.

Ten documented cases

These are not theoretical risks. Every one of them is a published, dated case.

And two from 2026 that are worth singling out.

The first is the most instructive allowlist story I know. The agent's outbound traffic was restricted with a domain list — correctly. Except that the provider's own API was on the list. Using a key placed in the prompt, the attacker had the files uploaded to the provider's own file upload endpoint, then downloaded them later. The limit worked; the way out was on the list of trusted destinations.

The second: an office agent sent emails without approval, with external images — and loading the image was itself the leak channel.

What these have in common

Three statements worth memorising word for word. The researchers behind one of the cases put it like this:

• "not a flaw in that particular server's code, but a fundamental architectural question that has to be handled at the agent system level";
• "not specific to one agent or one client — it affects every agent that uses this server, regardless of model and implementation";
• "even the most advanced, aligned models are vulnerable to these attacks."

In other words: this is not a software bug that will get fixed, and not a model question that the next version solves. It is a property of agent architecture, and permissions are where you can deal with it.

There is a recurring pattern in them too: in almost every case the data went out through a "harmless" channel — an image URL, a redirect, a submission, a form. Not a data export, but something that looked legitimate.

How many permissions do they actually run with?

Here come the measurements, and they are not flattering.

The 9.93% deserves separate attention. The agent decides what to call based on the tool description. If every tenth description does not describe what the code does, then every tenth decision the agent makes rests on wrong information — without anyone having made a deliberate mistake.

And the wider picture, from cloud telemetry: 19–23% of virtual machines run with excessive permissions, a good share of them able to acquire full administrator rights. 59% of IAM users have an access key older than a year. (This survey does not break out agents separately — but this is the environment they land in.)

The toolkit for narrowing it down

The good news: there is primary documentation for this, you do not have to invent it.

Minimising scope. The protocol specification devotes a separate section to it and lists the price of over-broad permissions: a larger blast radius for a stolen token, harder revocation (revoking one know-everything token stops every process), noisy audit (one merged permission hides what the user actually intended), permission chaining (the attacker can immediately call a high-risk tool with no further escalation), and the abandonment of consent — the user rejects the dialog if it asks for too much.

The recommended model is progressive: minimal starting permissions (discovery and reading only), and targeted elevation at the moment it is first needed.

The typical mistakes it names: publishing every possible permission; wildcard or "know-everything" permissions; bundling unrelated rights together so that no further asking is needed later.

Token pass-through — an absolute prohibition. The specification states it in mandatory form: a server must not accept a token that was not explicitly issued to it.

Network limits. At recommended level the specification prescribes blocking private IP ranges — and names the cloud metadata endpoint among them. That is the address from which a compromised process can request the credentials of the runtime environment. Alongside it: enforcing HTTPS, validating redirect targets, an outbound proxy.

Sandboxing. For local servers: minimal default permissions, restricted filesystem and network access, and where possible a transport that only the client can reach.

And the most recent industry risk list, which names identity and permission abuse as an entry of its own: "with stolen credentials they can operate far beyond their intended scope".

The recipe

1. CUT ONE OF THE THREE LEGS
   Private data / untrusted content / outbound channel.
   Decide which one you remove - do not try to handle
   all three at once.

2. READ THE ALLOWLIST BACKWARDS TOO
   The question is not what you allow. It is which of
   the allowed destinations data can be taken OUT to.
   A file upload endpoint on the list = an open door.

3. START WITH READ, ASK FOR WRITE SEPARATELY
   Minimal starting permission, and elevation when it
   is first genuinely needed.

4. NO WILDCARDS IN THE PERMISSIONS
   "Full access" and the wildcard character are exactly
   what the specification names as a typical mistake.

5. BLOCK THE INTERNAL NETWORK
   The cloud metadata endpoint above all. It is the most
   frequently forgotten address.

6. A TOOL DESCRIPTION IS NOT DOCUMENTATION
   Every tenth one does not describe what the code does.
   Read the code of what you wire in, not the blurb.

7. SHORT-LIVED CREDENTIALS
   Measurement: on 59% of human accounts the key is
   older than a year. The agent's must not be.

The second point is the most important and the easiest to get wrong. Everyone writes the allowlist by asking "where does the agent need to go". The right question: "which of the destinations on the list can data be uploaded to?"

Common misconceptions

• "This is a vulnerability, they will fix it." The researchers say it is not a flaw in one product's code but an architectural question to be handled at agent system level.
• "A better model solves it." The published finding is that even the most advanced, aligned models are vulnerable.
• "I have an allowlist." A service on the allowlist can also be an exit channel — that is exactly what happened in a 2026 case.
• "The agent only reads." As long as it also reads untrusted content and has any outbound channel at all, the trifecta is complete.
• "The tool description tells me what it does." A study of 19,200 pairs found that every tenth description does not match the code.
• "We have a security scanner." A study of 64 thousand servers found that fewer than half of the alerts are true positives.

What to take away

For agents, least privilege is not a matter of caution but the one manageable point of the risk — because there is no reliable technical defence against prompt injection, and model progress does not solve it either.

In one sentence: the decision is not how much you trust the agent, but how far it can reach if it gets deceived.

And one check that costs five minutes: look at the allowed destinations for outbound traffic and ask about each one whether data can be uploaded there. If the answer is yes, that is the third leg of the trifecta — however trustworthy the destination is.

Where the human approval belongs in the chain is what the human in the loop post measures out; the standard behind wired-in tools and its security side is the subject of the MCP post. The most extreme case is a personal agent running on your own machine, where every boundary is yours to build — that is what the self-hosted personal agents piece is about, end to end.