Why Agent Tool Use is an Identity Problem, Not a Prompt Problem

Somewhere right now, an enterprise is deploying an autonomous agent with a system prompt that looks something like this:

You are a helpful database query assistant.
You must ONLY read records where tenant_id = 42.
Never run DROP, DELETE, or UPDATE.
Never disclose employee compensation records.
Always be polite.

Under the hood, the orchestrator has handed the LLM agent a raw PostgreSQL connection string with SUPERUSER privileges or an AWS IAM role with s3:* across the entire analytics data lake.

Let's be completely candid: this is not software architecture. This is cargo-culting safety through the medium of English prose. It is the cloud equivalent of giving a stranger a skeleton key to every room in your building, accompanied by a polite Post-it note asking them not to open the executive washroom.

If your authorization boundary depends on a 70-billion-parameter next-token predictor deciding to obey your instructions rather than an adversary's jailbreak prompt, you do not have a security model. You have a wish list.

1. The 1988 Confused Deputy Problem (Re-Invented in Python 3.12)

In 1988, Norm Hardy coined the term Confused Deputy to describe a security vulnerability where a program with legitimate authority is tricked by an unprivileged client into misusing its authority on the client's behalf.

For thirty years, systems architects built capability-based security, cryptographic tokens, and fine-grained authorization matrices (FGAP) specifically to eliminate confused deputies. We learned—painfully—that privilege must be tightly bound to intent.

Then generative AI arrived, and the industry collectively decided to pretend these lessons never happened. Consider what happens when Alice asks an orchestrator agent: "Summarize my open PRs and clean up stale test branches on GitHub."

When the agent calls the GitHub API, who is the caller?

• Is it Alice? If the agent passes Alice's personal access token (PAT), it is impersonating Alice with 100% of her authority—including the power to delete production repositories or approve its own malicious commits.
• Is it the agent? If the agent presents its own static machine service account, the destination server has no cryptographic proof that Alice ever authorized this specific call.
• Is it the subagent? What if the orchestrator spins up three parallel workers to parse ASTs? Do all three inherit root?

2. The Bearer Token Lie

RFC 6749 bearer tokens were designed for a boring, two-party world: a human user logs in via a browser client, and the client presents an opaque string to a backend resource server. Possession of the token is proof of authority.

In autonomous agent topologies, however, execution graphs look like this:

User (Alice) ──> Orchestrator Agent ──> Specialized Worker Subagent ──> GitHub Tool API

If you pass Alice's bearer token down the line, you violate every principle of least privilege (Saltzer & Schroeder, 1975). The worker subagent now holds unconstrained authority across Alice's entire account.

If you instead mint an isolated token for each subagent without recording the delegation chain, you completely sever the enterprise audit trail. When an unauthorized commit lands on main, the audit log simply records: Action executed by agent-worker-4. Who authorized it? Why? Under what user intent? The chain of custody is gone.

3. The Real Wire Architecture: RFC 8693 Token Exchange

We do not need to invent speculative cryptographic protocols. The identity architecture community already solved this: it is called RFC 8693 (OAuth 2.0 Token Exchange).

Instead of handing an agent raw credentials or static bearer tokens, the orchestrator presents Alice's subject token to the Authorization Server and requests an attenuated, cryptographically bound delegation token, explicitly declaring its own actor identity:

POST /oauth/v2/token HTTP/1.1
Host: auth.acme.corp
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJhbGciOi... (Alice's access token)
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=eyJhbGciOi... (Agent-X's authenticated service identity)
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&scope=repo:read pull_requests:read
&audience=https://api.github.com

The resulting token issued by the authorization server carries the RFC 8693 act (actor) claim:

{
  "iss": "https://auth.acme.corp",
  "sub": "alice@acme.corp",
  "aud": "https://api.github.com",
  "scope": "repo:read pull_requests:read",
  "exp": 1730419200,
  "act": {
    "sub": "agent-orchestrator-9",
    "client_id": "agent-orchestrator-9"
  }
}

Notice what happens at the wire level:

• Attenuated Authority: The subagent's scope is mathematically downscoped (repo:read, not repo:admin). Even if prompt injection compels the agent to issue a DELETE /repos call, GitHub rejects it at the HTTP boundary.
• Audience Confinement: The token is cryptographically locked to https://api.github.com. If the agent is tricked into calling an attacker's webhook, the token is worthless.
• Dual Identity & Non-Repudiation: GitHub knows the subject is Alice, but the actor executing the call is agent-orchestrator-9. The audit log preserves both identities without ambiguity.

4. The Non-Human Identity Trap: Revocation Cascades

Here is the dirty secret of modern identity servers: almost none of them handle delegation cascades properly.

Suppose Alice is terminated at 2:00 PM on Friday. The security team clicks "Deactivate User". Her primary access token is revoked via RFC 7009. Her SSO session dies instantly.

What happens to the background agent that exchanged her token at 1:55 PM with a 60-minute TTL?

In almost every major open-source identity server running in enterprise clusters today, downstream exchanged tokens are completely orphaned. They remain fully active and valid until cryptographic expiration (exp). An agent running an autonomous loop will continue mutating enterprise infrastructure for another 55 minutes after the user who authorized it has been escorted out of the building.

5. The Way Forward

If you are building multi-agent systems, stop treating tool security as a prompt engineering problem. Stop writing polite instructions in markdown system prompts and hoping the model doesn't hallucinate.

Treat every agent invocation as a cross-domain authorization boundary. Enforce least-privilege capability confinement at the wire level, mandate RFC 8693 actor chains in Model Context Protocol (MCP) tool dispatch, and ensure your identity plane supports downstream revocation cascades.

Boring protocols, sound mathematics, and deterministic invariants will protect your enterprise. System prompts will not.