Short answer: An API key is a single long-lived secret that grants broad, standing access and says nothing about who is using it or what they are allowed to do. Agent authorization replaces that with a scoped, time-limited, revocable grant tied to a specific user and a specific agent, checked on every call. The difference matters because an AI agent reads untrusted content and takes autonomous actions, so a broad key it holds forever is a much bigger liability than the same key sitting in a script.
Why do so many AI agents run on static API keys today?
Because it is the path of least resistance. Most services expose a plain API and no way to grant an agent narrow, revocable access, so developers paste a static API key or personal access token into an environment variable and move on. A 2025 security scan of thousands of MCP (Model Context Protocol) servers found that, of the servers requiring credentials, roughly 53 percent relied on static API keys or personal access tokens and only about 8.5 percent used OAuth. Security researchers have taken to calling these long-lived, over-scoped secrets “the God key,” and have described MCP servers as the new shadow IT precisely because they “operate with broad privileges” and “rely on weak credential models such as long-lived static secrets.”
The key works, which is the problem. It is invisible to the user after setup, it rarely expires, and it usually carries far more access than the task needs.
What is actually wrong with giving an agent an API key?
Three things, and each gets worse when the holder is an AI agent rather than deterministic code:
It is over-broad. A key is typically all-or-nothing. The agent that only needs to read your notes can usually also delete them. There is no per-action, per-resource limit baked into the secret.
It is standing and long-lived. The key keeps working until someone remembers to rotate it. There is no built-in expiry that forces the person back into the loop.
It erases attribution. A shared key tells the service nothing about which user or which agent is behind a given call. When something goes wrong, there is no clean record of who authorized what. Security researchers describe this as the moment “user attribution is lost and least privilege controls break down.”
An AI agent amplifies all three. It processes untrusted inputs, it can be steered by prompt injection, and it acts on its own. A broad, permanent, unattributed key in the hands of something that can be manipulated is a standing liability, not a convenience.
How is scoped agent authorization different?
Agent authorization treats access as a narrow, revocable grant instead of a shared secret. The properties that matter:
Scoped. The grant names exactly which actions and resources are allowed (for example, read notes but not manage the account). A request outside that scope is refused.
Time-limited on the user’s terms. The grant lasts as long as the person chose, an hour, a week, or until they revoke it. Unlike a forgotten key, ending access is a decision the user owns, and shorter durations add deliberate friction for sensitive tasks.
Per-user and per-agent. The grant is tied to a specific person and a specific agent, so every call is attributable and the audit trail names who authorized it.
Revocable in isolation. The person can revoke one agent’s access without disturbing anyone else’s, and the change takes effect on the agent’s next call.
Note that OAuth on its own does not fully close the gap for agents. In a standard authorization-code flow the token’s subject is the human, so the resource server cannot tell the user from the agent acting for them, and there is no separate audit trail for the agent. Naming the agent as a distinct, separately-authorized party is the piece that has been missing.
What does replacing the API key look like in practice?
With user-mediated authorization, the person opens a “Connect Your AI Agent” flow from the application’s own signed-in session and picks the scopes and the duration on an AgentAdmit consent page opened on the app’s behalf. A single-use, time-limited connection credential is issued to the person on that page (not to an agent endpoint), and the person hands it to their agent. The agent exchanges it for a scoped, revocable access token that is validated on every call. The static key in the environment variable, long-lived and all-or-nothing, is replaced by a grant the user authored and can revoke.
This complements standards like OAuth and protocols like MCP rather than replacing them. MCP tells the agent what a service can do. The authorization layer decides whether this agent, for this user, is allowed to do it, and keeps that grant scoped, attributable, and revocable.
Frequently asked questions
Are API keys bad for AI agents?
They are risky as the primary access model. A static API key is long-lived, usually over-scoped, and unattributed, so an agent that holds one has broad standing access that no one is watching. That is a poor fit for software that processes untrusted input and acts autonomously. Scoped, time-limited, revocable grants are the safer alternative.
Why not just use OAuth for AI agents?
OAuth is a strong foundation, but in a standard flow the token represents the human, so the service cannot distinguish the user from the agent acting for them, and there is no separate audit trail for the agent. Agent authorization adds a per-user, per-agent, scoped grant on top of that foundation.
How do you give an AI agent least-privilege access?
Grant only the specific actions and resources the task needs, attach an expiry, tie the grant to the user and the agent, and make it revocable on its own. Then validate every call against that scope rather than trusting a single broad secret.
What is the difference between an API key and an access token here?
An API key is a standing secret that usually grants broad access indefinitely. The scoped access token described here is narrow, expires, is tied to a specific user and agent, and can be revoked without affecting other connections.
AgentAdmit is the authorization layer for AI agents: scoped, time-limited, revocable access the user controls, in place of a static key. Learn more at agentadmit.com.
Short answer: Caller-identity consent means one API surface can serve several kinds of caller, a signed-in person, the application’s own built-in AI, and an external AI agent acting for a user, and let the data owner consent to each kind independently. Granting one never grants another, and any combination is allowed. It matters because roles and scopes were built to tell humans apart, not to ask “is it a person, our own AI, or someone’s external agent,” which is now the question that decides whether data should be shared.
Watch: caller-identity consent in 37 seconds
Three Callers, One Door, a 37-second film on caller-identity consent from AgentAdmit.
Transcript: One door to your data. Three very different callers: a person, the app’s own AI, and an outside agent. Roles and scopes were built to tell humans apart. They cannot even ask which kind is calling. Caller-identity consent reads the caller’s class from the structure of its credential. A class it cannot fake. Three consent states. One endpoint. No inheritance. Changing one never changes another. Any combination the data owner wants. AgentAdmit.
What is caller-identity consent?
Picture a fitness coaching app. A member’s workout data can be reached three different ways: their coach opens it in the dashboard (a human), the app’s own built-in AI generates a summary of it (the platform’s internal AI), and the coach points their own external AI agent at it to prepare for a session (an outside agent acting for the coach). Those are three architecturally distinct callers hitting the same data through the same API.
Caller-identity consent lets the data owner decide on each one separately. The member might let their coach view the data and let the in-app AI summarize it, while blocking all external agents. Or allow an external agent to read it while denying the platform’s own AI. Each decision is independent, and changing one never changes another. That is the core property: three consent states, one endpoint, no inheritance between them.
Why don’t roles or scopes already handle this?
Because they answer a different question. Role-based access control and OAuth scopes were designed to distinguish one human user from another, or to limit what a single credential can do. They do not express “a person may see this, but our AI may not,” or “an external agent may read this, but our own AI may not.” Those distinctions are about the class of caller, not the identity of a user or the breadth of a token.
There is also a blind spot. An application’s own internal AI usually never passes through the authorization layer at all, because it is just the app’s own code reading the app’s own data. So there is often nothing to attach a consent decision to for that class. Caller-identity consent makes the internal-AI class a first-class decision the data owner can actually control, alongside humans and external agents.
How does the caller class stay un-spoofable?
Classification happens before any consent check, and it is derived from the structure of the credential, not from anything the caller can set. A standard login session, the application’s own internal service credential, and an external agent’s access token each look structurally different (by token format, prefix, signing method, issuer, or session context). The system reads those structural traits to decide the class. The caller cannot self-select or spoof it, and cannot claim to be a person while behaving as an agent.
Only after the class is fixed does the system evaluate that class’s own consent path, and each path reads only its own setting. No path inherits or even looks at another path’s preference. This is what keeps “allow the human, deny the AI” from silently leaking into “allow everything.”
How does AgentAdmit implement caller-identity consent?
AgentAdmit provides the consent-differentiation engine and the storage behind it: an independent consent state per class per data owner, an immutable consent ledger for audit, and APIs to read, set, and export those states. On the request path it validates external agent tokens (the class it issues) and enforces that class’s consent and scope directly. For the human and internal-AI classes, which live inside the application’s own boundary, the application classifies the caller from the credential and checks the matching consent path through the same engine, so all three decisions stay consistent and independent.
For the data owner’s side, the AgentAdmit React SDK ships a drop-in consent panel with three independent switches, wired through the application’s own backend so credentials never reach the browser. The result is the pattern described above, delivered as components and APIs rather than something each app rebuilds from scratch.
The switches themselves are protected against the caller they govern. Because a computer-use agent could try to flip the very consent toggles that restrict it, an app can require that any change to a data owner’s consent settings carry fresh proof of human presence, meaning a confirmation the agent cannot produce from where it runs (AgentAdmit implements this with WebAuthn user verification from a pre-registered authenticator; an approval on a separate device satisfies the same property). The same requirement can be applied when a grant elevates an agent’s existing scopes. The decision to allow a class of caller stays a human decision, made through a ceremony the caller class in question cannot complete.
This complements standards like OAuth and protocols like MCP. They authenticate the caller and describe what a service can do. Caller-identity consent adds the layer that asks, for this specific class of caller, whether the data owner agreed to this at all.
Is caller-identity consent limited to three classes?
No. Three (a human session, the application’s own AI, and an external agent) is the common set today, but the model is not fixed at three. The same design, classify the caller from the structure of its credential and then evaluate that class’s own independent path, extends to additional classes as they emerge, without disturbing the classes already in place. A natural example is a verified-agent class: as standards like Web Bot Auth let agents cryptographically prove their identity, a data owner may want to allow verified agents while still denying unverified ones, which is a separate decision from a blanket external-agent switch. A delegated-user class, for one person acting on behalf of another, is another. The point is that the independent-path model generalizes rather than hard-coding the number of caller classes.
Frequently asked questions
What is caller-identity consent in one sentence?
It is the ability for a data owner to grant or deny access independently for each class of caller, a human session, the application’s own AI, and an external AI agent, at the same API endpoint, with no class inheriting another’s permission.
How is this different from OAuth scopes or roles?
Scopes and roles distinguish users and limit what a token can do. They do not express consent per class of caller, and they usually do not cover an application’s own internal AI at all, because it never traverses the authorization layer. Caller-identity consent adds that per-class, no-inheritance decision.
Can a caller pretend to be a different class to get access?
No. The class is derived from structural characteristics of the credential before any consent check, not from anything the caller supplies. A requestor cannot self-select its class, so an external agent cannot present itself as a human session to inherit a person’s access.
Does the data owner have to allow all three, or none?
Neither. Every combination is valid: none, one, two, or all three. The decisions are independent, so a data owner can allow a human while denying both AI classes, allow an external agent while denying the platform’s own AI, or any other mix.
Can there be more than three caller classes?
Yes. Three is the common set, but the independent-path model is not limited to three. New classes, for example a verified-agent class as agent-identity standards like Web Bot Auth mature, or a delegated-user class for one person acting on behalf of another, can be added the same way: classify from credential structure, then evaluate that class’s own consent path, without changing the classes already in place.
AgentAdmit is the authorization layer for AI agents, including independent, per-caller-class consent the data owner controls. Learn more at agentadmit.com.
Short answer: Yes. If an approval screen is reachable from the place an AI agent runs, a browser tab it drives or a dialog on the machine it controls, then a compromised or prompt-injected agent can click “Approve” by itself. A confirmation click proves that something clicked, not that a human weighed the decision. The durable fix is to move the authorization decision out of the agent’s reach, so the grant is authored by the person in a channel the agent cannot operate, and the decision leaves evidence a third party can verify.
Watch: the gate the agent cannot reach, in 40 seconds
The Unreachable Gate, a 40-second film on why an AI agent should not be able to approve its own access, from AgentAdmit.
Transcript: If an approval is reachable from where an AI agent runs, the agent can complete it by itself. One prompt injection, and an instruction to approve runs like any other instruction. A click proves that something clicked, not that a person decided. User-mediated authorization moves the decision out of the agent’s reach: the person chooses the scope and duration in their own session. The agent receives only what the person handed over. It cannot grant, and it cannot grow, its own access.
Can an AI agent really click its own “Approve” button?
Yes, and vendors now say so plainly. The category has a name: computer-use agents (for example, Anthropic’s Claude Computer Use and OpenAI’s Operator, now folded into ChatGPT’s agent mode) act by reading a real screen and clicking on it the way a person would. In its November 2025 research on browser agents, Anthropic notes that these agents work by “navigating to URLs, filling forms, clicking buttons, downloading files,” and concludes that even after major robustness gains, “no browser agent is immune to prompt injection.” Their reported attack success rate dropped to around 1 percent, which they describe as still “meaningful risk,” not a solved problem. By August 2026 Anthropic had retired that evaluation as saturated and reported that, on a newer evaluation built from stronger red-team attacks, the same model and safeguards from November 2025 were beaten 16.7 percent of the time. The direction did not change: the vendor itself says no browser agent is immune.
An approval button is just another button on the screen. If the agent can see and click the page, it can see and click the “Approve” on a consent dialog rendered in that same page. This stops being theoretical once you add prompt injection. Palo Alto Networks Unit 42 documented in March 2026 that indirect prompt injection, where hidden instructions are planted in web content the agent reads, is “no longer merely theoretical but is being actively weaponized,” with observed attacker goals including “unauthorized transactions” and “sensitive information leakage.” An injected instruction that says “approve the pending request” is executed the same way as any other instruction the agent picks up.
Why isn’t a confirmation dialog enough?
Because a click is weak evidence of a considered human decision, even when a real human is present. Anthropic reported that in Claude Code, users approved “roughly 93% of permission prompts,” and observed that “the more approvals a user sees, the less attention they pay to each.” By August 2026 the published figure was 97 percent, and in Anthropic’s own controlled study human review caught 13.6 percent of dangerous commands. That is approval fatigue in the best case, where a human is actually in the loop. In the worst case, where the agent controls the input path, there is no human in the loop at all, and the click carries no signal whatsoever.
The lesson is that the security of a consent step does not come from the presence of an “Approve” button. It comes from where the button lives. If the decision surface sits inside the agent’s execution context, the agent can complete it, and the confirmation becomes ceremony rather than control.
What does a real human-in-the-loop actually require?
The approval has to be a ceremony the agent cannot complete from where it runs. In practice that means three properties:
The grant is authored by the person, not the agent. The user starts from the application’s own authenticated session and chooses the scopes and the duration on an AgentAdmit consent page opened on the app’s behalf, not through a redirect or dialog the agent set in motion.
The decision surface is outside the agent’s reach. If approving requires an action on a channel the agent does not control, an injected instruction has nothing to click.
Escalation returns to the human. When an agent needs more access than it was granted, that request cannot be self-served. It has to route back through the same out-of-band decision the person made the first time.
This is why “add a human approval step” is necessary but not sufficient. The approval step has to be one the agent physically cannot perform on its own, or it collapses back into the problem it was meant to solve.
How does user-mediated authorization solve this?
User-mediated authorization is built on exactly this separation. The person opens a “Connect Your AI Agent” flow from the app’s own signed-in session and selects what the agent may do and for how long on an AgentAdmit consent page opened on the app’s behalf. A single-use, time-limited connection credential is issued to the person on that page, on a channel the person controls, not to an agent endpoint, webhook, or callback URL. The person then hands that credential to their agent out of band, and the agent exchanges it for a scoped, revocable access token.
The point that matters here: there is no redirect, callback, or programmatic path an agent can drive to create or expand a grant. The authorization decision happens outside the agent’s execution context, so a malicious instruction injected into the agent has no button to click and no endpoint to call. If the agent later hits an operation outside its scope, it gets an insufficient_scope response, and the only way forward is a fresh, user-mediated grant. There is no self-service escalation path.
One honest edge case remains: a computer-use agent running on the person’s own machine could try to drive that consent page too. This is why the ceremony itself can be hardened. The requirement is the important part: the confirmation must be something the agent cannot complete from where it runs, such as an approval on a separate device the agent does not control, or a user-verified assertion from an authenticator registered before the task began. AgentAdmit implements this with WebAuthn user verification, the standard behind passkeys. Where the app requires presence, a grant is finalized only by a user-verified passkey ceremony whose challenge commits to the exact grant shown: the scopes, the duration, the user’s own stated intent, and any call ceilings the user set. An app can require the same ceremony for any grant that elevates an existing user’s scopes, and for changes to consent settings generally. Other mechanisms that satisfy the same property work just as well; what matters is that no approval surface reachable from the agent’s execution context counts as proof of a human decision.
This is the same failure mode behind incidents like the GitHub MCP “toxic agent flow” reported in 2025, where a benign request plus a poisoned public issue led an agent to leak private repository data through the GitHub token it already held, and the Microsoft 365 Copilot flaw tracked as CVE-2025-32711, which its discoverer Aim Security described as a zero-click prompt-injection vulnerability. In each case the agent held standing authority it could exercise without a human re-entering the loop, in the GitHub case once the user had opted to approve tool calls automatically. Moving the grant and every escalation out of the agent’s reach removes that standing authority by design.
User-mediated authorization complements standards like OAuth and protocols like MCP. MCP tells an agent what it can do; the authorization layer decides whether it is allowed, and keeps that decision where the agent cannot reach it.
What happens when one action needs a fresh human decision?
A standing grant answers “may this agent do this kind of thing.” Some actions deserve a fresh answer every time: a payment, a deletion, a message sent in the person’s name. Since September 2026, an app owner can mark a scope confirm each time. When an agent exercises that scope, the permission check refuses with confirmation_required and stages a one-time ceremony on an AgentAdmit page. The person completes a user-verified passkey ceremony whose challenge commits to the exact action shown: the scope, the method, the endpoint, a digest of the request, and the app’s summary of what will happen. The agent then retries with the attestation, and the response names the confirmation it consumed.
A decline is an answer, not a timeout. The declined action stays refused for the window the approval would have covered, and only the person can lift it. The agent has nothing to click, nothing to retry its way past, and no way to produce the signature itself. TrainerTracer, the first production integration, runs agent-initiated trainer payments through this ceremony.
How do you prove a person decided, not just that something clicked?
With evidence a third party can check. Every hosted ceremony produces Verifiable Consent Evidence: the person’s authenticator signs a commitment to the exact thing approved, and that signed record is stored with the grant, the per-action confirmation, or the settings change it authorized. An app or an auditor can export it and verify it with AgentAdmit’s public verifiers, released under the MIT license, without trusting AgentAdmit. The consent ledger and every verified call are hash-chained, so a removed or altered row is detectable.
The claim ceiling is deliberate. Consumer-tier evidence is user-verified and signed over an exact commitment, and it proves what was signed, not what a screen rendered. That is still a different kind of record from a click: the agent cannot produce it, and anyone can check it.
Frequently asked questions
Can prompt injection make an AI agent approve its own access?
If the approval surface is reachable from the agent’s execution context, yes. Prompt injection is an instruction the agent reads and acts on, and clicking an on-screen “Approve” is an action a browser or computer-use agent can take. Unit 42 documented indirect prompt injection being weaponized in the wild in early 2026, including for unauthorized transactions. The defense is to place the approval on a channel the agent cannot operate.
Can a computer-use agent approve its own consent prompt?
Yes. Computer-use agents such as Claude Computer Use and OpenAI’s Operator act by reading a screen and clicking on it, so an approval dialog rendered where the agent runs is just another button it can press. A consent step shown on the same device the agent controls therefore proves nothing. The fix is to require approval on a channel the agent cannot operate, so the decision is made outside its reach.
Is a human approval click enough to stop AI agent misuse?
Not on its own. Anthropic found users approved about 93 percent of Claude Code permission prompts and grow less attentive as prompts pile up. A click confirms that something clicked, not that a human evaluated the specific action. A confirmation step is only as strong as the agent’s inability to complete it.
How do you stop an AI agent from escalating its own permissions?
Remove the programmatic path to more access, then harden the human path. With user-mediated authorization, a request beyond the granted scope returns an insufficient_scope error, and the only way forward is a new grant the person authors themselves, starting from the app’s own session. Because a computer-use agent on the person’s machine could try to drive that session too, the elevation ceremony can additionally require a user-verified passkey ceremony that signs a commitment to the exact grant, from an authenticator registered before the task began, or an approval on a separate device the agent does not control. For individual high-stakes actions, confirm each time stages a fresh ceremony on every use, and a decline keeps the action refused.
Can an app require a fresh human decision for one specific action?
Yes. The app owner marks the scope confirm each time. Each use is refused with confirmation_required until the person completes a user-verified passkey ceremony that commits to that exact action, and the agent retries with the resulting attestation. A decline keeps the action refused for the window the approval would have covered, and only the person can lift it.
How does this relate to OAuth and MCP?
No. It complements them. OAuth and MCP handle authentication and capability discovery. User-mediated authorization adds the piece they do not: a per-user, per-agent, scoped grant that the user controls and that lives outside the agent’s execution context.
AgentAdmit is the auth layer for the agent economy: discovery, scoped grants the person authors, credential delivery to the person, per-call enforcement, confirm each time, and evidence a third party can verify, built so the authorization decision does not sit where an agent can click it. Learn more at agentadmit.com.
Short answer: The Context Access Divide is the gap between AI users whose agents can retrieve relevant context from their own files and data automatically, and users who must find and attach the right documents by hand at every prompt. The term comes from a July 2026 arXiv preprint by Masahiro Fujita, a sociologist at Kansai University. The paper argues for broader access to open dynamic retrieval across ecosystems. We agree, with one addition the paper does not address: once an agent can reach your entire corpus on its own, the deciding question becomes who authorizes that reach, for what, and for how long. That is an authorization problem, and most deployments have not solved it.
What does the Context Access Divide paper actually say?
The paper (arXiv 2607.08495, submitted July 9, 2026, a preprint that has not been peer reviewed) extends earlier work on “agentic inequality,” which measured who can access AI agents and at what capability level. Fujita’s point is that two people on the same subscription tier, using the same model, can still get categorically different value from it. What separates them is a single architectural feature: whether the system retrieves context on its own or waits for the user to supply it.
He sorts AI interfaces into three architectures. In the Manual Attachment Model, the user hunts down the relevant files and uploads them at each query. In what he calls Walled dynamic retrieval, the assistant fetches context autonomously but only inside one vendor’s ecosystem, the way Copilot reads your Microsoft 365 documents or Gemini reads your Google Drive. In Open dynamic retrieval, the agent can reach across ecosystems into local files, email, databases, and third-party services, which is what the Model Context Protocol (MCP) enables.
The core argument is that manual attachment fails mathematically as your files accumulate. Drawing on memory research, the paper models how a person’s ability to recall which documents matter degrades as the corpus grows, so for a knowledge worker with twenty years of files, hand-feeding context is not an inconvenience. It is a ceiling on what AI can do for them. Fujita calls the divide a “macro-consequential micro-variable”: a per-interaction design detail whose effects add up to society-level inequality.
What does the paper propose to do about it?
Fujita’s recommendations are aimed at platforms and regulators: transparency about which retrieval architecture a product actually ships, interoperability mandates so platforms support open retrieval protocols, data portability so users can move their corpus without losing retrieval capability, and public procurement standards that favor open architectures. He also names a market dynamic worth remembering: vendors have every incentive to offer capable retrieval inside their walls, because it delivers the user experience while deepening lock-in. Nobody profits from building the open version, so the market under-supplies it.
One thing the paper does not propose, despite how naturally it fits, is any mechanism for user control over what agents retrieve. Its governance instruments are about which architectures exist and who can access them, not about how a specific user authorizes a specific agent to touch a specific slice of their data.
The question the paper leaves open: who authorizes the retrieval?
Take the paper’s prescription seriously and picture the end state. Every knowledge worker has agents with standing, autonomous reach into their email, files, notes, calendars, and third-party accounts. The retrieval problem is solved. The trust problem has just become enormous.
Agents process untrusted input, which means their access can be turned against their owner. In the GitHub MCP incident documented by Invariant Labs in May 2025, a poisoned public issue was enough to make an agent exfiltrate private repository data, using the same token its owner had legitimately configured. The agent did not malfunction. It did exactly what its access allowed, on instructions its owner never gave.
Now look at how retrieval access is actually granted today. Astrix’s 2025 scan of MCP servers found that of those requiring credentials, 53 percent use static API keys or personal access tokens and only 8.5 percent use OAuth at all. The dominant setup behind “autonomous context retrieval” is a broad, long-lived credential in an environment variable that the user configured once and cannot see, limit, or revoke per agent. Expanding retrieval on top of that foundation does not close a divide. It scales an exposure.
This is why we read the Context Access Divide as an authorization problem wearing an inequality costume. The paper is right that autonomous retrieval is the future of useful AI. It is also the reason per-agent, user-controlled authorization stops being optional.
How user-mediated authorization makes open retrieval adoptable
The failure mode in every incident above is the same: the credential lives in an automated channel the agent controls, so whatever manipulates the agent inherits the access. User-mediated authorization (the model AgentAdmit implements, patent pending) removes that channel. The user starts the connection inside the app that holds their data, chooses exactly which scopes to grant and for how long, and receives a single-use connection token themselves. The user hands that token to their agent; the app never delivers a credential to an agent endpoint, webhook, or callback. There is no automated path from “injected prompt” to “new access.”
The result is retrieval an owner can reason about. Each agent holds a scoped, time-limited credential of its own. Every call is validated and logged. Revoking one agent takes one click and does not disturb the others. A read-only research agent can see read endpoints and nothing else. None of this restricts what the paper wants users to have. It is what makes granting that reach a sane decision, in the same way that MCP answers what an agent can do while authorization answers whether this agent, for this user, is allowed to. The approach complements standards like OAuth rather than replacing them; we have documented it in an Internet-Draft submitted to the IETF, draft-emerson-oauth-user-mediated-delivery (a work in progress).
Fujita notes a “configuration gap”: platforms supporting MCP does not mean users experience dynamic retrieval, because setup demands technical sophistication. Authorization design is part of that gap. A consent flow a non-technical user can complete, inspect, and undo is not just safer. It is one of the things that lets the people on the wrong side of the divide actually cross it.
Frequently asked questions
Is the Context Access Divide paper peer reviewed?
No. It is an arXiv preprint (cs.CY, July 2026) by a single author, Masahiro Fujita of Kansai University. That does not make it wrong, but cite it as a preprint, not as settled research.
What is the difference between walled and open dynamic retrieval?
Walled retrieval fetches context autonomously but only within one vendor’s ecosystem, like an assistant that reads your documents inside a single office suite. Open retrieval crosses ecosystem boundaries over open protocols such as MCP, reaching local files, email, and third-party services. The paper argues only the open form serves users whose data lives in many places.
Doesn’t MCP already handle authorization?
MCP specifies authentication for connections, and its 2025-2026 revisions strengthened it. What it does not give you on its own is per-user, per-agent, scoped consent that the data owner controls and can revoke. Authorization is the layer that decides what an authenticated agent is allowed to touch.
Does closing the divide mean giving agents unrestricted access to my data?
No, and it should not. The useful end state is agents with exactly the reach their owner granted: scoped to the task, time-limited, revocable in one step, and logged. Autonomous retrieval and tight authorization are not in tension. The second is what makes the first safe to adopt.
AgentAdmit is the authorization layer for AI agents: user-mediated, scoped, revocable access to the apps that hold your users’ data. See how it works at agentadmit.com.
Short answer: Discovery-by-introspection is a mechanism that tells an AI agent what it is allowed to do at the moment its credential is checked. When the agent exchanges or validates its token, the response comes back with an operational map: the endpoints its scope permits, and for each one that takes input, the exact fields, types, and which are required. The map is filtered to the agent’s granted scope, so a read-only agent is never even shown a write operation. The agent arrives knowing nothing about the app and is fully operational from that one response, with no documentation and no manual integration.
Watch: discovery-by-introspection in 37 seconds
The Lit Path, a 37-second film on discovery-by-introspection from AgentAdmit.
Transcript: Without a map, an agent guesses. And guessing breaks things. Discovery by introspection answers at the exact moment the credential is checked. Back comes an operational map: only the doors its scope permits, and the exact shape of each one. A read-only agent is never even shown a write operation. What it cannot touch does not exist. The agent arrives knowing nothing, and leaves fully operational. AgentAdmit.
The problem it solves
Connecting an agent to an app normally means someone reads the API documentation and builds an integration: base URLs, endpoint lists, field names, request formats. That work is slow, it breaks when the API changes, and it does nothing for authorization. Worse, discovery and permission are usually separate systems, so an agent can often see far more of an API than it is allowed to use, and what it can use is documented for humans, not for software that has to construct valid requests on its own.
Without structural information, an agent guesses. It sends a field named “project_title” when the endpoint expects “name,” gets a validation error, and retries. Multiply that across every endpoint and every app, and agent integrations become brittle exactly where they need to be dependable.
How discovery-by-introspection works
The mechanism runs at the same moment the agent’s credential is validated, in either of two ways: during the initial token exchange, or later, when an agent with an existing token asks the introspection endpoint to refresh its view. That refresh works only while the user’s grant is still alive. The user sets how long access lasts when they approve the connection, anything from an hour to thirty days to until-I-revoke, depending on what the app offers, and once the grant expires or the user revokes it, there is nothing left to introspect. The agent has no way to renew access on its own; getting back in takes a fresh grant from the user. Either way, the sequence is the same.
The agent presents its credential. No prior knowledge of the app is required.
The system identifies the app and the agent’s granted scopes from the credential.
The full capability map is filtered down to the agent’s scope. Operations that require permissions the agent was not granted are removed, not grayed out. Two agents connected to the same app with different scopes receive different maps.
Field-level schemas are attached. Every authorized operation that accepts input comes with its required fields, optional fields, data types, and descriptions.
One response returns everything: the app’s identity, where to send requests, and the filtered, schema-complete operation map.
The response is execution-enabling rather than descriptive. It is not documentation for a person to read; it is structure an agent can act on directly, and it stays valid whether the agent calls the operations over HTTP or registers them as tools in a tool-use framework.
Why filtering by scope matters for security
Least privilege usually stops at enforcement: the agent is blocked if it tries something out of scope. Discovery-by-introspection moves least privilege up into visibility. An agent granted read-only access receives a map containing only read operations, so the write surface of the API is not merely forbidden, it is invisible. An agent cannot be steered toward operations it has never been told exist, which shrinks what a compromised or manipulated agent can even attempt. And because the map is regenerated from the live grant, revoking or narrowing a scope changes what the agent sees, not just what it is permitted.
When an agent genuinely needs something outside its grant, there is a path, and it runs through the user. The denied request comes back naming the specific permission that was missing, so the agent can tell the user exactly what it needs and why. Granting it is a step-up: the user approves the additional scope through the same authorization flow they used the first time, or declines. There is no API through which an agent can expand its own permissions, so scope escalation always requires a conscious human decision.
How this relates to the self-describing credential
They are two halves of one connection story. The self-describing credential gets the agent to the door: the token itself tells the agent where to exchange it. Discovery-by-introspection is what the agent receives once inside: the scope-filtered, schema-complete map of what it may do. Together they take an agent from “holding a token” to “making correct, in-scope API calls” in a single exchange, with the user’s grant deciding both access and visibility. Both begin with user-mediated authorization: the user approves the scope, and everything the agent sees downstream flows from that choice.
Frequently asked questions
Is discovery-by-introspection the same as API documentation or an OpenAPI spec?
No. Documentation describes the whole API for human developers, regardless of who is asking. Discovery-by-introspection returns a per-agent view at credential-check time: only the operations that agent’s scope allows, with field-level schemas attached, in a format the agent can execute against directly.
When does the agent receive the discovery response?
Either during the initial token exchange, so a single request returns both the access token and the full operational map, or later from an introspection endpoint, so an agent with an existing token can refresh its view of what it is allowed to do without repeating authorization. The refresh only works while the user’s grant is still active: if access has expired or been revoked, the agent gets nothing, and only the user can grant access again.
What does scope filtering actually change?
It changes what the agent can see, not just what it can do. Operations outside the agent’s grant are absent from the response entirely, so a read-only agent never learns the write endpoints exist. Enforcement still checks every call, but the attack surface an agent can be pointed at is smaller from the start.
What happens when the agent needs a permission it was not granted?
The request is denied with a response naming the specific missing permission, so the agent can tell the user exactly what it needs. The user then approves the additional scope through the same authorization flow, or declines. This step-up always goes through the user; there is no API through which an agent can expand its own permissions.
Does it work with tool-use frameworks like MCP?
Yes. The discovered operations carry enough structure to be registered as tools in an agent’s tool-use framework, and the map is independent of transport, so it holds whether the agent calls operations over HTTP or through a tool interface.
Discovery-by-introspection is one of the inventions behind AgentAdmit, and it is patent pending.
AgentAdmit is the authorization layer for the agent economy: user-mediated, scoped authorization for AI agents, where one exchange returns the token and the scope-filtered map of everything the agent may do. Scoped. Revocable. Auditable. See how AgentAdmit works.
Short answer: A self-describing credential is a token that carries everything an AI agent needs to connect, so the agent can start working without separate documentation or configuration. The agent reads the exchange location out of the token itself, exchanges it once, and gets back its access token plus the scopes it was granted, the endpoints it can call, and the request schemas for each one. It turns “here is a token” into “the agent is operational” in a single step, with no shared secrets and no manual setup.
Watch: what a self-describing credential is in 37 seconds
“The Map Inside” a 37-second film on self-describing credentials for AI agents, from AgentAdmit.
Transcript: An API key is a bare secret. It says nothing, and it unlocks too much. A self-describing credential puts the map inside the token. The agent reads where to exchange it from the token itself. No documentation. No setup. One exchange returns its scopes, its endpoints, and the exact shape of every call it may make. From here is a token to fully operational, in one step. AgentAdmit.
Why connecting an AI agent to an app is usually painful
The normal way an agent gets access to an app is a scavenger hunt. Someone reads the API docs, finds the base URL, configures endpoints, wires up an auth flow, and pastes in a key. Every new integration repeats the work, and every step is a chance to over-grant access or leak a secret. The agent ends up holding a broad credential and a hand-built map of what to do with it.
A self-describing credential removes that work by putting the map inside the token.
How a self-describing credential works
Two things make the token self-describing.
The agent finds the exchange point on its own. The location where the token is redeemed is encoded in the token itself, so the agent determines where to exchange it without external instructions, documentation, or a separate discovery service.
One exchange returns everything. When the agent exchanges the token, it receives its scoped access token along with operational instructions in the same response: which app it is talking to, where to send requests, the specific endpoints its scope allows, and the field-level request schema for each of those endpoints.
The result is that an agent goes from holding a credential to making correct, in-scope calls without a human writing integration code for it.
What a self-describing credential gives you that an API key does not
An API key is a bare secret. It says nothing about who granted it, what it is for, or what the agent may do with it, and it usually unlocks far more than the task at hand. A self-describing credential is the opposite on every count:
Zero configuration. No docs, no endpoint list to maintain, no shared setup between your app and the agent.
Least privilege by construction. The endpoint map the agent receives is filtered to the scope the user approved. A read-only agent is only ever shown read endpoints, so it cannot discover or call anything beyond its grant.
No shared secrets to leak. The agent does not need pre-shared configuration or credentials to learn how to operate, because the token carries what it needs.
Does a self-describing credential work with any AI agent?
It works directly with any agent that can make HTTP requests, such as Claude Code, Codex, or a custom agent, because those agents can read the token and call the exchange endpoint themselves. Chat interfaces that cannot make arbitrary calls, like Claude Desktop or ChatGPT, connect through an MCP server that acts as the bridge. Either way the agent gets a token it can act on immediately.
Where this fits with user-mediated authorization
A self-describing credential is how the agent operates. User-mediated authorization is how the agent got the credential in the first place: the user approved a scope and the token was delivered to the user, not pushed to the agent through an automated channel. Together they mean the user decides what an agent may do, and the agent can then do exactly that, and nothing more, without a manual integration. For the granting side, see what user-mediated authorization for AI agents means.
Frequently asked questions
Is a self-describing credential the same as an API key?
No. An API key is a bare secret with no built-in meaning, usually granting broad access. A self-describing credential tells the agent where to exchange it and, after exchange, returns the scopes, endpoints, and request schemas the agent is allowed to use, so it operates in-scope without extra configuration.
How does the agent know where to send the token?
The exchange location is encoded in the token itself. The agent reads it directly from the credential and sends its exchange request there, with no external documentation or separate discovery step.
What does the agent get back when it exchanges the token?
A scoped access token plus operational instructions in one response: the app it is connecting to, where to send requests, the endpoints permitted by its scope, and the field-level request schema for each. That is enough for the agent to start making correct calls immediately.
Does the token expose every endpoint in the app?
No. The endpoint map is filtered to the scope the user approved. An agent granted read access is only shown read endpoints, so a self-describing credential stays least-privilege rather than handing over the whole surface of the app.
The self-describing credential is one of the inventions behind AgentAdmit, and it is patent pending.
AgentAdmit is the authorization layer for the agent economy: user-mediated, scoped authorization for AI agents, with a patent-pending self-describing token that makes an agent operational in one exchange. Scoped. Revocable. Auditable. See how AgentAdmit works.
Short answer: User-mediated authorization is a model where the account holder grants an AI agent access directly, and the resulting credential is delivered to the user rather than pushed to the agent through an automated channel. The user gives the credential to their agent, so there is no redirect, callback, or automated path between the app and the agent for an attacker to intercept. Access is scoped to specific actions, time-limited, and revocable. It is how you answer the question every platform now faces as agents multiply: under whose authority is this agent acting?
Watch: user-mediated authorization in 33 seconds
The Human Decides, a 33-second film on user-mediated authorization from AgentAdmit.
Transcript: Every AI agent wants access to your apps. Today, credentials travel through channels no human ever sees. User-mediated authorization changes the path. The credential is delivered to the person. The human hands the agent exactly the access they choose. Nothing more. AgentAdmit. The human decides.
Why AI agents need a different authorization model
Traditional access was built for two things: a person logging in, or one server calling another with a shared key. An AI agent is neither. It acts on a user’s behalf, often continuously, often across several services at once, and it decides in the moment which calls to make. That breaks the old assumptions in two ways:
The credential travels an automated channel. Most agent auth today leans on API keys, OAuth redirects, or environment variables. These move a credential with no human at the point of delivery, so they can be intercepted through prompt injection or misconfiguration.
The access is broad and hard to undo. Agents are often handed long-lived tokens that grant far more than the task needs, with no clean way to scope a single agent, expire its access, or revoke it on its own.
The industry has started naming what goes wrong. Security teams call the accountability problem the attribution gap: the distance between what an agent did and your ability to prove who authorized it. When a credential rides an automated channel and grants broad access, an injected instruction can turn the agent into the attacker, and afterward no one can cleanly say who approved what. A model built for AI agents has to close both halves: the interception risk and the attribution gap.
How user-mediated authorization works
Four things keep the human in control at the moment access is granted.
The user grants access directly. Approval happens with the account holder, in plain language, for specific scopes. The developer does not stand in the middle holding the keys.
The credential is delivered to the user. It goes to the human, who gives it to their agent. There is no redirect, no callback, and no automated path between the app and the agent. This is the piece most systems skip, and it is what keeps the user as the authority.
The token is self-describing. The agent extracts where to exchange it from the token itself, and after exchange it receives its scopes, endpoints, and request schemas, so it can start operating without extra configuration or shared secrets.
Access is scoped, time-limited, and revocable. The user chooses what each agent can do and for how long, and can revoke one agent’s connection at any time without affecting others.
How is this different from API keys or a normal consent screen?
An API key or service account is a single broad secret that moves through an automated channel. It cannot express who approved it, it usually grants far more than one task needs, and revoking it tends to break everything else that shares it. A standard consent screen is better, but on its own it still typically returns the credential through an automated redirect or callback and hands the agent broad access.
User-mediated authorization changes two things. The credential is delivered to the user instead of flowing to the agent automatically, and access is scoped per agent, time-limited, and revocable. The result is least-privilege access that is provable after the fact, not a broad secret you hope never leaks.
Why deliver the credential to the user instead of the developer?
Because that is what keeps the user as the authority. If the developer holds the credential, the user is trusting the developer’s infrastructure with their account. Delivering it to the user means a developer never has to custody raw credentials, and a breach of the developer’s systems does not expose user accounts.
Is user-mediated authorization the same as a standard login or authorization flow?
No. It complements standards like OAuth rather than replacing them. It changes how the credential reaches the agent, through the user instead of an automated redirect or callback, and adds per-agent scoping, expiry, and revocation, so the human approves and controls access at the moment it is granted.
Why not just push the credential straight to the agent?
Because an automated path between your app and the agent is exactly what a prompt injection or a misconfiguration can intercept. Delivering the credential to the user removes that channel. The user gives it to their agent, so there is no automated hop for an attacker to sit on.
Does this slow the agent down?
Authorization happens once per grant, when the user approves it. After that the agent operates within the scope it was given without re-prompting, and a self-describing token means it does not need extra setup to start working. The user gets control and an audit trail without turning every action into a permission dialog.
What is the simplest first step toward this model?
Stop moving raw, broad credentials to agents through automated channels. Deliver scoped access that the user approves, make each connection time-limited and revocable on its own, and keep a record of every grant.
User-mediated authorization with credential delivery to the user is the core invention behind AgentAdmit, and it is patent pending. We have also written the model up for the standards community: you can read our Internet-Draft submitted to the IETF OAuth community (a work in progress, not an adopted standard).
AgentAdmit is the authorization layer for the agent economy: user-mediated, scoped authorization for AI agents. The credential is delivered to the user, not an automated channel. Scoped. Revocable. Auditable. See how AgentAdmit works.
Short answer: MCP standardizes how an AI agent discovers and calls your tools and data, and it added an OAuth-based authorization framework to go with it. What it does not give you on its own is per-agent, scoped, revocable access that the end user controls. To let an agent access user data safely through MCP, add a layer of user-mediated authorization: the user approves specific scopes, the credential is delivered to the user rather than pushed to the agent through an automated channel, and every call is checked against that grant. MCP handles what the agent can see. User-mediated authorization handles whether it is allowed.
What MCP handles, and what it leaves to you
The Model Context Protocol solved a real problem: a common way for agents to find tools, read resources, and call them across different systems. Its authorization spec is OAuth-based and is getting stricter. The protocol’s 2026-07-28 revision hardens authorization with six changes, including issuer validation per RFC 9207 and cleaner dynamic client registration.
But a protocol that standardizes authentication and transport does not, by itself, answer the question a data owner actually cares about: which specific agent is allowed to do which specific thing with this user’s account, and can the user see it and take it back. That is authorization at the level of the individual user and the individual agent, and it is the part builders keep having to solve themselves.
The authorization gaps builders keep hitting
Three problems show up again and again when agents get access through MCP.
Static, over-broad credentials. An audit of more than 5,200 MCP servers found only 8.5% use OAuth. The majority rely on static API keys or personal access tokens, and most pass them through environment variables. A long-lived key in an env var is broad by default and rarely scoped to the one task at hand.
The confused deputy. The MCP spec itself warns about it: when a server sits in the middle as an OAuth proxy and does not properly validate consent per client, an attacker can get access to a downstream API as the user without the user’s explicit approval. The spec’s own guidance is that proxy servers must implement per-client consent. The trouble is that this is left to each implementation to get right.
Injected instructions turning access into exfiltration. Agents read untrusted content, and that content can carry commands. Invariant Labs showed a “toxic agent flow” where a malicious public GitHub issue steered an assistant into exposing private repositories through access it already held. EchoLeak (CVE-2025-32711) showed a single crafted email making Microsoft 365 Copilot leak internal data with no click. In each case the credential was valid. What failed was scoping and control over how that credential could be used.
How to close the gap: user-mediated authorization on top of MCP
User-mediated authorization is a model where the account holder grants the agent access directly, and the resulting credential is delivered to the user rather than pushed to the agent through an automated channel. The user hands it to their agent. There is no redirect, no callback, and no automated path between your app and the agent for a prompt injection or a misconfiguration to intercept.
In practice that means:
The user approves specific scopes in your app’s own UI, in plain language, in their authenticated session.
The credential goes to the user, not the agent. The authorization decision happens outside the agent’s execution context, so an injected instruction has nothing to hijack.
Access is scoped, time-limited, and revocable per agent. The user can pull one agent’s connection without breaking the others.
Every call is checked against the grant, and each grant is recorded, so you can answer who authorized this agent and for what.
This does not replace MCP. It sits on top of it. MCP tells the agent what it can do. User-mediated authorization decides whether it is allowed, on every call, under the user’s control.
How it fits with the MCP spec
MCP’s tightening authorization rules and user-mediated authorization are complementary. The spec’s hardening makes the OAuth plumbing safer between clients and servers. User-mediated authorization adds the piece the plumbing does not cover: end-user, per-agent, scoped consent that the user owns and can revoke. For an MCP server, the addition is small. Carry a user-approved token and verify it, per call, against the scopes the user granted. The agent gets a token it can use immediately, and the user keeps a dashboard of exactly which agents can do what.
Frequently asked questions
Does MCP handle authorization on its own?
MCP provides an OAuth-based authorization framework and is hardening it, which covers authentication and the client-to-server flow. It does not, by itself, give end users per-agent, scoped, revocable control over what a specific agent can do with their account. That user-level authorization is the layer you add on top.
Is an MCP server secure by default?
No. Security depends on how it is implemented. Audits show most MCP servers rely on static API keys rather than OAuth, and the MCP spec itself warns that proxy servers must implement per-client consent to avoid confused-deputy attacks. A safe deployment scopes access to specific actions, delivers the credential to the user, and checks every call against what the user approved.
What is a confused deputy attack in MCP?
It happens when a server in the middle holds a user’s authorization and passes it downstream without properly checking, per client, that this particular agent was approved for it. The attacker never steals the credential directly; they get the intermediary to use its authority on their behalf. Per-client consent and validating authorization on every call are the defenses.
Does adding user-mediated authorization slow the agent down?
Approval happens once per grant, when the user allows it. After that the agent operates within its scope without re-prompting, and a self-describing token lets it start working without extra setup. The user gets control and an audit trail without turning every action into a permission dialog.
User-mediated delivery is one of the inventions behind AgentAdmit, and it is patent pending.
AgentAdmit is the authorization layer for the agent economy: user-mediated, scoped authorization for AI agents that complements MCP. The credential is delivered to the user, not an automated channel. Scoped. Revocable. Auditable. See how AgentAdmit works.
Short answer: To let an AI agent access a user’s account safely, keep the credential off any automated channel between your app and the agent. Most agent access today runs on API keys, OAuth redirects and callbacks, or environment variables, and those channels can be intercepted through prompt injection or misconfiguration. The safer path is user-mediated delivery: the credential is delivered to the human, and the human gives it to their agent. Pair that with access that is scoped to specific actions, time-limited, and revocable, and the user stays in control of exactly what their agent can do, with a record of who approved what.
Why an AI agent changes the security picture
A normal login authenticates a person who is present and reacting to what they see. An AI agent is different. It acts on the user’s behalf, often continuously, often across several services at once, and it decides in the moment which calls to make. It also reads untrusted content along the way, and that content can carry instructions.
This is not hypothetical. In 2025, researchers showed that a single crafted email could make Microsoft 365 Copilot pull internal data and leak it to an outside server with no click from the user, a zero-click flaw tracked as CVE-2025-32711 and nicknamed EchoLeak. Around the same time, Invariant Labs demonstrated a “toxic agent flow” on the GitHub MCP server: a malicious public issue steered an assistant into exposing private repositories, using the same access the user had already granted it. In both cases the agent had a valid credential. The problem was what that credential could reach and how it was handled.
Handing that kind of actor a broad, long-lived credential through an automated channel creates three problems:
The channel can be intercepted. API keys, redirects, and environment variables move a credential with no human at the point of delivery, so a prompt injection or a misconfiguration can quietly capture it.
The access is broader than the task. A single shared key usually grants far more than the one thing the agent was asked to do, so a leak exposes the whole account.
No one can prove or undo consent. If access was arranged through automated plumbing, there is no clean record that the user approved it, and no easy way to revoke one agent without breaking the rest.
The default today leans into all three. An audit of more than 5,200 MCP servers found only 8.5% use OAuth. The majority rely on static API keys or personal access tokens, and most pass them through environment variables. Long-lived, broad, and sitting on an automated channel is exactly the combination these attacks feed on.
What user-mediated delivery means
User-mediated delivery puts the human back in the loop at the moment access is granted. Instead of the credential flowing straight from your app to the agent, it is delivered to the user. The user then gives it to their agent. There is no redirect, no callback, and no automated path between your app and the agent. The developer never has to hold the user’s raw credentials, and the user can see and control exactly what they are handing over.
The reason this matters is where the authorization decision happens. It happens outside the agent’s execution context, in the user’s own authenticated session. So an instruction injected into the agent has nothing to hijack. There is no programmatic path from “injected prompt” to “new grant of access.”
A safe-access checklist
Keep credentials off automated app-to-agent channels. Don’t push an API key, a redirect, or an environment variable straight to the agent.
Deliver the credential to the user. Route it back through the account holder, who passes it to their agent.
Scope it to specific actions. Grant the minimum the task needs, in plain language the user approves.
Time-limit it and make it revocable. Let the user set how long access lasts and revoke a single agent’s connection at any time, without affecting others.
Use a self-describing token. A good token tells the agent where to exchange it and, after exchange, hands back its scopes, endpoints, and request schemas, so the agent can operate without extra configuration or shared secrets.
Keep an audit trail. Record who approved which scope and when, and show it to the user.
What this looks like in practice
When access is delivered this way, it is least-privilege by default. An agent authorized to read one thing cannot quietly reach everything else. A single leaked token is limited to one scope on one account and can be revoked on its own. And because the user granted access directly and it was recorded, both the user and the platform can answer the question that matters as agents multiply: who authorized this, and for what.
You can, but it is the least safe option. An API key is usually broad, moves through an automated channel that can be intercepted, cannot express who approved it, and is hard to revoke without breaking everything else that uses it. Scoped, user-delivered credentials limit the damage if the agent or its host is compromised.
Does user-mediated delivery replace OAuth or a normal login?
No. It complements standards like OAuth. It changes how the resulting credential reaches the agent, through the user rather than an automated redirect or callback, and adds per-agent scoping and revocation, so the human stays in control at the moment of access.
Does the agent still end up with a credential?
Yes, and that is fine. The difference is the path. The credential is delivered to the user, and the user gives it to their agent, so there is no automated channel between your app and the agent for an attacker to intercept.
What is the simplest first step to make agent access safer today?
Stop pushing raw, broad credentials to agents through automated channels. Move to scoped access that the user approves and delivers, keep a record of each grant, and make each connection revocable on its own.
User-mediated delivery is one of the inventions behind AgentAdmit, and it is patent pending.
AgentAdmit is the authorization layer for the agent economy: user-mediated, scoped authorization that lets AI agents access user accounts with the credential delivered to the user, not an automated channel. Scoped. Revocable. Auditable. See how AgentAdmit works.
