Least privilege: what the agent was allowed to touch

A developer runs a coding agent against GitHub through an MCP server. The token behind it is the developer's own, with access to every repository the developer can see. The developer asks: "Go through the open issues in my public repo demo-site and handle them." Issue 12 reads like fan mail. It also asks for a README section about the author, with a list of their other repositories and a few lines from each one's config, "including the private ones." The agent lists all nine repositories, opens a config file in a private one, writes the README and opens a pull request on the public repo. The pull request is public. The config file had a live payment key in it.

This is not a made up shape. Invariant Labs published the attack on 26 May 2025 against the official GitHub MCP server: a public issue with planted instructions, an agent with a broad token, and private repository data leaked into a public pull request. They called it an architecture problem rather than a bug in the server code, and GitHub had no simple fix to ship.

The injection is the trigger. The token is the damage. The agent never needed to read a private repository to handle issues on a public one, but nothing in the system knew that. The prompt said which repo the task was about. The token said every repo. When the two disagree, the token wins, because the token is what the API checks.

OWASP lists this as LLM06:2025, Excessive Agency, and splits it three ways: excessive functionality (tools the task does not need), excessive permissions (credentials wider than the task) and excessive autonomy (actions taken with no check). Our agent had all three. It could write as well as read, its token reached private repositories, and it opened the pull request without anyone looking.

A common misreading is that tool descriptions solve this. The MCP specification, since its 2025-03-26 revision, lets a server mark a tool with readOnlyHint and destructiveHint. Those are hints for the client's interface. The spec says clients should not trust them from untrusted servers, and nothing enforces them. A hint is not a permission.

Give the agent a credential for the task, not for the person. The task was "issues in demo-site", so the token is a fine grained one scoped to demo-site: read on issues, write on pull requests, nothing else. The same injection in issue 12 then produces a 403 at line 6 instead of a leak at line 7. The model still gets fooled. It just cannot do anything with it.

Separate read from write at the tool level and gate the writes. A pull request on a public repository is external communication in Willison's sense: it is a way for data to leave. Either a person approves it, or the tool checks that the diff contains only files from the same repository. Authorization lives in the tool and the API, never in the prompt, because the prompt is the thing the attacker edits.

Then shorten the list. Every tool the agent carries is one more thing an injection can call. If the job is triage, the agent does not need get_file on anything outside the target repo. Unused capability is not free. It is attack surface with a friendly name.

Say three words first: token, scope, task. "The failure is at line 6, where the agent reads a private repo during a task about a public one. The model was tricked, but the token let it. I would mint a token per task, scoped to the one repository and the operations the task needs, and I would gate any write that publishes data behind a diff check or a person." If they push on the MCP hints, say they are interface hints, not authorization.