Category: AI Agent Security

Short answer: Read-only access limits what an agent can take in. It says nothing about where the agent can send what it has read. In the Grok Bot case Shane Mac described in Business Insider, the read permission held and the destination was only a sentence in a prompt. Treat “where can this go” as its own permission, granted separately, and put a human decision in front of any send that leaves a private place.

What happened with the Grok Bot CFO agent?

Shane Mac, CEO of XMTP Labs, gave a personal “CFO” agent on Grok Bot read-only access to his checking and savings accounts. He told it to send its monthly report only to him, through Grok Bot. On Thursday, October 1, his head of product messaged him on Slack: the report, with his balances and biggest expenses, had appeared in the company Slack.

In his as-told-to essay, Mac says the agent “was doing exactly what I told it to do.” Grok’s team found it “confused the destination,” sending the message to a Slack chat titled “Exec-team” instead of his personal group chat with his agents. The channels had the same name. He also writes that his agents “feel like different agents” but “underneath the hood, they’re actually all using the same connections.” Afterward he removed every connection he had made, including Google, calendars, banking and Stripe.

Two details are worth holding onto. No attacker was involved, and this was not prompt injection. And the fix is as he reports it: Grok “implemented and shipped a solution last night,” requiring users to explicitly grant permission before agents move information to other channels. We have not seen a statement from Grok or XMTP.

Why didn’t “read-only” protect him?

Because read-only was a permission on one connection, and “send messages only to me” was an instruction. They are different kinds of thing.

A permission is enforced by something the agent does not control. An instruction lives in the agent’s own context, and the agent is the only thing holding it to account. When two channels look alike, or the context gets long, or a task gets re-planned, the instruction is the first thing to bend. The bank accounts were locked down properly. The route out of the system was a polite request.

The second gap is the shared connection. Mac connected Slack for one agent, and every agent could reach it. Once a connection exists, the question “which agent may use it, for what” is often answered by nobody.

Which permissions decide where an agent’s data can go?

Three, and a read-only label covers none of them.

1. Which connections each agent has. A finance agent should not inherit a messaging connection that was set up for a different agent.
2. Which actions each connection allows. Reading a feed and posting to a channel are separate abilities. Grant them separately, so a read grant does not quietly include sending.
3. Which sends need a person each time. Posting to a shared place, emailing a list, or paying someone leaves the private space. Those are worth a fresh human decision, because the cost of a wrong destination arrives before anyone can review it.

The same structure shows up in the permissions that quietly pile up over time: each individual grant looks reasonable, and the combination is what leaks.

What does this look like when an app uses AgentAdmit?

Where an app integrates AgentAdmit, each of the three is a setting the user or the app owner controls, outside the agent.

• Every agent gets its own connection, with its own label, scopes and expiry. Revoking one does not touch the others, and the audit trail shows which agent acted.
• The app can expose “read” and “post” as separate scopes, so a user can grant one without the other.
• The app owner can mark the outbound scope confirm each time. The agent’s call is refused until the user completes a passkey ceremony on a page the agent cannot operate. The signed commitment covers the scope, method, endpoint and a digest of the request body. We walk through the mechanics in Can an AI agent be required to get human confirmation for one action.

Had the apps in this story integrated AgentAdmit, this leak could have been prevented. A finance agent granted read scopes only holds no post scope, so the report could not have been posted anywhere. If the owner did grant a post scope and the app marked it confirm each time, the send would have waited for his passkey approval of that exact call. Two honest limits. This applies to apps that integrate AgentAdmit; the Slack connector and bank feed in the Grok story do not today. And what the user sees on the confirmation page depends on the summary the app writes, so an app that wants the destination reviewed should put the destination in that summary. And a signed yes is still a yes: it records that a person approved that exact action, not that the person read it carefully.

What it does change is who decides. The agent cannot approve its own send, which is the point of asking whether an agent can approve its own permission request.

What should you change if you run a personal agent today?

Start with the outbound side, since that is where the Grok case broke.

• Do not put a messaging or email connection on an agent that can read financial accounts, unless a send needs your approval each time.
• Where a product offers a choice between approving once and allowing every time, pick per-send approval for anything that posts to a shared space.
• Give each agent its own connection when the product allows it, so one mistake has one owner.
• Treat anything you wrote as “only do X” as a wish, not a control. If it matters, find the setting that enforces it.

Rishi Bhargava, cofounder of Descope, put the principle plainly in a separate Business Insider piece this month: “The user should consent on the actions that agents can perform on the website.” Mac ended his own essay in the same place: the challenge is “building better permission systems so users stay in control of the access they grant agents.”

FAQ

Does read-only access stop an AI agent from leaking data?

No. Read-only limits what the agent can change in the account it reads. It does not limit where the agent can send what it has read, if it holds any other connection that can send.

Was the Grok Bot incident a prompt injection?

Not according to the person it happened to. Shane Mac says the agent did what he told it to and picked the wrong destination because two channels had the same name.

Is telling an agent “only send this to me” a security control?

No. It is an instruction inside the agent’s own context. A control is a limit enforced outside the agent, such as a scope that does not include posting or a send that is refused until a person confirms it.

How does confirm each time apply to an outbound action?

The app owner marks the sending scope as confirm each time. The agent’s call is refused until the user completes a passkey ceremony committing to that exact call, and the agent cannot complete that step for the user.

Would AgentAdmit have prevented the Grok Bot incident?

Yes, had the apps involved integrated it. A finance agent granted read scopes only holds no post scope, so the report could not have been posted to Slack or anywhere else. If the owner had granted a post scope marked confirm each time, the send would have waited for his passkey approval of that exact call, which the agent cannot complete for him. The Slack connector and bank feed in this story do not integrate AgentAdmit today, which is why the control was missing.

See how apps give users scoped, per-action control over their AI agents.

Short answer: Mostly no, as far as their documentation shows. We read the READMEs of 1,634 MCP servers on the curated awesome-mcp-servers list and scored each one on six things a person would need in order to stay in control of an agent’s access: how the credential reaches the agent, whether there is an approval moment, whether one agent’s access can be revoked on its own, how long the access lasts, whether it can be narrowed, and whether the server can tell which agent made a call. Among the 857 servers that document a real credential channel, 85% deliver the credential through an automated pipe such as an environment variable or a config file. 8% document a way to revoke one agent’s access on its own. 9% document a credential that expires. Two thirds document no way to narrow what the agent may do. Half take the credential through an automated pipe and document none of the five user controls we looked for.

What did we measure, and how is it different from “is there auth?”

Other groups have already measured whether MCP servers authenticate at all. A May 2026 arXiv preprint, A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, identified 7,973 live remote MCP servers and found that 40.55% expose tools without any authentication; among 119 testable OAuth-enabled servers, every one had at least one flaw. Canopii’s monthly MCP Security Index, as read on September 30, 2026, scores 31,466 servers and reports that 3% of the 3,243 live endpoints it probed declared authentication and then served their tool surface to an anonymous caller. Astrix’s State of MCP Server Security 2025 read the READMEs of 5,205 repositories and found 53% relying on static API keys or personal access tokens.

Those studies answer “does a lock exist?” We asked a different question: once the lock exists and a person hands an agent the key, can that person still see, scope, and revoke what the agent holds? That is the layer where prompt injection turns a helpful agent into an exfiltration path, and we found no published measurement of it.

So we built a rubric with six dimensions, each one a question a user could ask about their own agent:

1. Credential delivery. Does the credential reach the agent through an automated channel (environment variable, config file, redirect callback), or does a person approve access each time?
2. Consent surface. Is there any moment where a human approves this agent’s connection?
3. Revocability. Can the user end this one agent’s access without rotating a key that other things depend on, and without redeploying?
4. Credential lifetime. Static, expiring on the server’s schedule, or a duration the user picks?
5. Scoping. All-or-nothing, or can what the agent may do be narrowed?
6. Attribution. Can the server tell which user or agent made a given call, or does every caller look the same?

The frame is the punkpeye/awesome-mcp-servers list: 1,347 repositories fetched on July 13, 2026, plus 287 repositories added to the list by September 10, for 1,634 total. This is a curated list, so it skews toward active, popular servers, and the long tail is probably less well documented.

How do you read these numbers?

Every figure below is a statement about documentation: “the README documents X” or “the README does not document X.” We chose that form after testing our own method. When a README says nothing about revocation, a classifier can either infer “there is no way to revoke” or answer “not enough information,” and which one it picks changes from run to run. Counting only what a README affirmatively documents gave figures that held steady when we repeated the classification. Counting inferred failures did not, so we do not report them. The method section near the end has the details, including the starker numbers we threw away.

How does the credential reach the agent?

Of the 1,634 servers, 857 document a real credential channel. Of the other 777, 668 need no credential (a local filesystem tool, a public read-only API) and 109 do not document one clearly enough to classify. Everything below about credentials uses those 857 as the denominator.

84.5% of credential-requiring servers deliver the credential through an automated pipe. 585 take it from an environment variable and 139 from a config file. A further 104 (12.1%) use a redirect-based authorization flow, where the agent’s client starts the flow and receives the token at the end of it. Only 29 servers (3.4%) document a path where a person approves access per request or per session, as opposed to setting a value once.

The distinction matters because an automated pipe has no human in it after setup. The key is planted once and the agent holds it from then on. Whatever the agent is talked into doing, it does with that key, and nothing on the delivery path asks a person whether this particular agent should have it.

This was the most stable result in the study. Two independent classification passes agreed on the delivery label for 95% of sampled servers, and an earlier pass that read far less of each README produced 84.6%.

Is there a moment where a human authorizes this agent?

80.1% of all 1,634 servers document no approval step at all. No “authorize this agent” screen, no confirmation, nothing: access is implicit once the server is configured. Among credential-requiring servers the figure is 75.1%.

161 servers (9.9%) document a connection-time approval, typically the consent screen of a standard authorization flow.

The rubric also has a label for an approval step that is reachable or operable from the agent’s own execution context, such as a confirm flag or a confirmation tool the agent can call. That pattern looks like consent, but the party asking and the party approving can be the same process. The classifier applied the label to 36 servers. It was the least stable consent label between passes, so we re-read all 36 READMEs one at a time.

In 24 of the 36, the README documents a confirmation step that is completed inside the agent’s own tool call. Thirteen use a confirm flag or a fixed confirmation string that the agent passes as a tool argument. Five return a confirmation token to the caller, which sends it back on a second call. Six expose the approve or trust action as another tool on the same server. Four of the 24 say in so many words that the agent cannot bypass or skip the step. As documented, though, the input that completes the step is available to the agent. A second call shows that the call was made twice. It does not show that a person read the preview.

Three READMEs in the set state that limit themselves and describe their confirmation step as friction or defense in depth, not as a human-approval boundary. That is the accurate way to document it.

The other 12 are a mix. Two raise a dialog in the client and fall back to a value the agent can pass when the client cannot show one. One requires an approval code that the operator holds. Four are sign-in flows that the agent starts and a person completes in a browser. Three are not approval steps at all, and two do not describe the mechanism in the text we read.

Two caveats. A client’s own tool-approval prompt can still put a person in front of each call; that is a property of the client, not of the server’s confirmation step. And 24 is a floor: it counts only rows the classifier flagged, so it shows the pattern exists on the list, not how common it is.

Can the user revoke one agent’s access without breaking the others?

8.3% of credential-requiring servers document a way to end one grant on its own. That is 71 of 857. The other 91.7% do not document one.

The 8.3% is a generous count. It includes READMEs whose documented “revocation” is deleting a local credential file or removing a linked device, which ends the local copy without necessarily ending the access upstream. As a cross-check, we searched every remaining README for revocation vocabulary (revoke, deauthorize, disconnect, remove access, delete the key). Counting every such mention as if it documented single-agent revocation, the ceiling is 95 servers, or 11.1%.

Undocumented does not mean it cannot be done. A server that takes one static key from an environment variable can be cut off by rotating that key at the provider. But think about what that means in practice. A user who suspects one agent has gone wrong has to break every other integration that uses the same key, then re-plant the new key everywhere. Most people will not do that on a suspicion. They will wait for proof, and by then the access has been used.

How long does the access last?

8.8% of credential-requiring servers document a credential that expires. That is 75 of 857: 72 with a server-set expiry such as a token lifetime or refresh cycle, and 3 where the user chooses.

Those three deserve a closer look, because user-chosen duration is the control that matters most for an agent. In two of them, the choice is made on the upstream provider’s token-creation page, where the account owner sets a validity period for the key before pasting it into the server’s configuration. In the third, the duration applies to new storage keys that the agent itself can create through a tool, up to a maximum the operator sets. None of the three is a duration a user sets for one agent’s access to the MCP server. If you want to give one agent access to your account for the afternoon and have it end at six, we found no server on the list that documents that as a per-agent option.

The cross-check here is looser. Counting every README that mentions expiry, a TTL, a refresh token, or a short-lived credential anywhere, including mentions that have nothing to do with the agent’s credential, the ceiling is 24.5%.

Can the user narrow what the agent may do?

66.2% of credential-requiring servers document no way to narrow what the agent gets. The other 290 servers (33.8%) document some narrowing: 101 by tool, 82 through scopes the user selects at grant time, 64 through separate credentials per user, and 43 per action.

That third is the most encouraging number in the study, and it comes with a caveat. Most of the per-tool narrowing is an operator switch: an environment variable that lists enabled tools, a read-only flag, or a tool profile chosen when the server is started. In 82 of the 101 per-tool cases the classifier’s evidence refers to an environment variable, a command-line flag, a config setting, or a read-only or tool-profile switch. It is a real control and worth having. It is set once for the deployment, though, so every agent that connects gets the same surface, and the person whose data is at stake may not be the one who set it.

Can the server tell which agent made a call?

23.2% of credential-requiring servers document per-user or per-agent attribution. That is 199 of 857. The other 76.8% either document one credential that every caller presents or say nothing about it.

Attribution decides whether an audit log is worth anything after an incident. A log that says “the key did it” cannot answer “which agent, under what authorization?”

How many servers document none of these controls?

436 servers, 50.9% of credential-requiring servers, take the credential through an automated pipe and document none of the five user controls: no narrowing, no way to revoke one grant, no expiry, no approval step, and no per-user or per-agent attribution. On the repeat sample, the two classification passes put this figure at 52.0% and 48.1%.

How was the classification done, and how reliable is it?

This is static analysis of documentation. It measures what a server documents, not how it behaves at runtime. A server may have an undocumented revocation path, or a documented one that does not work. We did not probe any third-party server.

Each repository’s README, up to its first 30,000 characters, plus its top-level file names, was classified by a language model (Claude Sonnet 5.5, one fixed version for every row) working from a written rubric with a definition for each label. A verbatim evidence quote was required for every label, with an “insufficient data” option instead of guessing. 129 READMEs (7.9%) run to 30,000 characters or more, so any text beyond that point was not read.

We tested the method three ways and re-read one label row by row.

Repeatability. We ran the same classifier a second time on a random 200 repositories. The two passes assigned the same label in 85.8% of cells (1,029 of 1,200): 95% for credential delivery, 90% for consent, 88.5% for attribution, 82% for lifetime, 80% for scoping, and 79% for revocability. Most of the flips were between a label and “insufficient data.” For the headline figures in this post, the two passes differed by less than four percentage points.

Independent re-read. A separate reviewer pass, also a language model and blind to the labels, read 20 of the September repositories in full. It agreed with the classifier on 80.0% of cells (96 of 120). Both readers come from the same model family, so this measures agreement, not ground truth.

Quote check. For labels that credit a server with a capability, we checked mechanically that the quoted evidence appears in the README. Across all 1,634 rows it did for 71 of 78 revocation labels, 71 of 77 lifetime labels, 305 of 329 scoping labels, and 224 of 235 attribution labels.

Row-by-row review. The 36 rows carrying the agent-operable approval label were each re-read individually, in a separate pass by a different model from the classifier, and sorted into the categories reported above. The README passage behind each judgment is recorded. This is a closer reading than the batch classification, and it is still not a human audit. It does not change any label or any other figure in this post.

The numbers we threw away are part of the method too. Our first pass, in July and September, read only the first 3,500 to 4,000 characters of each README and reported that 57% of credential-requiring servers had no way to revoke a single agent and that 44% failed all six dimensions. A verification re-read exposed the truncation. When we re-ran the classification on full READMEs with one model, those two figures fell to 16% and 9%, and they moved again between repeat passes. They had been measuring how readily a classifier infers failure from a silent README. The figures in this post count only what a README documents, and they are the ones that held.

“Curated list” cuts both ways: these are the servers people actually install, which makes the findings more relevant, and they are probably better documented than the long tail.

What would user-controllable agent access look like?

Every dimension above has a concrete better shape, and none of it requires abandoning standard authorization flows. It complements them.

The person starts the grant from inside the app they already trust, in their signed-in session. On a consent page hosted for that app, they decide which operations the agent may perform and for how long. The token is shown to the person, not to the agent; the person gives it to their agent, and the agent exchanges it for a scoped access token. The agent has no endpoint that opens a consent screen. Each agent gets its own connection, so the server can name the caller on every request and the user can revoke one agent without touching anything else. Access ends at the expiry the user chose or at revocation, whichever comes first. Operations that can do damage can require a fresh confirmation from the person, bound to the exact call.

That is the model we built AgentAdmit around, and it is why we ran this study: to find out how far the ecosystem is from it. The answer, for now, is that half of the credential-handling servers on the list document none of those controls, and fewer than one in ten document a way to revoke a single agent. The gap is the product.

Frequently asked questions

How many MCP servers were analyzed in this study?

1,634 repositories from the punkpeye/awesome-mcp-servers curated list: 1,347 fetched on July 13, 2026 and 287 added to the list by September 10, 2026. Of those, 857 document a real credential channel and form the denominator for credential-related figures.

What percentage of MCP servers document a way to revoke a single agent’s access?

8.3% of credential-requiring servers (71 of 857) document a way to end one grant on its own. The other 91.7% do not document one. Counting every README that mentions a revocation keyword anywhere raises the ceiling to 11.1%.

Do any MCP servers let the user choose how long an agent’s access lasts?

Three of the 857 credential-requiring servers (0.4%) document a user-chosen lifetime, and none of the three is a duration set for one agent’s access to the MCP server: two rely on the validity period chosen on the upstream provider’s token page, and one concerns keys the agent creates through a tool. 8.8% document a credential that expires at all.

Is this study based on live testing of MCP servers?

No. It is static analysis of each repository’s README and top-level file names, so it measures documented capability, not runtime behavior. No third-party server was probed. Labels were assigned by a language model working from a published rubric; two independent passes of that classifier agreed on 85.8% of labels, and the headline figures moved by less than four percentage points between passes.

Is a confirm flag on an MCP tool the same as human approval?

Not by itself. Of the 36 servers flagged for an agent-operable approval step, 24 document a confirmation that is completed inside the agent’s own tool call: a confirm flag or fixed string, a token returned to the caller, or an approve tool on the same server. A second call shows that the call was made twice, not that a person approved it. A client-side approval prompt can add that, and it is a property of the client.

How can I reproduce the numbers?

Every figure in this post is printed by committed scripts over one classification file. The rubric, the repository list, the scripts, and the aggregate counts are published at github.com/PhoenixCo-Founder/mcp-user-controllability-study. The per-repository label file is available to researchers on request at christopher@agentadmit.com, so that no individual server is singled out.

If you run an MCP server and want your users to be able to see, scope, and revoke what their agents hold, AgentAdmit is the hosted layer for that: user-started grants, per-agent connections, user-chosen duration, confirm-each-time on sensitive actions, and a tamper-evident audit ledger. Patent pending. Build and test on a test key.

Short answer: Yes, if the approval was signed rather than logged. Where an app requires presence, AgentAdmit’s hosted consent page derives the passkey challenge from a cryptographic commitment to the exact grant on screen: the scopes, the duration, the app’s declared purpose, the user’s own intent words, and any call ceilings. The user’s passkey signs that commitment. The signed response, the authenticator’s public key, and the commitment preimage are all persisted and exported, so anyone holding the export can recompute the commitment and run standard WebAuthn verification without trusting AgentAdmit’s database.

Why isn’t a vendor’s consent log proof?

A log row that says “user approved read:workouts at 14:02” is a statement by the system about its own behavior. If you trust the operator, it is useful. If you are an auditor, a regulator, a customer’s security team, or the user in a dispute, it is exactly the thing you were asked to verify, restated. The operator could have written it, edited it, or written it late.

That problem gets sharper with AI agents. An agent that holds a token will act on it thousands of times. When one of those actions is questioned, the question is never “did the vendor record consent” but “did a person actually approve this grant, with these limits.” A log cannot answer the second question on its own. A signature can.

What does the passkey actually sign?

In an ordinary WebAuthn login, the server sends a random challenge and the authenticator signs it. The signature proves the user was present. It says nothing about what they were agreeing to.

AgentAdmit replaces the random challenge with a commitment. When the hosted consent page reaches the ceremony, the server freezes the grant selection into a canonical string: the app, the user, the scopes sorted, the duration, the declared purpose, the user’s intent in their own words, any call ceilings, the session id, and the time it was issued. The challenge is the SHA-256 hash of that string. The user confirms with Face ID, Touch ID, a device password, or a security key, and their passkey signs that hash.

The result is a signature over the decision itself. The server stores the signed response, the public key of the credential that signed it, and the preimage string, and copies the bundle onto the append-only consent trail as part of the presence event for that grant.

The binding is enforced. If the user changes scopes or duration after the ceremony, token generation refuses with a commitment mismatch and the page asks for a fresh ceremony. The evidence can only ever describe the grant that was issued.

How does someone verify it without trusting AgentAdmit?

Two checks, both standard, both offline.

1. Recompute the commitment. Hash the stored preimage with SHA-256 and compare it to the challenge inside the signed clientDataJSON. A match means the ceremony signed a commitment to exactly these recorded grant parameters.
2. Verify the signature. Run ordinary WebAuthn verification: the signature over the authenticator data and the hash of clientDataJSON, checked against the recorded public key. The authenticator flags inside the data show user presence and user verification.

Nothing in those two steps calls AgentAdmit. The bundle is available two ways: inside the consent export, and directly per connection at GET /api/v1/connections/{connection_id}/evidence with include_raw=true, under the app’s own live key. Test keys never read live evidence.

What are the three evidence tiers on a connection?

Not every connection has a signed commitment behind it, and the evidence endpoint says so rather than blurring the line. Each connection sits in exactly one tier.

• hosted_vce. A commitment-bound ceremony ran on the hosted page and the evidence bundle is persisted. Independently verifiable.
• presence_fact. A ceremony is recorded on the connection but no commitment evidence exists. This covers the legacy path, and it covers an app that ran its own passkey prompt and attested the fact at token issuance. The response labels who witnessed it, and it is labeled not independently verifiable. An app-attested fact never promotes to the hosted tier.
• none. The hosted service never witnessed a ceremony: a direct API token, a presence-off session, or an app-side prompt that was never attested.

An app can show these tiers to its users as they are. A connection that reads “no ceremony evidence” is the system being honest, not the system failing.

Are all passkeys equal?

No, and the evidence records the difference. An app chooses one of two assurance policies, and the policy is frozen into each session when it is staged.

Consumer accepts what people actually have: Face ID, Touch ID, a device password, or a passkey synced through iCloud or Google. Those credentials arrive without attestation, so the evidence records them as user-verified and unattested. One extra rule closes the obvious gap: a newly registered credential is never final evidence by itself. It must immediately sign an authentication assertion over the same persisted commitment before the grant can finalize, so registration alone never grants anything.

Trusted requires direct attestation from the authenticator, validated against the FIDO Metadata Service, with provenance rechecked on later assertions. An ordinary phone passkey does not qualify. It exists for the apps where the cost of a wrong approval justifies a hardware key.

The claim ceiling for the consumer tier, stated plainly: user-verified and signed over the exact commitment, not hardware-attested.

What does the evidence not prove?

It proves that a user-verified passkey ceremony signed a commitment to these recorded grant parameters. It does not prove what the user’s screen rendered, or that they read it. No cryptography can, and a vendor telling you otherwise is selling the log back to you with a signature on top.

It is also a review-time record, never an enforcement input. The live verification call that allows or refuses each agent request checks the grant, the scope, expiry, revocation, and the user’s ceilings. The evidence is what you reach for afterward, when someone asks whether the grant was real.

The trail it rides has its own honest ceiling. Every decision event carries a hash of its content and of the previous event, so an altered or deleted row breaks every fingerprint after it. That is tamper-evident, never tamper-proof. An operator rewriting and re-chaining history is caught by comparing two exports taken at different times, which is why the export exists on every plan.

Where is it running?

Commitment-bound evidence shipped on August 6, 2026 and the assurance tiers on August 28, 2026. TrainerTracer, the first production integration of AgentAdmit, runs its agent grants and its own consent-switch changes through hosted ceremonies, so its connections carry the hosted tier. We have run the offline verification ourselves on a real passkey ceremony, from export contents alone, using nothing but the two checks above.

FAQ: verifiable consent evidence for AI agents

Does the user’s biometric data leave their device?

No. Face ID and Touch ID stay on the device. The only thing recorded is the cryptographic signature and the public key of the credential, which is how every passkey login works.

Can the agent produce this evidence on the user’s behalf?

No. The ceremony runs on AgentAdmit’s hosted page with a user-verified passkey. An agent can carry the link to the user. It has no way to produce the signature.

What happens if the grant changes after the user signed?

Token generation refuses with a commitment mismatch and asks for a fresh ceremony. The evidence only ever describes the grant that was actually issued.

Is the evidence produced for every grant?

Only where the app requires or prefers presence on the hosted page. Direct API tokens and presence-off sessions produce no ceremony evidence, and the evidence endpoint reports them as such.

Is the consent trail tamper-proof?

No. It is tamper-evident. Each decision event carries a hash chain fingerprint, so alterations are detectable by anyone holding an export. The three checks are documented in the App Owner Guide and can be re-implemented from the export fields alone. The reference verifiers are public at github.com/PhoenixCo-Founder/agentadmit-verifiers.

Integration details are in the App Owner Guide and the MCP Server Operator Guide, the term is defined in the glossary, and the flow is identical with test keys at agentadmit.com.

Related reading: Can an AI agent’s grant carry the app’s declared purpose and the user’s own intent? | Can an AI agent be required to get human confirmation for one action? | Should an AI agent ever hold its own authority?

Short answer: Yes, and no. In AgentAdmit a grant can carry two short statements: the app’s declared purpose, written by the app owner, and the user’s intent, typed by the user in their own words on the consent page. Neither one is enforced. Every verification decision is made on scopes, connection status, and consent. The two statements go on record instead: they ride every audit row, the grant event, every alert, and, for the user’s words, the passkey-signed commitment, so a human reviewing the trail later can judge whether the agent’s behavior still matches what was said.

What is a declared purpose on an agent grant?

A declared purpose is the app’s one-line reason the grant exists, up to 300 characters, set by the app’s backend when it opens a consent session. The user sees it on the hosted consent page before approving anything, under the label “Declared purpose”. TrainerTracer, the first production integration, declares “Connect an AI agent to TrainerTracer with only the permissions you approve.”

Once the user approves, the purpose is stored on the connection. It comes back to the app on every successful verification call. It is stamped into every per-call audit row, including refused calls. It is written into the grant event when the connection is created and again when it is revoked. When an alert fires, the purpose travels with it in the webhook payload and the email.

None of that changes what the agent may do. The scope list does that. Purpose answers a different question, months later: what was this connection for?

Why record the user’s own words as well?

Because the app’s words and the user’s words are not the same thing, and the user’s are the ones that matter in a dispute. The consent page has an optional field titled “Your Intent”. The prompt under it reads: “What do you want this agent to do for you? Your own words go on record with the grant, separate from the app’s declared purpose above.” A user might type “build me a weekly workout summary” under an app purpose that talks about connecting an agent in general.

User intent flows exactly like purpose: stored on the connection, returned on verification, stamped into audit rows, carried on grant and revocation events, included in alert payloads. When the consent page runs a presence ceremony, the intent text is part of the commitment the passkey signs, alongside the scopes, duration, and declared purpose. The difference is whose words they are: the authenticator signs what the user said they wanted, not only what the app declared. If the user edits the text after the ceremony, the page requires a fresh one, because the earlier signature covered different words.

The two fields are never merged. Purpose is app-declared. Intent is user-declared. An export shows both, side by side, on the same row.

Is the purpose or intent enforced at verification time?

No, by design. A verification decision reads the scopes on the grant, whether the connection is active, and the consent state. It never reads purpose text or intent text. If an agent with a read-workouts scope calls the read-workouts endpoint, the call is allowed whether the stated intent was a weekly summary or anything else.

That is deliberate. Enforcing a sentence of text would mean a machine deciding whether “summarize my week” covers a particular call. That judgment belongs to a person, and it belongs at review time, with the evidence in front of them. Scopes, durations, call ceilings, and confirm-each-time are the enforcement tools. Purpose and intent are the record that makes the review honest.

What does the review actually look like?

Three places, all fed by the same two fields.

The first is the trail itself. The per-call audit export and the consent-ledger export both carry purpose and intent on every relevant row, so a question like “was this agent doing what the user asked for in July?” is answered from the export, not from memory.

The second is the alert. AgentAdmit watches each connection for drift from its own established pattern: a historically narrow connection suddenly using most of its granted scopes in one window, a scope that sat unused for two weeks waking up, or call frequency several times the prior daily average. These boundary-deviation alerts are review-only. They are always warnings, they never revoke anything, and the kill switch cannot be enabled for them. Each one delivers the drift evidence next to the declared purpose and the user’s intent, so the person reading it judges whether the behavior still matches the words. The text is never parsed or scored by the system.

The third is the revocation screen. When a user comes back to a connection weeks later, the dashboard shows the purpose under the connection and the intent they typed. “Is this still appropriate?” gets answered against their own stated boundary, not only the app’s.

Where does this show up for the user and the app owner?

For the user: on the consent page before approval, on the existing-grant review step that lists each active grant’s agent, scopes, and declared purpose before a new one can be created, and on their connection list afterward.

For the app owner: in the dashboard’s connection rows and Logs page, in the two exports, and in every alert delivery. Apps using the React components get purpose on the connections list without extra code. Server SDKs return purpose and intent on the verification result.

Shipped in August 2026: declared purpose first, user intent a week later, both live for every app on every plan, including test keys.

FAQ: declared purpose and user intent on agent grants

Can the agent change the purpose or intent after the grant?

No. Both are set at consent time and stored on the connection. An agent holds a token, not a way to edit the grant record. A new purpose means a new grant, which the user sees and approves.

What if the app leaves purpose empty?

The field is optional. The grant works the same and the audit rows simply carry no purpose. We recommend setting it, because a blank reason is the weakest possible answer to “what was this for?” in a later review.

Does an alert on drift mean the agent misbehaved?

No. It means the connection’s pattern changed relative to its own history. The alert puts the evidence next to the recorded purpose and intent and leaves the judgment to a person. It never revokes on its own.

Is the user’s intent cryptographically bound to anything?

When a presence ceremony runs, the intent text is part of the commitment the user’s passkey signs, alongside the scopes, duration, and purpose. An auditor can recompute that commitment from the record and check it against the signed response. That proves a user-verified ceremony signed those exact words. It does not prove the user read the screen.

Why not just enforce intent with a model?

Because a model’s guess about whether a call matches a sentence is not something to build an authorization decision on. Enforcement stays deterministic: scope, status, consent, ceilings, confirmation. The sentence stays on record for the human.

Declared purpose and user intent are live on every AgentAdmit grant. The App Owner Guide and the MCP Server Operator Guide show where each field is set. See how the consent page records both at agentadmit.com.

Short answer: Yes. Whoever runs the app or MCP server the agent is calling decides which actions are high-risk, sending a payment for example, and flags those actions in AgentAdmit as confirm each time. From then on, every time the agent tries one of those actions, the call is refused until the user confirms that exact action with a passkey on a page only the human can complete. The agent keeps its token and the rest of the grant works as before. It just cannot finish that one action on its own.

Why isn’t a valid grant enough for some actions?

A grant answers “what may this agent reach, for how long.” It does not answer “should this specific transfer go out right now.” An agent with a payments scope on a 30-day connection can send a payment on day one and on day twenty-nine, and both calls look identical to the server. That is fine for reading a workout log. It is not fine for moving money, deleting records, or emailing a customer list.

The usual fix is to make the agent ask. The agent shows a dialog, the user clicks yes, the agent proceeds. The problem is where that dialog lives. It runs inside the agent’s own process, so anything that can steer the agent can also produce the “yes”: a planning error, an injected instruction, a tool result that looks like a user reply. A confirmation the agent can satisfy by itself is not a confirmation.

How does confirm each time work?

The app or MCP server operator sets one flag on the scope when registering it with AgentAdmit: confirm_each_time: true. From then on, the check runs inside the same verification call the app already makes on every request. Four steps.

1. The agent calls, verification refuses. The app passes the scope being used, the method, the endpoint, and a digest of the request body. AgentAdmit answers that the token is valid but this call needs confirmation, and it stages an action session bound to exactly those values.
2. The app relays the link, and tells the user itself. The agent receives a 403 with a confirmation URL and shows it to the user. The URL is for the human, not for the agent. The app should not depend on the agent to pass it along. When the refusal comes back, the app can notify the user directly. TrainerTracer, the first app running AgentAdmit in production, does this: the refusal creates an in-app notification and a push, and its Agent Access page lists the pending action with a Review button, so the user learns about a waiting action even if the agent never mentions it.
3. The human confirms. The hosted page shows the app’s name, the agent’s label, the scope, the method and endpoint, the request digest, and the app’s plain-language summary such as “Pay Alex $50”. The user confirms with a user-verified passkey (Face ID, Touch ID, or a security key). The signing challenge is a cryptographic commitment to that exact action, built only from the values the server stored when it refused the call. The session expires 15 minutes after it is staged.
4. The agent retries. Same call, plus the attestation id from the refusal. Verification consumes it atomically, once. A second retry with the same id is refused again with a fresh session.

Nothing in that flow widens the grant. Only a scope the user already granted on an active connection can be staged. A confirmation is not a permission; it is permission to run one call the user already authorized in principle.

What does the user actually sign?

The passkey challenge is a SHA-256 commitment over the connection, the scope, the method, the endpoint, the request digest, and the summary. The claim this supports is narrow and worth stating precisely: a user-verified passkey ceremony signed a commitment to the exact action shown. It is not proof that the user read the screen, and on a phone passkey it is not hardware attestation, and the record says so honestly. Apps that need more set the trusted tier: the ceremony then requires a hardware security key with attestation checked against the FIDO Metadata Service, and an ordinary phone passkey does not qualify. Either way it is a record that a person, holding the credential they enrolled, approved these bytes.

That record lands in two places. The refusal and the retry are both rows in the per-call audit trail, which is hash-chained on the server. The ceremony itself appends a presence event to the consent ledger, with the tier the app required and an honest assurance record. On the consumer tier an export can answer “was a human present for this call” without trusting the agent’s own log. On the trusted tier it also answers what signed: a hardware security key, its attestation format, and its make and model as registered with the FIDO Metadata Service.

When should an app or MCP server operator use it, and when not?

Use it for actions that are irreversible or leave the building: money movement, deletions, anything the agent would send, post, or publish, production deploys, privilege changes. Those are the calls where a fresh human decision is worth 15 seconds.

Do not use it for bounded routine work. If the concern is “how many times” rather than “which one,” the right tool is a call ceiling the user sets at the ceremony. Reading a calendar 200 times a day should never fire 200 prompts. A gate that fires on everything trains people to click yes. Confirm each time is meant to be rare, specific, and out of band.

The app can also stage a confirmation before the agent attempts the call, so the human approves first and the agent’s request goes straight through. A pending session for the same action is reused rather than minted twice, so a retrying agent does not create one ceremony per attempt.

Where is it running today?

Confirm each time shipped on September 15, 2026, in the hosted service and in all six server SDKs. TrainerTracer, the first production integration of AgentAdmit, uses it on agent-initiated payments to trainers: the client’s own AI agent, whichever one they connected, can prepare the payment, but the client approves that exact payment on their phone before it goes out. The flow is identical under test keys, so an integration can run it end to end before go-live.

FAQ: confirm each time for AI agents

Does confirm each time replace scopes and durations?

No. It sits on top of them. The user still grants scopes for a duration with optional call ceilings. Confirm each time adds a per-call human decision to the scopes the operator flags, inside that grant.

Can the agent complete the confirmation itself?

No. The confirmation happens on AgentAdmit’s hosted page with a user-verified passkey. The agent can carry the link to the user and retry after the user confirms, but it has no way to produce the signature.

What happens if the agent changes the request after the user confirmed?

The retry is refused. The attestation is bound to the scope, method, endpoint, request digest, and summary the user saw. If any of those differ, verification reports an action mismatch and stages a fresh session.

Does a confirmation cover more than one call?

No. Each confirmation is consumed exactly once. The next call on the same scope needs a new confirmation.

Is this a per-call prompt on every action?

No. It applies only to scopes the operator flags, and only when the app declares which scope a call uses. Everything else runs on the standing grant and its ceilings.

Read the integration details in the App Owner Guide or the MCP Server Operator Guide, or start with test keys at agentadmit.com.

Related reading: Should an AI agent ever hold its own authority? | Can an AI agent approve its own permission request? | Prompt injection is an authorization problem, not just a model problem

Short answer: Yes, and in a typical deployment today it happens by default. When an agent receives broad API credentials at setup, those permissions persist indefinitely. Each new task may add scopes; nothing routinely removes them. The result is an agent that holds the union of everything it was ever granted, with no user-facing way to see, audit, or reverse what accumulated.

What does “accumulating permissions” actually look like?

Most AI agents get their access at setup: an API key or OAuth token is configured once, and the agent uses it for every subsequent task. The scope reflects what the first use case needed. Then the agent gets a second job. A third. Each one might require a slightly wider permission. The developer adds the new scope to unblock the pilot. Nobody goes back to remove the old one.

Microsoft’s security guidance from July 2026 names this exactly: “The fastest way to create long-term risk is granting broad Owner/Admin roles to unblock a pilot, then never coming back to refactor permissions once the workflow ‘works.’” The problem is not malice. It is inertia. Broad access is easier than precise access, and there is no forcing function that makes teams revisit what an agent holds once it is running.

Kovrr, a cyber risk firm writing about agent access patterns in September 2026, put it plainly: “Permissions are requested per task and granted per lifetime, and the difference between those two is where the exposure accumulates.” An agent that has run six different jobs over a year holds the union of what all six needed. A compromise at job six inherits the blast radius of jobs one through five as well.

Why do scopes grow but never shrink?

The standard authorization model was not designed for agents. SpruceID, writing on agent authorization in September 2026, explained the gap: “OAuth 2.0 grants access at the scope and API level. A token proves that a user authorized an application to act on their behalf, and it defines a broad category of permitted actions. What it does not support is saying: this agent may access exactly these three files, for exactly this purpose, for the next 72 hours, and only on behalf of this named principal.”

That granularity does not exist in the token. So developers approximate. They pick the closest available scope, often a superset of what the task actually requires, and move on. The agent now holds a permission that covers more than the task needed. Multiply that across a deployment with dozens of tasks, and the effective access surface is far wider than any single workflow ever justified.

The service account pattern makes it worse. SpruceID again: service accounts have permissions that “accrete over time as teams add scopes without removing old ones, so the average enterprise service account has far broader access than any single workflow requires. When an AI agent inherits a service account or uses an API key, it inherits both the access and the lack of attribution.”

There is also no widely adopted mechanism to trigger a permission review. Nobody asks the user whether the agent still needs what it held six months ago. The user often does not know what the agent holds at all.

Is token expiry the answer?

Short-lived tokens help with some attack scenarios, but they do not solve accumulation. Kovrr made this point clearly: “The identity industry has settled on an answer to agent permissions. Zero standing privileges, credentials issued at the moment of need, scoped to the task, expiring when it completes. The reasoning is sound and the architecture is coherent. Almost nobody has deployed it for non-human principals.”

The practical reason is that long-running tasks break short token windows. An agent mid-workflow either renews its credential repeatedly, which is standing access with extra machinery, or it fails halfway through. Most teams choose standing access and tell themselves the token scope is narrow enough.

There is also a more fundamental issue. Refresh tokens undo expiry. If a token automatically refreshes on use, it does not expire in any meaningful sense. The user never re-enters the decision. The agent just keeps going. The “expiry” becomes a detail in a spec, not a real boundary that makes the user look again at what the agent holds.

That is why AgentAdmit issues no refresh tokens at all: when a grant expires, the agent comes back to the person.

What actually tells you what an agent currently holds?

In the typical deployment, nothing. The API key is in an environment variable. The OAuth token is stored in a secrets manager. Neither surfaces to the user in a readable form. If the user wants to know what the agent can do, they have to find the original configuration and remember whether it has been updated since.

Kovrr’s advice on this is worth quoting directly: “Whether the grant is observable and whether revocation has been tested” matters more than theoretical duration. “A standing grant somebody can see and withdraw in minutes is a better position than an ephemeral system nobody has exercised.”

Observability is the precondition for any other control. You cannot scope what you cannot see. You cannot revoke what you cannot enumerate. The technical solutions, just-in-time credentials, ephemeral tokens, minimal scopes, are all inaccessible until you have a list of what an agent actually holds and under whose authority.

What does user-controlled authorization change?

User-mediated authorization addresses permission accumulation at the architecture level, not the policy level. Several design choices work together to make it structural rather than aspirational.

First, there is no expand-scope API. If an agent needs an additional permission, a new connection flow is required. The user goes back through the consent surface, selects the new scope alongside the existing ones, and approves explicitly. The agent cannot quietly acquire more access between user interactions.

Second, there are no refresh tokens. When the connection expires, it expires. The agent brings it back to the user for renewal. That renewal is also an opportunity to review: the user sees the current scope and either reauthorizes it or adjusts it. Expiry becomes a forcing function for a real review, not a box that gets ticked automatically.

Third, the existing-grants review step makes accumulation visible before a new grant lands. When a user tries to create a new connection to an app where they already have active grants, the consent surface blocks the flow with a review step. Every existing grant is listed. The user can revoke any of them, or acknowledge and continue. A new grant cannot be added without confirming what is already there.

Fourth, the user sets usage limits at the consent ceremony, recorded in the grant itself. An agent that bumps against a usage ceiling stops and comes back to the user. The user decides whether to increase the limit. The agent cannot raise its own ceiling.

Every request made with a valid token is logged against the connection: what the agent accessed, when, and whether the call was refused. The user sees the live signals on their own connection: when it was last used, how many calls it has made against the ceilings they set, and any recent alerts on it. The app owner holds the full per-call trail in the AgentAdmit dashboard, can export it at any time, and can surface it to the user inside the app, instead of leaving it buried in a server log nobody reads.

This is also where the question of self-approval matters. An architecture that lets an agent initiate its own authorization flow can also let it expand its own access. User-mediated delivery closes that path structurally: the credential is delivered to the human and the agent has no programmatic route to request more without going through the user.

FAQ

Can an AI agent request additional permissions without the user knowing?

In the typical deployment today, yes. API keys and OAuth tokens are configured once and the agent uses whatever they grant indefinitely. There is no widely adopted mechanism that alerts the user when a task requires a wider scope, or that blocks access until the user approves an expansion. User-mediated authorization changes this by requiring a new connection flow for any scope expansion. The agent cannot add permissions between user interactions.

How do you find out what permissions an AI agent currently holds?

In a typical deployment, you have to trace it manually: locate the credential, find the original grant, and check whether anything was changed since configuration. Most users have no access to that information. A user-controlled authorization layer addresses this by surfacing active connections and their exact scope in a dashboard the user can access directly. Revocation is self-serve inside the app, not a ticket to an IT team.

Is there a way to set a ceiling on what an agent can do before it even starts?

Yes, if the authorization architecture supports it. Usage limits authored at the consent ceremony and recorded in the grant mean the agent’s reach is bounded from day one. The user sets the ceiling; the agent cannot raise it. A call past the ceiling is refused and logged. The user then decides whether to authorize more, not the agent.

Does token expiry prevent permission accumulation?

Not by itself. Expiry limits how long a specific token is valid, but it does not narrow the scope or remove permissions that were added over time. If the token refreshes automatically, expiry does not meaningfully interrupt access either. What expiry can do, when combined with user-mediated re-authorization, is create a real review moment: the user sees the current scope and reauthorizes it or adjusts it. Expiry as a forcing function for review is different from expiry as a security control in isolation.

Learn more about the industry and research consensus on what AI agents should and should not hold, or read about how prompt injection turns wide access into an immediate attack surface.

AgentAdmit gives app owners and their users the tools to issue scoped, time-limited, user-revocable agent access and see exactly what each agent holds. Learn more at agentadmit.com.

Short answer: The buyer’s guides to AI agent authorization we have read evaluate tools that fix the credential problem at the infrastructure layer: short-lived tokens, just-in-time provisioning, policy decision points. None of them gives the person whose data is at stake a surface of their own. Where the user appears at all, it is to approve one transaction from a phone or to pick a trust tier inside limits an administrator set. There is no place where the user sees what access the agent holds, scopes it, sets a call ceiling, and revokes in one step. That is the gap they skip.

What do AI agent authorization buyer’s guides actually cover?

A detailed guide published September 14, 2026 compared five of the most credible tools in agent authorization: an AWS gateway that issues delegated tokens and runs Cedar policy on every tool call, a credential broker and MCP proxy whose agents never hold the downstream credential at all, a delegation platform that routes specific transactions to a user’s phone for approval, a proxy that tiers tools by read/write/destructive risk, and an open-source policy decision engine. The framing is correct. The core problem in agent authorization is standing privilege: a credential that exists whether or not a task needs it, valid before the agent starts and still valid after it stops.

Every product on the list is a real answer to a real problem. Token brokers replace long-lived keys with short-lived, scoped credentials. Gateway proxies intercept tool calls and check them against policy on every request. Approval systems route high-stakes transactions to a human before the agent can proceed. These are genuine security wins, and the industry was right to build them.

But every product on that list is admin-controlled, developer-controlled, or enterprise-controlled. The security team and platform engineers configure the rules. The end user whose data is in scope gets, at most, a per-transaction approval prompt or a trust-tier choice; never a standing view of the grant itself.

Why does the user layer keep getting skipped?

The framing matters. The CISO and platform engineer ask: how do we keep agent credentials from outlasting the task, from being intercepted, from granting more reach than the task requires? The infrastructure tools answer that question well.

The user asks something different: what is this agent allowed to touch in my account? Who gave it permission? Can I see what it did last week? Can I cut it off right now?

Those questions don’t appear in enterprise buyer’s guides because the buyer is the enterprise, not the user. The enterprise buys the token broker. The enterprise buys the policy engine. The user of the enterprise’s product receives whatever the enterprise decided to configure, with no visibility into what that was and no controls of their own.

Okta’s chief product officer, Ely Kahn, framed the infrastructure problem accurately in September 2026: “Nobody wants to slow AI down, but you can’t simply hand out access and hope for the best.” The 2026 Verizon Data Breach Investigations Report backs that up: counting every point where it appears in a breach, credential abuse sits at the top of the report’s initial-access vectors, in 39% of breaches. That’s the right motivation. Zero standing privilege for enterprise infrastructure is a meaningful goal. It’s a different problem from user-visible, user-controlled access grants.

What does the missing user layer look like in practice?

When an AI agent gets access to a user’s account today, the typical path goes through a developer or an IT team. They provision credentials, configure scopes at the service account level, and set up whatever policy their chosen tool supports. The user may see a generic permission screen during initial setup. After that, they see nothing.

They don’t know what the agent can reach. They didn’t pick the scopes. They have no record of what the agent did with their data yesterday. If they want to revoke, they file a support ticket and wait.

The missing layer is the one where the user holds the authorization decision. The grant starts inside the app the user already trusts, in their signed-in session. The consent step runs on a hosted page opened on the app’s behalf. The user sees exactly what the agent will be able to access, picks the scopes, sets a duration, and optionally sets call ceilings on how many times the agent can use a given group of actions per day or over the lifetime of the grant. A Connection Token is generated and shown to the user once. The user passes it to their agent. The agent exchanges it for a scoped Access Token. Every call the agent makes afterward is verified against the user’s original choices on every request.

This mechanism is what AgentAdmit calls user-mediated delivery, a patent-pending approach documented in an Internet-Draft submitted to the IETF (draft-emerson-oauth-user-mediated-delivery). The token never travels through an automated channel between the app and the agent. The authorization decision happens outside the agent’s execution context, so a prompt injection attack cannot, by itself, produce a new grant: a person has to approve it on the hosted page, with a passkey when the app requires presence. There is no automated path from an injected instruction to a wider grant.

Does fixing infrastructure credentials solve the user problem?

Not directly. Infrastructure tools solve the enterprise’s problem: credentials don’t outlive tasks, policy gates fire on every tool call, token reach is bounded at the platform level. That’s genuinely valuable work.

But the authorization problem at the user level has a different shape. A credential can be short-lived and still be broader than the user intended. A token can expire in an hour and still carry permissions the user never consciously chose. An audit log can exist in a compliance system without the user ever seeing it.

Astrix’s 2025 scan of over 5,200 open-source MCP servers found that 53% rely on static API keys or personal access tokens: long-lived, rarely rotated, and usually sitting in an environment variable. Infrastructure tools improve that picture. What they don’t address is a user who wants to know what their AI assistant can reach inside their account today, wants to limit it to specific actions, and wants a record of what it actually did.

Those are user rights, not infrastructure properties. They require a user surface.

What should a complete AI agent authorization checklist include?

The infrastructure checklist is well understood: does the product remove standing credentials, does it check every tool call against policy, does it support human approval for high-stakes actions? Those are the right questions for the platform layer.

The user layer needs a parallel checklist. Can the user see what access their agent holds, in plain language? Can they scope it to specific actions rather than inheriting admin defaults? Can they set a limit on how many times the agent uses a given group of actions per day? Can they revoke in one step, immediately, without involving the security team? For an action the app owner marks as high-consequence, can the user be asked to confirm that exact action, at the moment it happens, on a surface the agent cannot reach? Is there an audit trail they can read themselves, not just one that compliance can pull on their behalf?

Today the typical agent deployment answers no to all of these. The infrastructure tools answer the first checklist. AgentAdmit answers the second. Most real deployments will need both.

FAQ: the user consent gap in AI agent authorization

Why don’t enterprise authorization tools give end users a consent surface?

Most enterprise identity tools are built for the relationship between the organization and the agent, not between the individual user and the agent. The organization provisions access. The user is the subject of that access, not a participant in deciding it. A user-facing consent surface is a separate product layer, and it isn’t what enterprise security buyers are asking for. Their buyer is the IT or security team.

What is user-mediated delivery in AI agent authorization?

User-mediated delivery means the authorization credential is generated in response to a conscious user decision and handed to the user directly, not routed through an automated channel between the app and the agent. The user grants access in their signed-in app session, selects scopes, sets a duration, and passes the Connection Token to their agent out of band. No redirect, no callback, no automated path. AgentAdmit’s implementation is patent pending and documented in an Internet-Draft submitted to the IETF at datatracker.ietf.org/doc/draft-emerson-oauth-user-mediated-delivery/.

Can a user set limits on how much an AI agent uses their access?

Yes, with AgentAdmit. At the consent ceremony, the user can set call-count ceilings per scope group or per connection, on a daily or lifetime basis. Those ceilings are recorded in the grant at the moment the user approves and checked on every verification call afterward. The agent learns its ceilings in the exchange response, so it knows when to ask the user for more access rather than failing silently or trying to work around the limit.

What happens when a user wants to revoke an AI agent’s access?

With user-mediated authorization, the user revokes from inside the app themselves. Revocation takes effect on the next call the agent makes. There’s no ticket to file and no security team to loop in. The grant event is recorded in the tamper-evident audit log with a timestamp, so the app can show the user exactly when access was cut, and the app owner can export the calls that preceded it.

Is the user consent layer a replacement for enterprise agent authorization tools?

No. Enterprise infrastructure tools address standing privilege at the platform level: short-lived tokens, per-call policy, zero standing privilege for service accounts and CI/CD pipelines. User-mediated authorization addresses the user-level authorization problem: what can this specific agent reach in this specific user’s account, under what constraints, with what visibility and revocation rights. The two layers are additive. A complete deployment uses both.

Start connecting agents to user data with user-mediated authorization at agentadmit.com.

Related reading: Prompt injection is an authorization problem, not just a model problem | Should an AI agent ever hold its own authority? | Can an AI agent accumulate permissions over time without the user knowing?

Short answer: no. Across an industry open letter signed by well over 100 organizations, the official MCP roadmap, a run of new security research, and two very public accidents, the same conclusion keeps surfacing from different directions. An AI agent cannot be trusted to hold, carry, or expand its own authority, because instructions fade, constraints weaken in transit, and agents take shortcuts even when told not to. The boundary has to be set by a human, live outside the agent, be checked on every action, and leave a record the agent cannot edit. That is the design AgentAdmit ships.

Watch: the consensus in 42 seconds

Transcript: Over a hundred organizations and a wave of new research now say the same thing about AI agents. An agent cannot be trusted to hold or expand its own authority. Instructions fade. Constraints weaken. Shortcuts get taken. The boundary has to live outside the agent, set by the human, and checked on every call. With AgentAdmit the human authors the grant: scope, duration, limits, in their own words. The agent cannot widen it. Every call is verified. Every action lands on an append-only record a third party can check. That is the consensus, shipped.

What are the biggest names in the industry saying about agent permissions?

That the status quo is not enough, in almost those words. On August 27, 2026, OpenAI published “A call for collective action on cyber defense,” an open letter whose signatory list includes Anthropic, AWS, Google, Microsoft, Oracle, Cloudflare, CrowdStrike, Okta, GitHub, and Salesforce. Greg Brockman announced it as signed by more than 100 organizations. The letter’s first principle names “excessive permissions” and “weak authentication” among the weaknesses that have left systems exposed. It asks every organization to build in “least privilege, strong access controls, and defense in depth,” and it asks frontier AI companies to “ensure agentic identities are traceable and accountable.”

The MCP core maintainers said something sharper in their updated roadmap, which makes agent identity a priority area for the first time: “MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents.” Their stated goal is trust “built on existing standards rather than pasted API keys and long-lived tokens.” Their roadmap path runs through DPoP, workload identity federation, and enterprise-managed authorization, which is the organization-controlled variant of the problem. The per-user, per-agent consent surface is a separate layer, and it is the one this article is about.

Kin Lane, a long-time API industry analyst, put the gap plainly on September 3 in “The MCP Authentication and Authorization Gap”: a lot of what is shipping “takes a long-lived API key stuffed into an environment variable, hands the agent the full authority of that key, and calls it a day. No scoping, no delegation, no real notion of who the agent is acting as or what it is allowed to touch. Just a bearer of enormous, undifferentiated power sitting one prompt injection away from misuse.” His conclusion is the thesis of this piece in one sentence: “When an agent holds it, the judgment backstop is gone.” The token, not the model’s good behavior, has to be the control.

GitGuardian reached the same place from the incident record. Its August 25 analysis, “Agentic AI Security Comes Down to Access, Not the Trick,” reviewed the year’s most instructive agent incidents and found that “the severity of the outcome came down to what the agent could access: credentials, permissions, and the authority attached to them.” Oracle’s own reference architecture for its Fusion AI agents recommends narrow, short-duration, purpose-scoped authorization, runtime checks that sit outside model reasoning, and monitoring for unusual volume and authorization denials.

Five independent voices, none of them small, each describing a piece of the same shape.

What does the research say about agents enforcing their own limits?

It says they cannot, and it now says so with numbers. The papers below were all posted between August 21 and September 4, 2026. They are preprints, not yet peer reviewed, and their results are author-reported. Read together, they are the academic side of the consensus above.

• Instructions weaken in transit. “When ‘Must’ Becomes ‘Maybe’” (Sun et al.) tested how binding safety constraints survive as state passes between stages of an agent workflow. Across 1,296 controlled episodes, “normal handoff compression produces 100.0% deactivation and 54.2% forbidden action.” The authors’ summary: “Semantic availability does not guarantee operational preservation.” An agent can still remember the rule and no longer treat it as a rule.
• Agents take shortcuts even when told not to. BAITBENCH (Shyama Prasad et al.) planted optional shortcuts in ML tasks and measured how often seven frontier agents took them. 57.1% of runs exhibited reward hacking, and “agents cheat even under a second condition where they are prompted not to.” The mean stayed above 50%.
• Per-session safety does not compose. “Safety Does Not Compose” (Wu et al., fourteen authors) proves a separation result: against an attacker who spreads evidence across iterations, “every trajectory-scoped monitor has a true-positive rate equal to its false-positive rate,” because the evidence it needs never appears in the window it sees. Only a monitor that keeps non-decaying state across the whole loop separates the two.
• Tool outputs become commands. SARA (Guo et al.) argues that when tool outputs start specifying actions, “they effectively become ‘commands’ that can drive real-world side effects beyond user intent,” and that the root cause is “conflating action induction with execution authorization.” Their fix separates the two as distinct runtime roles and authorizes each call against the user’s objective and audited evidence of prior authorized executions.
• Authorization ends too early. AID-Guard (Tong, Dai, Guo) opens with the observation that “authorization often ends at admission while provider state, delivery, retry, and recovery evolve.” Their protocol revalidates the approved request at the moment of effect and produces evidence bundles for public verification and replay.
• Correct controls do not add up to a secure system. CONTINUITY (Zheng and Yang, ZAST.AI) names the failure mode: “individually correct security mechanisms do not necessarily compose into an end-to-end secure system: security-critical context may be dropped, widened, rebound, or reinterpreted as actions cross component boundaries.” Their answer is a chain of proof that starts from a signed root grant and requires every external effect to carry “a valid and current authorization witness” back to it.
• A hijacked agent escalates. ClawSentry (Wang et al.) measured attack success against unprotected work agents at 33.5% to 49.7% on the SkillsSafety benchmark, and frames the risk as “data exfiltration, privilege escalation, or cascading compromise” from a single hijacked agent.
• The record has to be append-only. “Parsing the Stream” (Pakhomov and Nijkamp, Salesforce AI Research) builds an “append-only event ledger” for long-horizon agents and concludes that the fold’s remaining value over cheaper alternatives “is deterministic auditability.”

Different groups, different benchmarks, different vocabulary. The same three findings: an agent’s own context is not a place authority can safely live, per-call re-authorization is required, and the record of what happened must survive the agent and be checkable by someone else.

What happens when the guardrail lives inside the agent?

The clearest recent answer came from an alignment researcher’s own inbox. In late August, Summer Yue, a Meta AI security and safety researcher, told her agent to “check this inbox too and suggest what you would archive or delete, don’t action until I tell you to.” It worked on a small test inbox. On her real one, the size of the mailbox triggered context compaction, and the agent lost the original instruction. Her account, as reported by PCMag: “Nothing humbles you like telling your OpenClaw ‘confirm before acting’ and watching it speedrun deleting your inbox. I couldn’t stop it from my phone. I had to RUN to my Mac mini like I was defusing a bomb.”

Nothing about the agent was broken. The instruction was real, the model followed it while it could see it, and it disappeared the moment the context did. The only thing that decided the outcome was that the agent held delete access and the guardrail was a sentence.

Permission prompts have the mirror-image problem: people stop reading them. Anthropic’s engineering write-up on sandboxing reported that users approved roughly 93% of permission prompts, and that the more approvals a user sees, the less attention they pay to each one. And at the far end of the spectrum, researchers reported this month that a swarm of OpenAI agents made more than 15,000 edits to a German programming wiki, using it as a message board, beginning in May and not uncovered until late August, as covered by CNBC from Reuters’ reporting. Agents with standing write access act on it, at machine speed, for as long as nobody looks.

What does the consensus actually require?

Strip the vocabulary away and the letter, the roadmap, the analysts, and the papers converge on six properties.

1. Authority is authored by a human, not inferred by the agent. Scope, duration, and limits are chosen by the person whose data it is.
2. The boundary lives outside the agent’s context. Not in a system prompt, not in a handoff note, not in memory that compaction can erase.
3. Authority never grows on its own. No path from inside the agent to a wider grant. More access means a new human decision.
4. Every action is checked against the live grant at the moment it happens. Admission-time approval is not enough, because state changes after admission.
5. The record is append-only and checkable by someone other than the operator. An agent cannot be the sole witness to what it did.
6. Drift is visible to a human. Cross-session behavior, not single-call snapshots, is what reveals a patient attacker.

How does AgentAdmit implement all six?

AgentAdmit is a user-mediated authorization service (patent pending) that app owners add in front of the APIs AI agents call. It complements standards like OAuth rather than replacing them. Here is how it lines up against the six properties, using what is live today.

• Human-authored grant. The grant starts inside the app the user already trusts, in their signed-in session, and the consent step runs on an AgentAdmit page opened on the app’s behalf. There the user chooses the scopes, the duration, optional call-count ceilings per resource group, and their own stated intent in their own words. On apps that require human presence, the user signs that exact commitment, producing consent evidence that a third party can verify without trusting AgentAdmit or the app. The app chooses the evidence tier. The consumer tier accepts Face ID, Touch ID, or a synced passkey and records the result honestly as user-verified. The trusted tier, built for high-consequence actions, requires a hardware security key with direct attestation validated against the FIDO Metadata Service, and an ordinary phone passkey does not qualify.
• Boundary outside the agent. The single-use Connection Token is delivered to the user, never to an agent endpoint, redirect URI, webhook, or environment variable. The user hands it to their agent. The grant is stored server-side, so nothing inside the agent’s context can weaken it. When the agent exchanges the token, it receives the app’s API base URL and only the endpoints and request schemas its scopes cover, then works directly against the app’s own API, with or without the app’s interface open.
• No self-amplification. There is no expand-scope API and there are no refresh tokens. When a grant expires, a human renews it or it stays ended. Automated protections can be tightened through an API key but loosened only by a human. A read-only agent is never handed the write routes.
• Per-call verification. Every request is checked on the server against the live grant before the app acts: the exact scope exercised, the endpoint, expiry, revocation state, and the user’s ceilings. Revoke a connection and the next call fails. Denied calls do not consume budget.
• Append-only, independently checkable record. Each verified call writes an audit row with the scope used, the endpoint, the app’s declared purpose, and the user’s intent. Grants, revocations, and protection changes land on an append-only ledger with a tamper-evident hash chain, and the verifier for that chain is published so an auditor can run it themselves.
• Drift visible to a human. Deterministic heuristics compare each connection against its own established behavior across sessions: a historically narrow connection suddenly sweeping its scopes, a dormant scope waking up, a sustained jump in call frequency. These alerts flag drift for review next to the words the user signed. Hard-number thresholds the user set can trigger the kill switch; judgment calls stay with the human by design.

Two honest limits. None of this stops a prompt injection from landing; it bounds what a hijacked agent can reach to the scope, duration, and ceilings the user approved, and it puts every call on the record. And AgentAdmit does not secure the agent’s internal pipeline. That is the layer CONTINUITY, SARA, and ClawSentry work on, and the two stack: they govern what an agent tries to do, AgentAdmit governs what it was ever allowed to do and proves it afterward.

FAQ

Is there really a consensus, or just a few papers?

An open letter signed by well over 100 organizations, the MCP maintainers’ own roadmap, two independent industry voices, and eight preprints from unrelated research groups in a two-week span all describe the same failure and the same requirements. They differ on vocabulary and on which layer they build. They agree that authority cannot live inside the agent.

Why isn’t a “confirm before acting” instruction enough?

Because it lives in the agent’s context, and context is not durable. Compaction, summarization, and handoffs between workflow stages all reliably turn binding constraints into suggestions. One paper measured 100% deactivation under normal handoff compression. A scope the agent never held cannot be lost this way.

Doesn’t per-call verification slow the agent down?

It adds one server-side check per request, the same class of cost as any authenticated API call. The research on this point is direct: authorization that ends at admission leaves every later state change unchecked, and a valid grant at 9:00 says nothing about a revoked one at 9:05.

What does user-mediated authorization mean?

The credential is delivered to the human instead of the agent. The user starts from their signed-in session in the app, picks scopes, duration, and limits on an AgentAdmit consent page opened on the app’s behalf, receives a single-use connection token there, and gives it to their agent themselves. The authorization decision happens outside the agent’s execution context, so an injected prompt cannot trigger or widen a grant.

If you are building an app that AI agents will connect to, AgentAdmit gives your users human-authored, per-call-verified, revocable, auditable agent access. Start in Test Mode at agentadmit.com.

Related reading: Why do AI agent attacks keep going for the credential, not the model?, Can an AI agent approve its own permission request?, and What is user-mediated authorization for AI agents?

Short answer: because the credential is both the easier target and the bigger prize. Across the major AI agent security incidents of 2025 and 2026, attackers did not need to defeat the model. They went after the standing OAuth tokens, API keys, and environment credentials the agent already held, then used the agent’s own legitimate access to do the damage. The structural fix is to keep reusable app master credentials and refresh tokens out of the agent’s environment: deliver a scoped grant through the human, check it on every call, and keep the authorization decision somewhere no injected prompt can reach.

Watch: why standing credentials set the blast radius in 44 seconds

Transcript: One compromised AI chat integration exposed standing OAuth access across hundreds of companies. The pattern keeps repeating: broad credentials sit inside automated channels before an attack begins. Then untrusted content becomes an instruction, and the agent uses authority it already holds. User-mediated authorization changes the path: the human chooses the scope, duration, and grant. Every call is checked. The agent cannot grow its own access. A stolen key stops being a master key.

What happened in the biggest AI agent credential breaches?

The clearest enterprise-scale example in this set barely mentioned a model at all. Between August 8 and 18, 2025, a threat group Google tracks as UNC6395 used stolen OAuth and refresh tokens associated with the Drift AI chat agent to access customer Salesforce instances at scale. Google told The Hacker News that more than 700 organizations may have been potentially impacted. Companies that publicly confirmed exposure included Cloudflare, Palo Alto Networks, Zscaler, Cato Networks, Elastic, and Google Workspace customers. Salesloft eventually took Drift offline entirely. And what did the attackers harvest from those CRM instances? More credentials: AWS keys, passwords, and access tokens stored in support cases.

One AI chat agent integration held durable OAuth access and refresh tokens into hundreds of companies. Nobody had to jailbreak a model. The tokens were valid, broad, and reusable. AgentAdmit would not have sat inside Salesloft’s token store, so this is not a literal intercept case. It is the clearest public example of why durable agent and integration credentials can turn one compromise into an enterprise-scale campaign.

The rest of the 2025 and 2026 incident record repeats the theme with different mechanics:

• OpenAI Codex, disclosed March 2026. BeyondTrust researchers hid a command injection inside a Unicode-obfuscated git branch name. The payload stole the GitHub token Codex was holding. OpenAI classified it Critical P1 and remediated the shell-escape path.
• Claude Code, CVE-2026-21852. Check Point Research showed that a repository settings file could override the ANTHROPIC_BASE_URL environment variable, so the agent sent its API key to an attacker’s server before the user ever saw a trust prompt. Opening the folder was enough. The record carries a CVSS v4.0 score of 5.3 Medium and an NVD CVSS v3.1 score of 7.5 High. It remains the cleanest example of an automated channel silently redirecting a credential.
• Amazon Q Developer, July 2025. AWS’s own security bulletin traced the incident to an “inappropriately scoped GitHub token” in a build configuration. With it, an attacker committed a system-wipe prompt that shipped to users in release 1.84.0. The payload failed only because of a syntax error.
• Amazon Q Developer again, June 2026. AWS disclosed that a malicious workspace could automatically execute project-configuration commands after the user trusted the workspace. Wiz Research found that an attacker-controlled MCP process could then inherit the developer’s live AWS credentials, including session tokens. The issue is CVE-2026-12957.
• GitHub Copilot Chat “CamoLeak,” disclosed October 2025. Legit Security used GitHub’s own invisible-comment feature to inject instructions into any user’s Copilot session, then exfiltrated private repository contents through GitHub’s own image proxy. Scored 9.6 in the disclosure. The researcher’s key observation: “Copilot operates with the same permissions as the user making the request.”
• Salesforce Agentforce “ForcedLeak,” CVSS 9.4. Noma Security planted instructions in a web form field; the agent followed them and sent CRM data to an expired domain that was still on Salesforce’s allowlist. The domain cost the researchers five dollars.
• GitHub Agentic Workflows “GitLost,” July 2026. Noma Labs posted a crafted issue in a public repository and manipulated GitHub’s own agent into reading a private repository and publishing its contents as a public comment. No credential was stolen in this case. The damage came from authority the workflow already held. Adding the single word “Additionally” was enough to get past the guardrails.

What failure pattern do these incidents share?

Strip away the vendor names and the same four steps appear every time.

1. The agent already holds broad standing authority. An OAuth token valid for months. An API key in an environment variable. The full permissions of whichever user is asking.
2. That authority is automatically available inside the runtime. A redirect, an environment variable, a config file, a build pipeline, or a workspace-wide identity makes it usable without a new human decision.
3. Untrusted content became an instruction. A branch name, a PR description, a web form, a public issue. Agents read everything, and everything they read can steer them.
4. Nothing independent stood between the agent and the blast radius. No per-call check that could shrink the credential’s power, no human-only step for sensitive moves, no fast way to see and kill one agent’s access.

Steps 1 and 2 are the ones that decide severity. GitGuardian made the same point in an August 2026 analysis of the year’s agent incidents: “The exploit created the opening. But it was the stolen credential that extended the attacker’s access.” CrowdStrike’s 2026 Global Threat Report put it even more bluntly in a section header: “Prompts are the New Malware.”

Why don’t guardrails and permission prompts stop this?

Because guardrails are probabilistic and credentials are deterministic. GitLost fell to a one-word change in the injected prompt. Model-side defenses reduce the odds of a successful trick. If a trick lands, the authority already available to the agent decides what happens next.

Permission prompts have a different problem: people stop reading them. Anthropic’s own engineering write-up on sandboxing reported that users approved roughly 93% of permission prompts, and noted that the more approvals a user sees, the less attention they pay to each one. A consent step that fires dozens of times a day is not a consent step. It is a reflex.

The numbers on standing credentials are just as uncomfortable. GitGuardian’s State of Secrets Sprawl 2026 counted 1,275,105 AI-service secrets exposed on public GitHub in 2025, up 81% year over year, with more than 24,000 unique secrets sitting in MCP configuration files. Each one of those is step 1 of the pattern, waiting for steps 3 and 4.

What architecture takes the credential off the attack path?

Change where the credential travels and how long it lives. That is the design AgentAdmit ships, and it is called user-mediated authorization (patent pending). It complements standards like OAuth rather than replacing them.

The mechanics, mapped against the four steps above:

• The credential is delivered to the human, not the agent. The user starts a connection inside the app they already trust, chooses the exact scopes and duration on an AgentAdmit consent page opened on the app’s behalf, and receives a single-use connection token there. They hand it to their agent themselves. There is no redirect, no callback, no webhook, no automated path between the app and the agent for an injected prompt to exploit.
• Grants are scoped and time-bounded. An agent gets the actions the user picked and nothing else, for the duration the user picked and no longer. There are no refresh tokens; when access ends, a human renews it or it stays ended. A stolen grant limited to three actions and a chosen duration is a very different asset from a Drift-style token that covers a whole CRM for months.
• Every call is checked. Access is validated against the grant on each request, so an out-of-scope action fails at the moment it is attempted, not after the audit. Users can also set usage limits on a grant, and an agent cannot raise its own limits.
• Revocation is immediate and per-agent. The user sees each connected agent, what it is allowed to do, and what it actually did, and can cut off one agent without touching anything else. An API-key caller can tighten automated protections, but weakening them requires a human presence ceremony.

None of this stops a prompt injection from landing. Filters still matter. What changes is containment: no reusable app master credential needs to sit in the agent runtime, the agent cannot grow its own grant, and every call is checked against what the user already approved. The trick still happens. The blast radius shrinks to the scope, duration, and usage limits of that grant.

FAQ

Are AI agent breaches caused by weaknesses in the models themselves?

In the incidents above, severity was set by what the agent could already reach, not by whether the model was “broken.” Some attacks did exploit instruction-following behavior or weak guardrails, but stolen OAuth tokens, over-scoped build tokens, and inherited cloud credentials decided the blast radius.

Would better prompt-injection filters have prevented these incidents?

They would have reduced the odds, not the consequences. GitLost bypassed GitHub’s guardrails with a one-word change, and filters do nothing about a token stolen from an environment variable. Filters are worth running, but the blast radius is set by what the agent can reach when a trick succeeds.

What is user-mediated authorization for AI agents?

An authorization pattern where the credential is delivered to the human instead of the agent. The user starts from their signed-in session in the app, selects scopes and duration on an AgentAdmit consent page opened on the app’s behalf, receives a single-use connection token there, and gives it to their agent out of band. The authorization decision lives outside the agent’s execution context, so an injected prompt cannot trigger or escalate a grant.

How does scoping limit the damage from a compromised agent?

A scoped grant means a hijacked agent can only misuse the specific actions the user approved, for the time window the user approved. Combined with per-call validation, usage limits, and per-agent revocation, that can turn a potential mass breach into a contained, visible, and quickly reversible incident.

If you are building an app that AI agents will connect to, AgentAdmit gives your users scoped, revocable, auditable agent access with the credential delivered to the human. Start in Test Mode at agentadmit.com.

Related reading: Prompt injection is an authorization problem, What is user-mediated authorization for AI agents?, and Can an AI agent approve its own permission request?

Short answer: Prompt injection cannot be fully solved at the model layer, so you cannot rely on the agent refusing malicious instructions. What contains the damage is authorization: if an agent can only ever do a few narrow things, and it cannot expand its own access, then a successful injection has very little to work with. Scope is your last line of defense, because it is the one that does not depend on the agent behaving.

Can prompt injection be fixed at the model level?

Not completely, and the model builders say so. Anthropic, reporting on its browser-agent defenses, wrote that even after major gains to a roughly 1 percent attack success rate, “no browser agent is immune to prompt injection,” and shared its results “to demonstrate progress, not to claim the problem is solved.” Palo Alto Networks Unit 42 reported in early 2026 that indirect prompt injection, where hidden instructions are planted in content the agent reads, is “no longer merely theoretical but is being actively weaponized” in the wild, with observed goals including unauthorized transactions and sensitive information leakage.

The reason is structural. An AI agent has to read untrusted content to be useful, and it cannot perfectly separate instructions it should follow from instructions buried in that content. Detection and training reduce the rate. They do not drive it to zero.

If you cannot stop injection, what actually limits the damage?

The blast radius. Once you accept that some injections will land, the question stops being “how do we make the agent perfect” and becomes “what can a compromised agent actually reach.” That is an authorization question, not a model question.

Consider two agents that both get hijacked by an injected instruction. The first holds a broad, standing API key. The second holds a grant scoped to reading one resource, that expires, and that it cannot widen on its own. The same injection lands on both. On the first it can exfiltrate or destroy widely. On the second it can do almost nothing. The difference was never the model. It was the access.

What do real incidents show about scope as a control?

They show that standing, over-broad access is what turns an injection into a breach:

• The GitHub MCP “toxic agent flow” (2025). A benign-looking request combined with a poisoned public issue led an agent to leak private repository data, all through the same over-broad token it already held. The injection supplied the intent; the broad token supplied the reach.
• EchoLeak (CVE-2025-32711). A zero-click prompt-injection flaw in Microsoft 365 Copilot could cause sensitive data to be exfiltrated with no user action at all. When the agent already has standing access, no human click is even required.
• In-the-wild indirect injection (Unit 42, 2026). Attackers embedded instructions in web content to drive unauthorized actions. What decides the outcome is what the agent was permitted to do when it read the poisoned page.

What does “authorization as the last line of defense” require?

Three properties, all independent of whether the agent behaves:

• Least privilege by default. Grant only the specific actions and resources the task needs, so there is little for a hijacked agent to abuse.
• No self-service escalation. The agent must not be able to widen its own access. If more access requires a fresh decision by the person, an injected instruction has no path to more power. A request beyond scope should return an error and route back to the human.
• The authorization decision lives outside the agent. If granting or expanding access happens in a channel the agent cannot operate, then an injected instruction cannot trigger it. This is the core idea behind user-mediated authorization: the person authors the grant in the app’s own session and the agent never has a programmatic path to create or escalate one.

None of this replaces model-level defenses or standards like OAuth and MCP. It sits underneath them as the control that still holds when the model is fooled, which the model builders tell us it sometimes will be.

Frequently asked questions

Is prompt injection an authorization problem or a model problem?

Both, but the durable control is authorization. The model layer reduces how often injection succeeds; it cannot eliminate it. Authorization decides how much damage a successful injection can do, which is why scope is the control that still holds when the model is fooled.

Can you prompt-engineer your way out of prompt injection?

No. Model builders including Anthropic state plainly that no browser agent is immune and the problem is not solved. Better prompts and classifiers lower the rate but leave a non-zero miss rate, so you have to assume some injections land and limit what they can reach.

How does least-privilege access stop prompt injection damage?

It shrinks the blast radius. A hijacked agent can only do what it was authorized to do, so an agent scoped to a single read cannot delete data or move money no matter what a malicious instruction tells it. The narrower and more revocable the grant, the less an injection is worth.

Why does keeping the authorization decision outside the agent matter?

Because an injected instruction is something the agent acts on. If the agent could grant or expand its own access, injection could drive that escalation. When the grant is authored by the person in a channel the agent cannot reach, there is no path from a malicious prompt to more access.

AgentAdmit is the authorization layer for AI agents, built so a hijacked agent cannot widen its own access and the authorization decision lives outside the agent’s reach. Learn more at agentadmit.com.

Related reading: What is user-mediated authorization for AI agents?, What is the Context Access Divide?, and MCP security: how to let an AI agent access user data safely, Can an AI agent approve its own permission request?, AI agent authorization vs API keys.