Your Agent Is Not a User: Giving AI Agents Their Own OAuth Identity with Scoped, Revocable Credentials

The Real Business Bottleneck#

Sharing user credentials with an agent is a security and identity problem, and it surfaces in enterprise sales cycles before it surfaces in incident reports.

When an enterprise buyer evaluates your AI product, one of their first questions is not "what model does it use?" It's "whose credentials does the agent use when it calls our systems?" If the honest answer is "the user's token," you will hear the deal stall. Sharing a human's OAuth token with an agent conflates audit trails. Every action the agent takes looks like something the human did, both to the identity provider and to the downstream API. It also makes least-privilege impossible, because the agent inherits whatever the human can do, including the scopes — the individual permissions the user agreed to hand over; that the agent has no business touching.

That conflation is exactly what the emerging standards work targets. The IETF's Agent Authorization Profile (AAP) for OAuth 2.0 (draft-aap-oauth-profile-01) formalizes agent-specific OAuth flows. Vendor guidance from WorkOS ("Give your AI agents their own credentials") and Okta's "Securing AI Agents From Development to Enterprise Scale" whitepaper describe the two patterns you'll actually deploy: on-behalf-of (OBO) token exchange, where the agent swaps its own credential for a short-lived token that carries one user's context, and workload identity, where the agent holds credentials of its own the way a new employee gets a badge instead of borrowing the CEO's.

The cost angle is real too. A security review that ends in "we need custom identity work" is weeks of engineering time and a delayed launch. A demo where the buyer can see an agent that shows up in the logs as its own actor, a scoped token, and per-agent revocation collapses that conversation into an afternoon.

Why Naive In-Prompt Solutions Fail#

The instinctive fix is to handle it in the prompt or the agent harness: "Only call read endpoints," or "the user approved these actions, so act on their behalf." This fails for reasons that are structural, not stylistic:

• Prompts are not enforcement points. The API you call has no idea what your system prompt said. If the agent holds a token with write:invoices and a jailbreak, hallucination, or tool-confusion event sends it toward the write endpoint, the API honors the token. Authorization happens at the resource server, the API that actually holds the data, and the only lever you control there is the credential you present.
• Scope inheritance is all-or-nothing. A user token carries the union of everything the user consented to. You cannot subtract scopes at runtime. "The agent should only read" is a policy statement with no mechanism behind it.
• Audit logs stop telling the truth. When your agent acts as the user, your logs say the user did things the user never did. Reverse-engineering an incident means separating human actions from agent actions after the fact, and nothing in the records can prove which of them did what.
• Revocation is a sledgehammer. The only way to cut off a misbehaving agent sharing a user token is to revoke the user's session; kicking the human offline to stop the software. With per-agent credentials, you revoke one client, one grant, one set of scopes.

None of these are prompt-engineering problems. They are identity problems, and identity problems have a standards track.

Production Architecture & Code Blueprints#

The architecture rests on two separate identities:

1. The agent is a first-class OAuth client. It registers with the authorization server as its own client (workload identity) with its own client credentials and a narrowly scoped grant; say, offline_access plus a machine scope like agent:act.
2. Downstream access flows through token exchange (OBO). When the agent needs to act in the context of a user, it presents its own credential and exchanges it via the OAuth 2.0 Token Exchange grant (RFC 8693) . The token is short-lived and scoped to the user's context, carrying only the permissions the agent is allowed to exercise. The resource server sees a token whose act claim names the agent; the software doing the work; and whose sub names the user; the person it acted for; which is precisely the audit story the AAP draft is written for.

Keycloak runs this entirely in containers, so you can build the reference demo without any paid API. Here's a runnable blueprint:

# 1. Run Keycloak locally
docker run -d --name keycloak -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak start-dev

# 2. In the Keycloak admin console (localhost:8080):
#    - Create realm "agents"
#    - Create client "agent-svc" (confidential, service account enabled)
#      -> assign ONLY the "agent:act" role/scope; do NOT grant user-level scopes
#    - Create client "orders-api" (bearer-only) protecting your resource server

# 3. Agent obtains its OWN credential (client credentials, workload identity)
curl -X POST http://localhost:8080/realms/agents/protocol/openid-connect/token \
  -d grant_type=client_credentials \
  -d client_id=agent-svc \
  -d client_secret=$AGENT_SECRET \
  -d scope="agent:act"
# -> agent_token (sub = agent-svc, NOT a human)

# 4. On-behalf-of exchange: swap agent identity for a user-scoped, agent-stamped token
curl -X POST http://localhost:8080/realms/agents/protocol/openid-connect/token \
  -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
  -d client_id=agent-svc \
  -d client_secret=$AGENT_SECRET \
  -d subject_token=$AGENT_TOKEN \
  -d requested_subject=$USER_ID \
  -d scope="orders:read"
# -> delegated_token (sub = user, act = agent-svc, scope = orders:read ONLY)

# 5. Call the protected API with the delegated, scoped token
curl -H "Authorization: Bearer $DELEGATED_TOKEN" http://localhost:9000/orders

# 6. Revocation: kill the agent's grant without touching any human session
curl -X POST http://localhost:8080/realms/agents/protocol/openid-connect/revoke \
  -d client_id=agent-svc -d client_secret=$AGENT_SECRET \
  -d token=$AGENT_TOKEN

The critical detail is step 4: the requested scope (orders:read) is a subset the authorization server enforces against the agent's policy, not a scope the agent can simply request. If your agent policy says it may only read orders, the exchange refuses to mint a token with write scopes no matter what the agent's prompt or plan says.

Compare this with the naive pattern of handing the agent the user's access token directly. In that pattern:

• The resource server logs show the user as actor, with no act claim.
• The token carries every scope the user consented to.
• Revocation means revoking the user.

You can demonstrate the difference in the same container stack in an afternoon, which is the entire point: this is a buildable artifact, not a slide.

Financial/ROI Impact for Founders#

None of the sources above publish specific dollar figures for this pattern. So instead of an invented ROI multiple, here is the arithmetic a founder can fill in with their own pipeline data:

• Deal-unblocking value. Agents acting with human credentials is a known enterprise-blocker for AI adoption. If even one mid-market deal stalls on "whose credentials does the agent use?", compare the cost of that stalled cycle (your sales time plus the delayed contract value) against the cost of a build measured in days. The local demo above requires only Keycloak and a small API.
• Incident-cost avoidance. Per-agent credentials with act claims turn a forensic investigation from "interview everyone whose account was used" into "query tokens where act = agent-svc." The cost differential is real but context-specific; measure it as your average security-incident response cost versus a log query.
• Limited damage from a compromised agent. A scoped agent token caps what a compromised or hallucinating agent can touch. The value is the avoided cost of the excess scope, which is unbounded in the shared-token case and bounded by design in the agent-identity case.

The honest framing: nobody publishes a verified ROI table for agent identity yet. What is verifiable is that the pattern is standardized (IETF AAP draft), documented by major identity vendors (WorkOS, Okta), and runnable locally at near-zero infrastructure cost. That combination makes it one of the cheapest credible trust signals you can attach to an enterprise AI pitch.

What to Measure in Your Own Build#

Since the demo is fully local and reproducible, instrument it before you show it:

1. Audit distinguishability. Hit your resource server twice; once with the user's token, once with the delegated token; and show the log lines: one reads as the human, the other names both the user and the acting agent.
2. Scope enforcement. Attempt the token exchange requesting a scope the agent isn't allowed, and show the denial. This is your least-privilege proof.
3. Revocation latency. Revoke the agent's grant mid-session and time how long until the next API call fails. Short-lived delegated tokens bound this delay to the token's remaining lifetime; the number is yours to report.

None of these require external APIs or paid tiers. Every part of the automation runs in containers on your own machine, so your security reviewer can rerun the whole thing themselves.

Clear CTA#

Agent identity is the kind of work that looks like a security nicety until the first enterprise security review makes it a launch blocker. effloow builds exactly this: we help teams harden AI systems for enterprise adoption through our security and infrastructure services, and our Proof Studio turns patterns like per-agent identity, OBO exchange, and scoped revocation into demonstrable reference builds your buyer's security team can inspect. If you want to walk into your next security review with a working agent-identity demo instead of a roadmap promise, talk to us.