The missing trust layer for AI agents is a way for any service to establish, at the moment an agent acts, who the agent represents, what authority it was given, whether the requested action falls inside that authority, and who is ultimately accountable. Identity tells a service which agent is calling. Authentication tells it the agent holds valid credentials. Neither, on its own, tells the service whether it should rely on what the agent is asking to do.
That gap is now central to AI agent security and AI agent governance. Agents are moving from answering questions to taking actions: booking, purchasing, filing, negotiating, operating software and calling APIs. Each of those actions lands on a service that has to decide whether to accept it. Today, most of those services have only two crude options: treat the agent as if it were the human user, or treat it as unwanted automation. Neither is adequate for an internet where humans and agents increasingly act side by side.
The questions a service actually needs answered
When an AI agent arrives at a merchant, a bank, a SaaS platform or a marketplace, the receiving service faces a set of questions that traditional infrastructure was not designed to answer together:
- Which agent is this? (agent identity)
- Who does it act for? (the principal: an individual, an organisation or another authorised service)
- Who authorised it, and how? (delegation)
- What is it allowed to do? (scope of authority)
- Is this specific action inside that scope? (action-level authorisation)
- Is the authority still valid? (expiry and revocation)
- Does this action need explicit human approval? (intent)
- Who stands behind the outcome? (accountability)
The first question gets most of the attention. The remaining seven are where the real trust decision lives. This is the territory of Proof of Authority, one of the three primitives Proof of Actor is designed around.
Why existing authentication and authorization fall short
It is tempting to assume that existing tools already cover this. They cover parts of it.
AI agent authentication
AI agent authentication establishes that a request comes from a holder of particular credentials: an API key, a signed request, a token issued to a client. That is necessary. But a valid credential says that a caller has access, not that the caller is acting within a principal's intent. A leaked key, an over-broad token or an agent that has drifted from its task all authenticate perfectly well.
AI agent authorization
Delegated authorization frameworks, such as OAuth-style scopes, were a major advance for letting applications act on a user's behalf. They work well for bounded, predictable access, such as "read my calendar". Agents strain this model in a few ways:
- Scopes describe resources, not intentions. "Can make payments" is very different from "can buy this specific flight under 500 dollars this week".
- Agents compose actions. A single goal may involve many services, each of which sees only a fragment of the task.
- The principal is often invisible downstream. A merchant may see the agent platform, not the person or organisation the agent represents.
- Approval is often given once, broadly, and early. The human consents at setup, long before the consequential action occurs.
None of this makes existing authorization obsolete. It means agents need an additional layer that carries delegated authority in a form the receiving service can evaluate against the actual action.
AI agent identity
Agent identity is necessary and increasingly well discussed. Knowing that a request comes from a specific, registered agent operated by a known provider is meaningful progress, and work such as signed HTTP requests for bots shows the direction the web is moving. But identity is the start of the conversation, not the end. A verified agent acting outside its mandate is still a problem. An unverified agent acting entirely within a clear, valid mandate may be fine. We develop this argument in What Does Know Your Agent (KYA) Actually Need to Prove?.
Delegation: making the principal visible
Every legitimate agent action traces back to someone: a person who asked an assistant to buy something, a company that deployed a procurement agent, a service that delegated a sub-task to another. That someone is the principal.
The core problem in agent trust is that the principal is usually invisible to the service receiving the action. The service sees traffic, perhaps an agent identifier, perhaps a platform name. It does not see a verifiable link between the agent and the human or organisation that stands behind it.
A delegation layer is designed to make that link explicit and verifiable:
- Human-to-agent binding: this agent acts for a verified human, whose identity may be disclosed or kept private.
- Organisation-to-agent binding: this agent acts for a verified organisation.
- Chained delegation: this agent acts for a service that itself holds authority from a principal.
Privacy matters here. A merchant dealing with a shopping agent may need to know "this agent is authorised by a verified person to spend up to 500 dollars". It almost certainly does not need that person's home address. The principle we design around is to prove what matters without revealing what doesn't, as set out on our privacy page.
Scope of authority: the mandate is the product
If delegation answers "for whom", scope answers "for what". A useful mandate is specific. Here is a conceptual illustration of the kind of scope a well-governed agent might carry:
MANDATE (conceptual illustration)
Agent Procurement Agent #4812
Principal Acme Corporation (verified organisation)
Authority Purchase SaaS subscriptions
Maximum per order 5,000 USD
Allowed vendors Approved vendor list
Legal agreements Not authorised
Human approval Required above 2,000 USD
Expires 31 December 2026
Revocable by Acme procurement administrators
Several properties make a mandate like this useful for AI agent governance:
- Bounded: limits on value, category, counterparty and action type.
- Time-bound: authority expires rather than lingering indefinitely.
- Revocable: the principal can withdraw it, and revocation takes effect for future actions.
- Explicit about exclusions: "legal agreements: not authorised" is as important as what is permitted.
- Escalation-aware: some actions inside the scope still require a human to approve this action, at this time, under these conditions.
Action-level authorisation: checking the request against the mandate
A mandate is only useful if someone checks the current action against it. This is the step most often missing in practice. A service should be able to ask: given this agent, this principal and this mandate, is the specific action being requested right now inside the authority that was granted?
The following is an API Preview. It is illustrative of how we are designing the interface and is not available today:
// API Preview - illustrative only, design is evolving
// POST /v1/authority/verify
{
"agent_id": "agt_48291",
"requested_action": {
"type": "purchase",
"amount": 420,
"currency": "USD"
}
}
// Illustrative response
{
"agent": "verified",
"principal": "verified",
"mandate": "valid",
"action_authorised": true,
"maximum_amount": 500
}
The useful output here is not "this agent is good". It is "this action is inside a valid mandate from a verified principal". That is a statement a merchant, bank or platform can reasonably build policy on. For consequential actions, the same flow can require explicit human intent, linking the agent world back to Proof of Control for the moment a human needs to confirm.
Accountability: who stands behind the action
When something goes wrong in a human transaction, there is usually a clear chain: the account holder, the payment instrument, the merchant. With agents, that chain can blur. Was the error the agent's, the platform's, the principal's, or the receiving service's for accepting the action?
A trust layer for AI agents should make it possible to answer one question for every meaningful action: who ultimately stands behind this? That requires a durable record of:
- which agent acted
- on whose behalf
- under which mandate, and whether it was valid at the time
- whether the action was inside scope
- whether human approval was required and obtained
In Proof of Actor's architecture, this record is an Actor Attestation, with a human-readable form we call an Actor Trust Receipt. For an agent interaction, a receipt might read: Actor, AI Agent. Agent identity, verified. Principal, verified organisation. Requested action, inside delegated scope. Human approval, not required by mandate. Mandate status, valid.
Accountability is not about blame in advance. It is what allows services to say yes to agents with confidence, because there is a clear answer if something needs to be unwound.
Why "block all agents" is the wrong default
Much of the web's current tooling was built to reduce unwanted automation, and it remains valuable for that. But treating every automated actor as a threat creates two problems. It blocks legitimate agents that customers actually want to use, and it pushes agents to imitate humans to get through, which makes agency less visible rather than more.
A better default is to distinguish between kinds of actor. In the Proof of Actor model, an interaction can be:
- Human: a human appears to be directly controlling the interaction.
- Human + AI: a human remains responsible while AI materially assists.
- Authorised Agent: an AI agent acts within authority delegated by an identified human or organisation.
- Unverified Actor: the trust relationship is unknown, which is not the same as malicious.
Each service then decides its own policy. A support desk may accept authorised agents. A hiring assessment may require a human. A bank may accept an agent for routine payments but require verified human intent above a threshold. Proof of Actor is designed to supply the evidence. The relying service sets the rules. See Human, Human + AI, Agent: A New Identity Model for the full model.
Where the missing layer shows up first
The need is most visible where agents spend money or change state on someone's behalf:
- Agentic commerce: merchants need to know an agent's purchase is authorised and within limits. See agentic commerce and our essay Agentic Commerce Needs a Trust Layer.
- Financial services: payment initiation, account changes and approvals by agents. See financial services.
- Enterprise automation and procurement: agents operating across SaaS tools on behalf of an organisation.
- Marketplaces: distinguishing genuine users, AI-assisted users and autonomous agents. See marketplaces.
Frequently asked questions
What is AI agent governance?
AI agent governance is the set of policies, controls and records that determine what AI agents may do on behalf of people and organisations, and how their actions are authorised, monitored, limited, revoked and attributed. A practical governance model needs verifiable delegation, scoped authority and accountable records, not only internal guidelines.
What is the difference between AI agent authentication and AI agent authorization?
AI agent authentication establishes that a request comes from a holder of particular credentials. AI agent authorization determines what that agent is permitted to do. For agents acting on someone's behalf, authorization also needs to reflect the principal's mandate and be checked against the specific action requested.
Is AI agent identity enough for AI agent security?
No. Identity tells you which agent is acting. Security decisions usually also depend on who the agent represents, what it was authorised to do, whether the current action is inside that authority, whether the authority is still valid and who is accountable.
Should services block AI agents?
Blocking all agents is increasingly impractical and often against customers' interests. A more durable approach is to distinguish authorised agents from unverified automation and apply context-specific policy to each.
Help build the trust layer
AI agents will become ordinary participants in digital life. The question is whether their agency is visible and attributable, or hidden behind credentials and imitation. Proof of Actor is building trust infrastructure for delegation, scope and accountability as part of a broader model for humans and agents sharing the internet. You can read more on how it works and in our developer preview material. We are in development and working with early design partners, and if you build agents or services that agents act upon, we would welcome you to join the Developer Preview or become a design partner.
