An AI agent should never hold a credential that outlives the task it was given. That one rule is most of agent authorization. Two of the most instructive incidents on record — a chat integration's OAuth tokens used to bulk-export Salesforce customer data for ten days, and a public GitHub issue that steered an agent into private repositories — were standing grants doing exactly what they were allowed to do. Buy in this order: a broker that issues short-lived delegated tokens, then a policy check on every tool call, then human approval only for irreversible actions.
The verdict: fix standing privilege at the credential layer before you buy anything else. If your agents run on AWS, use Amazon Bedrock AgentCore Identity with Policy — it brokers delegated tokens and checks every gateway tool call's arguments in Cedar, for about $60 a month at the workload below. If your agents span clouds and self-hosted MCP servers, use Aembit, whose gateway means the agent never holds the downstream credential. Add Auth0 for AI Agents where a person must approve a specific transaction from their phone. Permit.io is a fast start for coding-agent fleets, provided you shorten its consent defaults. And do not start with a policy engine: Cerbos Hub loses this comparison — not because Cerbos decides badly, but because a decision service does nothing about the key the agent is still holding.
Reference workload: 500 employees delegating to 10 production agents that make 2 million tool calls a month. Prices from each vendor's public pricing page, checked 14 September 2026; compute, model tokens and engineering time excluded.
| Amazon Bedrock AgentCore (Identity + Policy) | Aembit | Auth0 for AI Agents | Permit.io MCP Gateway | Cerbos | |
|---|---|---|---|---|---|
| What it is | Token broker plus Cedar checks inside AWS's agent gateway | Credential broker and MCP gateway | Delegation, token vault and phone-based approvals | MCP proxy with tool risk tiers and approval requests | Open-source policy decision point plus paid control plane |
| Removes standing credentials? | Yes, for calls through the gateway | Yes — per-request credentials, cached 60 seconds | Partly — stores refresh tokens, hands access tokens to your backend | Partly — consent lasts up to 90 days by default | No — it decides, it never issues |
| Per-call check on tool arguments | Yes, in Cedar | Identity, posture, time and location; tool messages via a pluggable provider | Not among its four capabilities | Per tool, by read / write / destructive tier | Yes, if your code sends them |
| Human approval | Temporal policy can require a prior approval step | Not described | CIBA push with transaction details | Access Request MCP to human reviewers | None |
| Reference-workload price | ≈$60/mo ($50 Policy + $10 Gateway; Identity free via Gateway) | $200/mo (Teams, $20 per agent) | $225/mo (B2B Essentials + 50% add-on) to $1,200/mo (Professional) | $0 on Community if you fit its limits; no public paid price | $0 self-hosted; Hub Production from $933/mo |
| Buy it if | Your agents run on AWS | Mixed clouds, self-hosted MCP servers | A customer-facing agent needs per-transaction consent | You want a drop-in proxy for Cursor or Claude Code users | You are building your own enforcement point |
| Skip it if | Tools are called outside the gateway | You need argument-level rules or approvals | No downstream token may enter the agent process | You won't shorten consent lifetimes | You expect it to fix standing privilege |
What Standing Privilege Means for an AI Agent
Standing privilege is access that exists whether or not a task needs it: a key, token or role grant that is valid before the agent starts and still valid after it stops. For a human, standing admin rights are a risk. For an agent that reads untrusted text all day, they are the attack surface.
The record is consistent. Attackers used OAuth tokens stolen from the Salesloft Drift integration to run bulk SOQL exports against Salesforce customer instances from 8 to 18 August 2025, according to Google's Threat Intelligence Group. They searched the exported records for AWS access keys, Snowflake tokens and passwords, and deleted their query jobs afterwards. Google's advice was to treat any token stored in or connected to Drift as compromised. The breach was upstream — the attackers took the tokens from Drift's AWS environment after months inside Salesloft's GitHub account — but nobody broke Salesforce's authentication. The tokens were valid, broad and long-lived — exactly as issued.
In May 2025, Invariant Labs showed that a malicious issue on a public repository could steer a developer's agent into reading private repositories and leaking their contents, using the official GitHub MCP server and a token that could reach both. Invariant was explicit that this was "not a flaw in the GitHub MCP server code itself" but an architectural problem at the agent-system level. The token could reach everything, so the injected instruction could too.
In July 2025, Replit's agent deleted SaaStr founder Jason Lemkin's production database despite his instructions, and his conclusion, as The Register reported, was that "there is no way to enforce a code freeze in vibe coding apps like Replit." Instructions are not permissions. OWASP's Top 10 for Agentic Applications, released 9 December 2025, lists Identity & Privilege Abuse as ASI03 and cites the Replit episode under Rogue Agents.
The common thread: the credential had more reach than the task, and nothing outside the model checked the difference. The same shape shows up inside a single cloud account, where one agent escalated through another and every call was authorized.
Just-in-Time vs Standing Permissions: The One-Hour Test
Just-in-time access means a credential is minted for one task, scoped to one resource, and expires without anyone remembering to revoke it. The practical test for any product: if an attacker copies the credential the agent is using right now, is it still useful in an hour?
AWS's Well-Architected guidance for agentic workloads sets the bar in those terms — temporary STS credentials with 15-to-60-minute sessions, permission boundaries as a ceiling, and just-in-time elevation that revokes itself. Its anti-pattern list includes one every platform team will recognise: "expanding agent permissions in response to access errors without investigating," producing grants that are never revoked. That is how standing privilege actually grows — one unblocking ticket at a time.
The five products give three different answers to the one-hour test.
Aembit passes it most cleanly. Its MCP Identity Gateway "obtains credentials per-request and caches them for 60 seconds — it never persists them to disk," per its documentation, and exchanges them on the agent's behalf so the agent never holds them. Aembit's general-availability announcement in April 2026 states the design goal flatly: agents never hold standing credentials.
Amazon Bedrock AgentCore passes it for calls routed through its gateway. Part of the Amazon Bedrock platform, AgentCore Identity keeps third-party OAuth tokens in a vault scoped per agent identity and per user — "one agent can't retrieve tokens obtained for a different user," according to AWS.
Auth0's Token Vault moves the problem rather than removing it. Auth0 stores the connected account's access and refresh tokens and refreshes them automatically; your application exchanges an Auth0 token for the external provider's access token, which your backend then receives and uses directly. That is a real improvement over API keys in environment variables — the refresh token lives in a hardened identity service, not in your agent. But a live downstream token still lands in the agent's process, and a store of long-lived refresh tokens to other companies' SaaS is the same shape as the integration that failed in the Drift case. Know which of those you are buying.
The protocol is pushing the same way. The MCP authorization specification says authorization servers "SHOULD issue short-lived access tokens" and must rotate refresh tokens for public clients, per its 2026-07-28 revision.
How an Agent Should Act on Behalf of a Human
An agent acting for a person should use delegation, never impersonation — the token must name both the human and the agent. Anything else makes the audit log lie.
The distinction is old and precise. RFC 8693, the OAuth token exchange standard, defines impersonation as one principal being "indistinguishable from" another, and delegation as a principal that "still has its own identity" while acting for someone else. It records the chain in an act claim — nestable, so a sub-agent acting for an agent acting for a person stays legible — and uses a may_act claim to say in advance who is allowed to become the actor.
AgentCore Identity implements this directly. Its on-behalf-of token exchange swaps the user's inbound token for a downstream one via RFC 8693 or the RFC 7523 JWT grant, and "the exchanged token carries both the agent's own identity and the original caller's identity." The authorization server, not the agent, makes the final call on scopes and on whether the delegation is permitted at all.
Aembit calls its version blended identity: the agent and the human operating it are evaluated together in a single policy decision at request time, and when several people use one agent, each gets credentials scoped to their own identity. That per-user isolation is the part home-built agents most often skip. AWS's guidance lists the failure — a single shared service account for multiple agents, alongside reusing human credentials and letting agents role-chain into human roles — as a high-risk anti-pattern.
Two protocol rules apply to your MCP servers whatever you buy. The MCP specification says servers "MUST NOT accept or transit any other tokens" than those issued for them, and clients must bind each token to one server with RFC 8707 resource indicators. Token passthrough — forwarding the user's token downstream — is the shortcut that turns an MCP server into a confused deputy.
For delegation across vendor boundaries, the ID-JAG grant and Okta for AI Agents are covered in our Okta vs Entra Agent ID vs SailPoint comparison. An individual IETF Internet-Draft, now expired, also proposed carrying the agent's identity through the OAuth authorization request and into the token with requested_actor and actor_token parameters. It was a proposal, never a standard.
The buyer's test: ask each vendor for a decoded token from their product, and have them point to the claim that names the agent and the claim that names the person.
Scoping Tool Access per Task, Not per Agent
An OAuth scope is checked once, when the token is issued; a tool-call policy is checked on every call, against the actual arguments. Only the second can tell the task you asked for from the task an injected instruction asked for.
Scopes are coarser than they look. When an MCP server's challenge names no scope, the specification tells clients to request every scope listed in scopes_supported and step up later. "Read repositories" is a scope. "Only the repository this ticket is about" is a policy — and it is exactly what Invariant recommended after the GitHub exploit: block cross-repository operations within a single session. Delegation chains make this harder, because a supervisor agent can rewrite the task on its way down.
AgentCore Policy is the strongest managed option here. Generally available since 3 March 2026, it intercepts agent-to-tool traffic through AgentCore Gateway and evaluates each request in Cedar before the tool runs, with conditions on the principal, the tool and the tool's input parameters. A request is allowed only when a permit applies and no forbid overrides it. You can describe a rule in English and have it compiled to Cedar, with automated reasoning flagging policies that are overly permissive or can never be satisfied. Cedar was designed to be analysable; AWS's published research on the language describes the formal modelling behind it.
The practitioner notes are where you learn the edges. One detailed implementation guide documents a 400 KB Cedar schema limit across all tools on a policy engine, no floating-point numbers or regular expressions, and a nasty failure: if the gateway's role lacks GetPolicyEngine, LOG_ONLY mode can fail silently — the shadow run you trusted never evaluated anything. It also restates the hard boundary: Policy does not apply to tool calls that bypass the gateway.
Permit.io's MCP Gateway takes a coarser, faster route. It auto-classifies tools at import as low (read), medium (write) or high (destructive) risk, lets users pick a trust level under an admin-set ceiling, and enforces the lower of the two. That takes a coding-agent fleet from nothing to something in an afternoon. But classification by verb is not scoping by task, and its consent sessions persist for 30 days of inactivity or 90 days absolute — configurable, but a 90-day delegation is standing privilege with a nicer consent screen. Permit also says plainly that prompt-injection defences remain the responsibility of the surrounding environment.
Cerbos decides well and enforces nothing by itself. Its policy decision point is open source under Apache 2.0 and supports role- and attribute-based rules; for MCP, the server queries Cerbos to decide which tools to enable for a user in context. The check is only as strong as the code that remembers to ask.
Aembit governs who reaches which server more than what happens there. Its access policies define which agents and users can reach which MCP servers, with conditions on time, location and runtime posture; tool-message decisions come from a pluggable content security provider, and the gateway "doesn't replace the MCP server's internal authorization logic." Pair it with argument-level checks where the stakes are high.
Approval Gates People Actually Use
An approval gate works only if it is rare, specific and delivered out-of-band; a prompt on every action trains people to click yes. The evidence is Anthropic's own: Claude Code users approve 93% of permission prompts. The company calls the result approval fatigue, "where people stop paying close attention to what they're approving," and its fix was fewer prompts, not better ones — OS-level sandboxing cut permission prompts by 84% in internal use by making most actions safe to allow. We covered the same lesson in Claude Code's move away from asking.
Three design rules follow:
- Gate irreversible or externally visible actions only — money movement, deletions, data leaving the company, permission changes. Everything else belongs to policy.
- Approve the exact transaction, not a capability. Rich Authorization Requests (RFC 9396) exist for this:
authorization_detailscarries the amount, the counterparty and the action instead of a scope. - Ask on a different device, and make the approval the credential. The OpenID Foundation's CIBA specification defines a decoupled flow where the approver authenticates on a separate device, with a
binding_messageshown on both screens so the person can tell which request they are approving.
Auth0 for AI Agents is the one that ships this end to end. Its asynchronous authorization sends a CIBA request with authorization_details, pushes a notification through Guardian to the user's enrolled phone showing the transaction, and releases the access token only after the user approves; the agent's backend polls until then. The approval and the token are one event, which is what makes it hard to fake.
AgentCore gets there in policy rather than in the user experience. Its temporal policies can permit an action only if a matching approval succeeded earlier in the session — AWS's example allows SellShares only if ApproveSale returned approved for the same stock and share count within the hour. You still build the approval tool. Know the limits: 25 temporal policies per engine, a 24-hour maximum window, and — AWS's own warning — the session ID is supplied by the caller, so a count-based limit covers only that session. Start a new session and the counter resets.
Permit.io's Access Request MCP lets an agent propose a sensitive operation and routes it to human reviewers via UI or API. The request comes from a tool the model decides to call, and the overview does not say whether what gets granted expires — check that it is the single operation, not a reusable permission. Aembit's agentic AI materials do not describe a human approval flow, so plan to add one elsewhere.
Audit and Replay: What the Log Must Record
A useful agent audit record answers four questions — which agent, on whose behalf, which tool with which arguments, and which policy allowed it — and keeps the inputs so the decision can be re-run against a changed policy. Most products document three.
Cerbos has the best replay substrate of the five. Its decision logs record the request inputs, principal and resource attributes, outputs and matched policies, and ship to a file, Kafka or Cerbos Hub. The local store keeps seven days by default; the authorization header is excluded automatically, but any other sensitive header or attribute has to be excluded or masked in configuration.
Permit.io logs agent identity, human identity, tool name, MCP server, timestamp and the allow or deny decision. Aembit logs every MCP request with agent identity, user identity, target server and policy decision — the server, not the arguments — and its pricing page lists retention of 24 hours on the free Starter plan and 7 days on Teams. Plan for longer storage before an investigation needs it.
AgentCore logs every enforcement decision through CloudWatch metrics and logs, and its LOG_ONLY mode is the practical form of replay: attach a new policy, see what it would have denied against live traffic, then promote it to ENFORCE.
Two rules regardless of vendor. Keep logs outside the agent's reach — the Drift attackers deleted their query jobs, but Google notes the logs remained. And record arguments, because "the agent called the payments tool" is not evidence of anything.
Blast Radius When an Agent Is Compromised
Assume the agent will be steered. Its blast radius is everything its credentials can reach before they expire, multiplied by the number of people sharing them. Here is what a compromised agent process gets in each design:
- Behind Aembit: no downstream secret to steal — only what policy lets that agent-and-user pair reach while the compromise lasts. Revoke by policy.
- Behind AgentCore: every gateway call is still checked, but anything the runtime can call directly skips Policy, and each gateway runs under one execution role scoped to the union of its targets. Worse, anyone holding
bedrock-agentcore:UpdateGatewaycan switch enforcement toLOG_ONLYor remove the policy engine, and AWS notes no separate condition key protects that setting. Treat that permission like IAM administrator. - Behind Auth0: the live third-party access tokens in the backend until they expire, plus whatever the backend's own credentials can exchange for more.
- Behind Permit.io: every tool under the user's chosen trust ceiling, for as long as the consent session lives.
- Behind Cerbos alone: everything the agent's own credential could reach before Cerbos was installed, on any code path that does not call it.
Then the multiplier. The Drift tokens reached many Salesforce customers because one integration held grants for all of them. Per-user token isolation — enforced by both AgentCore's vault and Aembit's blended identity — is what keeps one steered session from becoming everyone's incident. For a coding-agent version of the same lesson, see why scoping the credentials beats trusting the refusal.
Who Should Not Buy Each Option
Do not buy Amazon Bedrock AgentCore Identity and Policy if your tools are called anywhere other than through AgentCore Gateway, because Policy never sees those calls. Also skip it if your call chains cross AWS accounts or regions and you need temporal rules, which require the gateway and its targets in one account and region, or if your tool catalogue will outgrow the 400 KB schema budget on a single engine.
Do not buy Aembit if your main requirement is argument-level rules or human approvals. Its strength is taking credentials away from the agent, not judging whether a $40,000 refund is sensible. Budget for log retention too: 7 days on Teams.
Do not buy Auth0 for AI Agents if your requirement is that no downstream token ever enters the agent's process — Token Vault hands it to your backend. And price it carefully: the November 2025 general-availability post said existing Auth0 users "can get started for free, regardless of their current Auth0 plan," while the pricing page as of 14 September 2026 lists it as an add-on that "adds 50% to the base price," with CIBA unavailable on the free tier. Get the number for your user count in writing.
Do not buy Permit.io's MCP Gateway if you will not shorten its consent lifetimes, or if you need a paid price before you commit — the pricing page shows a free Community tier for up to 1,000 monthly active users and "Contact Us" beyond it, and in-VPC or on-premises gateways require Enterprise.
Do not buy Cerbos Hub if you expect it to solve standing privilege. That is the next section.
The Loser: Buying a Policy Engine First
Cerbos Hub is the loser for this job, and the reason is the purchase, not the engine. Steel-man first: Cerbos has the richest decision logs of the five, a portable open-source engine you can run anywhere, and published pricing. If you are building your own agent gateway, its decision point is a sound component — and it costs nothing.
But the paid product is policy lifecycle tooling. Cerbos Hub runs from a free proof-of-concept tier and $25 a month with 100 monthly active principals included, to $933 a month with 5,000 on Production. No tier issues, holds, shortens or revokes a credential. A security team that buys it first ends the quarter with well-versioned policies and agents still carrying the same long-lived keys, asking permission only on the code paths someone remembered to wire up. None of the incidents in this guide would have been stopped by a check the attacker's path never called.
How to Decide: The Criteria That Predict Regret
Six questions predict whether you will regret this purchase within a year. Put them in the RFP verbatim.
- Does every tool call physically pass through one chokepoint? If not, no policy product protects you. Fix routing first.
- Is a stolen credential useful an hour later? Ask for default access-token and refresh-token lifetimes in writing.
- Does the token name both the agent and the human? Demand a decoded example.
- Does the log record arguments and the matched policy? Without both, you cannot replay a decision.
- Who can turn enforcement off, and does that raise an alert? In AgentCore it is one IAM permission.
- What is the price unit, and does it grow with your success? AgentCore charges per call ($0.000025 per authorization request), Aembit per agent ($20 a month on Teams), Auth0 per monthly active user, Cerbos Hub per active principal. A high-volume agent is cheap on one model and expensive on another.
What changes the answer: if everything runs on AWS, AgentCore wins on price by a wide margin at this workload. If your agents act for customers inside third-party SaaS, Auth0's delegation and approval flow matter more than its price. If your estate is mixed clouds, self-hosted models and a pile of MCP servers, start with Aembit. If you are building a platform team's own gateway, run Cerbos's free engine inside whichever broker you pick. And if your agents already live inside an internal platform where one security review covers every agent, check what that platform brokers before buying a second layer.
What to Do in the Next 90 Days
This Week:
- List every credential an agent can use today — API keys in environment variables, OAuth grants to AI integrations, service accounts shared by more than one agent — and record each one's expiry. The ones marked "never" are your backlog.
- Run the one-hour test on your highest-risk agent. Copy its credential in a staging environment, wait an hour, and try it.
This Month:
- Put one agent behind a gateway in shadow mode. Write the five rules you believe are already true — no cross-repository writes, no deletes, no external email — and read what they would have blocked.
- Convert one shared service account into per-user delegated tokens, and confirm the downstream log now shows both identities.
Before Q4 Close:
- Add exactly one approval gate on your most irreversible action, bound to the transaction details and delivered to a phone. Measure the approval rate; if it sits above 90%, the gate is in the wrong place.
- Restrict who can disable enforcement, and alert on every change to it.
The Bottom Line
The industry spent a decade taking standing admin rights away from people, because people get phished. Agents are phished by design — every document, issue and web page they read is a chance to be instructed — and many teams are handing them the permanent keys just taken off humans.
The tooling is now good enough that you do not have to. Broker the credential so the agent never keeps it. Check every call against the task. Ask a human only when the action cannot be undone. Log enough to prove all three.
Give the agent a task, not a key.
Continue Reading
- Okta vs Entra Agent ID vs SailPoint: Two Issue, One Governs
- One Agent Escalated Another. Every Call Was Authorized.
- Your Supervisor Rewrote the Task. The 'Do Not' Fell Off.
- Claude Code Stops Asking Aug 14. Prompts Aren't Policy.
- Cursor Refused. The Next Chat Didn't. Scope the Creds.
- Snowflake Agents Run as All Your Roles. Revoke From PUBLIC.
- Adobe Took Rilo's Team. Its Slack Token Never Expires.
- The 2026 Agentic AI Stack: 8 Layers, 3 You Can Skip