AI Agent Permissions: Designing Safe Tool Access

#Grant the Action, Not the Agent#link

Every agent design review I sit in on gets the capability question right — what can this thing do? — and skips the one that decides whether it's safe: whose identity does the work? In late August 2025, academic researchers published a demonstration they called the Agent Rental Problem, and it answers the skipped question the hard way. A victim's AI agent, injected through a malicious attachment, gets steered to an attacker's site and completes a 'Sign in with Google' flow on its own — the browser session is the victim's, the app was consented long ago, so the provider answers with a redirect and the attacker walks away holding the victim's authenticated identity. No password stolen, no exploit deployed. It worked because of a permission decision made months earlier: the agent acts as the user, so nothing downstream can tell their traffic apart. The six questions below are the ones worth answering in design review instead of in retrospect, in roughly the order teams hit them.

Whose Identity Is Acting?

Three models exist, and the first is what ships when nobody decides. Passthrough: the agent spends the user's live tokens, inheriting every scope they hold — tempting because it needs no new infrastructure, and disastrous because "the agent can do everything I can do" is the bug, not the feature. Shared service account: one over-scoped identity for the whole agent. A boundary finally exists, but it's a single moat around everything, so one crossing takes all of it. Per-tool scoped principals: each tool gets its own identity, scoped to its one function — small grants, clean logs, and a compromise ceiling that matches a tool's actual job. The rental attack only works under the first model, because completing login as the user was the entire design.

Notice what the flow required: no stolen credential, no endpoint malware, no protocol flaw. A live IdP session, a prior consent grant for a first-party-looking client, and a browser the agent controls — the provider saw a returning user and answered with a redirect. The same chain against a corporate IdP is worse: the attacker's page becomes a front door that mints the victim's intranet identity, and the session it produces is indistinguishable from theirs in every downstream log.

What Should the Agent Be Allowed to Ask For?

Scope, audience, lifetime — get any of the three wrong and even a clean architecture leaks. The MCP authorization spec (2025-06-18 revision) is unusually blunt: servers are OAuth 2.1 resource servers, tokens must be validated, and forwarding a token to a downstream API — passthrough — is banned outright. The spec's stated reasons are the mechanism: a token minted for one service and spent at another breaks audience validation, and once a token is spendable everywhere, attribution dies with it — the audit trail converges on whatever identity the token claims. Audience binding is what makes "this token only works there" true: the client sends a resource parameter (RFC 8707), the issued token carries the audience in its aud claim, and the downstream API rejects anything minted for anyone else. Scope granularity exists off the shelf — GitHub's fine-grained tokens do per-repository, per-permission grants: issues:read on two repos instead of a blanket scope over everything private. When a provider can't express grants at that grain, treat the provider as part of your threat model.

One Identity or Many?

A single shared service account is what everyone ships — one identity, all tools, production credentials, created in an afternoon. Its failure math is brutal: a compromised tool borrows the whole wallet, one leaked secret costs every integration at once, and the logs show one identity doing everything, which makes anomaly detection nearly useless. Per-tool principals invert that. A hijacked tool can do what that tool does — which is its legitimate job — and nothing else. Logs decompose into per-identity streams you can actually baseline: the comment tool hitting the issues API four hundred times a minute is loud when that principal normally posts a few comments an hour. The standing objection is credential sprawl, and it's dated — workload identity federation and modern secrets managers mint short-lived, per-service credentials as configuration. Sprawl with small grants beats concentration with a large one every time you run the numbers. Worth separating from runtime policy, too: what a principal may do is enforcement, who it is on the wire is identity, and you need both — enforcement without identity gives you an unlabeled failure zone.

What Does 'Read-Only' Mean When the Tool Describes Itself?

Permissions are granted against descriptions, which makes the tool manifest the load-bearing document in your whole authorization model — and nobody wrote it under your review. Two failure modes matter. The description can lie at registration: the tool-poisoning demonstrations in early 2025 shipped MCP servers with instructions hidden in description fields — the human approving the tool sees "fetches weather data," and the model reads the rest. And the description can change after approval, because most clients silently re-read the manifest on every reconnect without diffing so much as a line. The controls follow from the mechanism: pin the server to a version or content hash, diff the tool list and every description on each connect, treat any change as a fresh permission request, and keep an inventory of reviewed manifests so re-approval is a decision rather than a reflex.

How Much Can One Yes Do?

Approval answers "may the agent call this tool?" — the sharper question is "what can one call do?" A tool with no ceiling turns a single hijacked call into a batch job. Put numbers on the danger: row caps enforced by the receiving API from the token's claims (maxRows in the capability above), dry-run as the default mode for anything that mutates state, and read and write split across separate principals so no sentence in the context window can argue a read identity into writing — there is no write scope on the token to escalate to. Hold just-in-time elevation for the rare legitimate bulk write: the agent requests elevation, policy or a human bounds it, and it expires on its own. Enforcement location is what makes a cap real — a limit the agent is merely told about is a suggestion; a limit the API computes from the token is a control.

When It Goes Wrong, Can You Say Who Did It?

Every privileged call should log a triple: which agent, through which tool, on whose delegation. That's the attribution the MCP spec had in mind when it banned passthrough — with forwarded tokens the audit trail converges on the user, and the agent vanishes from its own incident. Build the revocation ladder as well, because stopping an agent mid-incident is a sequence: revoke the capability grant (jti makes it surgical), then the refresh tokens, then disable the tool principal, then the agent itself. Run the test now rather than during the incident: ask your SOC which agent wrote the row they're staring at. If the only honest answer is a person's username, the delegation happened in a chat message instead of in design, and the investigation starts an hour behind.

• ▪For every agent in production, write down whose token touches each hop. Any passthrough hop goes to the top of the backlog — it's the one fix that removes an entire attack class.
• ▪Give each tool its own principal this sprint; workload identity federation and your secrets manager make per-tool credentials a configuration task, not a project.
• ▪Send resource= on every token request, then decode the token and verify aud — don't take the IdP's word for audience binding.
• ▪Time-box refresh tokens, rotate on use, and wire their revocation into the agent's kill switch; access-token expiry alone is theater.
• ▪Split read and write into separate principals, put row caps and dry-run defaults on anything that mutates state, and reserve JIT elevation for genuine bulk writes.
• ▪Pin tool servers to a version or hash, diff manifests on every reconnect, and treat a changed description as a new permission request.
• ▪Log agent + tool + delegating user on every privileged action, and confirm someone outside the team can answer "which agent did this" from logs alone.
• ▪Expire every agent grant by default and force renewal on a schedule — a permission review that doubles as a liveness check on agents nobody remembers deploying.