Least Privilege

In classical systems, least privilege meant giving a UNIX process only the file permissions it actually needed. That was already hard to enforce. For agents it becomes structurally different, because privilege is no longer a single static attribute. It is the live union of every tool the agent can invoke, every memory namespace it can read or write, and every downstream agent it can delegate to. This same delegation risk is why Separation of Duties and Microsegmentation must be designed in from the start rather than retrofitted. And that union shifts at runtime: an orchestrator spins up a sub-agent and hands it a toolset “to be flexible,” and the effective privilege of that sub-agent at that moment is the product of tools × data × network reach, none of which was individually reviewed.

The right mental model is zero standing privilege. A human developer has a persistent SSH key because they work interactively and re-authenticating every keypress is absurd. An agent does not need persistence in the same way: it has a declared task, and the credential should exist only while that task runs. “Scoped to the task” means three-dimensional (task × resource × action), not just a broad service role. An agent creating a Jira ticket should hold a permission that reads roughly “create tickets in project ABC, fields summary and severity, at most five per minute.” The phrase “access Jira” is not a scope; it is the absence of one.

The interaction with non-determinism makes over-privilege especially dangerous. A human with excessive database access makes one deliberate choice at a time. An agent with excessive access is running a probabilistic search over all reachable tool-call sequences, including sequences an attacker can guide via injected text. Every extra permission widens the space of sequences that end in harm. That is why the scope must be established before the task starts, from an external broker, and must not be expandable by the agent itself.

Scenario: the standing database credential

A support agent is provisioned with a long-lived database service account to “check order status.” An attacker pastes a SQL fragment into a support ticket. The agent, faithfully trying to complete its task, constructs and runs a query. Because the credential has broad read access, the injection extracts the full customer token table. With per-task, read-only credentials scoped to the current ticket’s order ID (issued by a broker at task start, expiring when the task closes), the same injection finds nothing worth retrieving and has nowhere to send it.

Scenario: the over-tooled coding agent

A developer assistant is provisioned with fifty tools “for full flexibility”: code execution, file read/write, git push, email, external HTTP. A malicious comment in a dependency package triggers a prompt injection. Because the agent has code-execution and HTTP tools simultaneously, a single injection is enough to exfiltrate secrets from the working directory. The five tools the agent genuinely needed for the declared coding task (read file, write file, run tests, open PR, query docs) would not have given the injection that combination.

How it fails

• Agents carry long-lived API keys or service credentials in context or memory, so a successful injection has standing access rather than a task-scoped window.
• MCP and A2A grants are expressed as broad roles (“can use all tools on this server”) rather than per-task capability tokens.
• Agents are provisioned with tools “just in case,” on the assumption that unused tools carry no risk; that assumption ignores that a prompt injection can call any tool the agent can invoke.
• Sub-agents inherit the orchestrator’s credential scope without any reduction, so delegation multiplies rather than narrows privilege.
• No one runs a periodic audit to remove grants that have silently accumulated over time.

Why the mapped controls work

Just-in-time credentials from a broker, with a time-to-live tied to task duration, make standing access structurally impossible: there is nothing to steal from context because the credential doesn’t exist between tasks. Per-tool permission profiles enforced at a tool gateway mean the agent’s declared capability set is evaluated by a deterministic policy engine, not inferred from a prompt; the model cannot grant itself new tools mid-session. Periodic removal of unused grants catches accumulation over time, the equivalent of access-review for human accounts applied to agent toolsets. Together these controls close the three failure paths: no credential to steal, no undeclared tool to call, no privilege that survives the task.

First steps

1. Audit every agent’s current tool set and remove any tool not required for its declared task today. Use your MCP server’s capability manifest or your agent framework’s tool registry to produce a list, then challenge each entry with “does this specific task need this tool right now?”
2. Replace long-lived API keys or service credentials in agent context with just-in-time tokens issued by a secrets broker (HashiCorp Vault, AWS Secrets Manager, or similar) scoped to task × resource × action with a TTL matching the task duration.
3. Add a periodic grant-review step to your sprint or operational calendar. Export the current tool grants for each agent (from your tool gateway or IAM policy store) and confirm that nothing has accumulated silently since the last review.

Concrete example: a scoped OAuth token for a support agent:

scope=jira:issues:create project=ABC max_rate=5/min ttl=3600

This token authorises ticket creation in one project only, caps throughput, and expires in an hour. The “access Jira” service role is not a substitute for it.