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
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.
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?.