Proof of Actor is a proposed trust infrastructure for determining whether a digital interaction is being performed by a human, a human using AI, or an autonomous AI agent, and for establishing who authorised the action. It defines a category we call Actor Trust Infrastructure: the layer a digital service can query, after authentication and alongside its own authorisation rules, to learn who or what is actually acting, whether a human is present and in control, whether AI is involved, and who is accountable. Proof of Actor is currently in development.
Entity relationships
For readers and systems that want the structure at a glance:
Proof of Actor
Category: Actor Trust Infrastructure
Core products:
Proof of Human
Proof of Control
Proof of Authority
Output:
Actor Attestation
Supporting terms used throughout this essay:
- Actor: the entity actually performing or controlling a digital interaction.
- Principal: the human or organisation ultimately represented.
- Actor Trust: the overall category of trust concerned with Actors.
- Actor Attestation: the machine-readable result describing what could be established.
- Actor Trust Receipt: a human-readable representation of an attestation.
- Actor Policy: the rules a relying application sets for what it will accept.
The problem Proof of Actor addresses
Much of the internet's trust machinery rests on an assumption: behind meaningful digital activity is a human being. A face on a video call suggested a person was present. A logged-in account suggested its owner was acting. A completed form suggested a person filled it out.
Generative AI, autonomous agents, synthetic media and remote-control tools have made that assumption unreliable. Passing authentication no longer establishes that the authenticated person is controlling the current interaction. Knowing who owns an account does not tell a service whether that person, another person or an AI agent is acting through it.
The question is therefore changing from "is this a bot?" to a broader one:
Who or what is actually acting?
That shift matters because blocking all automation is neither realistic nor desirable. AI assistants will research, write, negotiate, book, purchase and operate software on people's behalf. The problem is not that AI participates. The problem is when agency becomes invisible. As we put it internally: AI does not need to disappear from digital interactions. It needs to become attributable.
For the background on why existing authentication does not answer this question, see our essay on why authentication is no longer enough.
The Actor model
An Actor is the entity actually responsible for producing or controlling a digital interaction. Proof of Actor is designed around four Actor states:
| State | Meaning | Example |
|---|---|---|
| Human | A human appears to be directly controlling the interaction | A candidate completes an assessment personally |
| Human + AI | A human remains responsible, but AI materially assists | A professional writes an email with an AI writing assistant |
| Authorised Agent | An AI agent acts for an identified human or organisation within delegated authority | A shopping agent buys a flight within its user's budget |
| Unverified Actor | The service cannot establish the Actor, human control or accountable principal with sufficient confidence | A session with no declared principal and insufficient evidence |
Unverified does not mean malicious. It means the trust relationship is unknown. And no state is ranked above another in the abstract. A Human + AI interaction is entirely acceptable in many places; an Authorised Agent is exactly what an agent-friendly checkout wants to see.
The Actor graph
The central picture of Proof of Actor is the Actor graph:
ACTOR
|
+-----------+-----------+
| | |
HUMAN HUMAN+AI AGENT
|
PRINCIPAL
|
AUTHORITY
|
ACTION
For human and AI-assisted interactions, the questions concentrate at the top of the graph: is a human present and in control, and how much is AI participating? For agent interactions, the questions move down the chain: which principal does the agent represent, what authority was delegated, and is this specific action inside that authority? Every branch ends in the same place: who is accountable?
The Trust Stack
Answering "who or what is acting" is not a single check. Proof of Actor is designed to reason across ten distinct layers, each with its own question.
| Layer | Question |
|---|---|
| Personhood | Is there evidence that a real human exists behind this interaction? |
| Identity | Is this human the person they claim to be? (Optional where anonymity matters) |
| Presence | Is the human actually present during this interaction, not just earlier? |
| Actor continuity | Is the same Actor continuing throughout the session? |
| Human control | Is the human actually controlling the interaction? |
| AI participation | Is AI materially participating, and to what degree? |
| Delegation | If an agent is acting, who authorised it? |
| Scope of authority | What is this Actor allowed to do? |
| Intent | Did the human explicitly approve this action, at this time, under these conditions? |
| Accountability | Who ultimately stands behind this action? |
Separating these layers is deliberate. Personhood is not identity: a service may need to know a real human is present without learning who they are, which is why the model supports "verified human, identity undisclosed". Presence is not control: a person can be present in front of a screen while something else operates the session. Authority is not intent: an agent may hold a valid mandate, while a bank still wants explicit human approval for a particular large transfer.
Human control deserves special mention because it is the layer least served by existing tools. Authentication proves access. Identity verification proves identity. Presence evidence shows someone is there. None of them, on their own, shows that the human is directing what happens.
The three primitives
The Trust Stack is broad. To make it usable, Proof of Actor is designed as three related primitives that a service can request depending on what it actually needs.
Proof of Human
Question: Is a real human here?
Proof of Human addresses personhood and presence. It is relevant wherever a service needs to know a real person is participating: account creation, communities, reviews, dating, polls and promotions. It can be combined with identity, or deliberately kept separate from it.
Proof of Control
Question: Is the human actually controlling this interaction?
Proof of Control addresses continuity, human control and AI participation across a session rather than at a single moment. It is relevant to assessments, interviews, financial approvals, high-risk account actions and video communication.
Proof of Authority
Question: If an AI agent is acting, who authorised it and what may it do?
Proof of Authority addresses delegation, scope, limits, expiry and revocation. It is relevant to agentic commerce, travel, procurement, financial services and enterprise automation. A conceptual mandate might look like this:
Agent: Procurement Agent #4812
Principal: Acme Corporation
Authority: Purchase SaaS subscriptions
Maximum transaction: $5,000
Allowed vendors: Approved vendor list
Legal agreements: Not authorised
Authority expires: 31 December 2026
The three primitives are designed to compose. A bank might ask for Proof of Human plus Proof of Control on a payee change. An airline might accept either a human or an agent with valid Proof of Authority.
The output: Actor Attestations
Whatever combination a service requests, the intended output is a single standardised Actor Attestation: a machine-readable record describing what Proof of Actor could establish about an interaction, with confidence levels rather than absolute verdicts.
Its human-readable form is the Actor Trust Receipt. An illustrative receipt for an agent interaction:
ACTOR TRUST RECEIPT
Actor AI Agent
Agent identity Verified
Principal Verified organisation
Authority Verified
Requested action Inside delegated scope
Human approval Not required by mandate
Mandate status Valid
The machine-readable form is still being designed. The following is an API Preview and is illustrative only; field names and structure will change.
API Preview (illustrative, Developer Preview - API design is evolving)
{
"actor": { "type": "human" },
"personhood": { "verified": true },
"identity": { "verified": true, "disclosure": "private" },
"presence": { "continuous": true },
"human_control": { "level": "high" },
"ai_participation": { "level": "low" },
"session_continuity": { "level": "high" }
}
Attestations are designed to be selective. A forum may need "unique real human". It does not need a name, date of birth or passport number. A merchant dealing with an agent may need "authorised to spend up to $500". It does not need the principal's home address. The guiding principle is prove what matters without revealing what doesn't. More detail on the format is on Actor Attestations.
Evidence, not verdicts: who decides policy
A core design decision is the separation between evidence and policy:
Proof of Actor supplies trust evidence. The customer determines acceptable policy.
Proof of Actor is not designed to decide whether an interaction should be allowed. It is designed to describe the Actor as well as the available evidence permits, and to say how confident that description is. The relying service then applies its own Actor Policy. A conceptual example:
Proposed API (illustrative)
policy.allow({
actor: ["human", "authorised_agent"],
agentAuthority: { required: true }
});
This matters for two reasons. First, trust is contextual: a forum comment and a large wire transfer should not require the same evidence. Second, it keeps the system honest. Signals produce confidence, not certainty, so outcomes are described as "high confidence" or "no significant evidence observed", never as guarantees.
What Proof of Actor is not
Proof of Actor will likely use or interoperate with adjacent technologies, but it is not primarily any one of them:
- Not only bot detection. Bot detection asks whether traffic looks automated. Proof of Actor asks whether automation is occurring, whether it is legitimate and who stands behind it.
- Not a CAPTCHA replacement. A single challenge at session start cannot establish continuity, control or authority.
- Not KYC. Identity verification answers "who are you?". Proof of Actor additionally asks "who is acting right now?", and can work without disclosing identity at all.
- Not only proof of personhood. Personhood answers "are you a real human?". Proof of Actor adds presence, control, AI participation and authority. See Proof of Human vs Proof of Actor.
- Not deepfake detection. Rather than asking only whether media looks synthetic, it asks who is responsible for the interaction regardless of how the media was produced.
Design principles
The architecture is being developed around a short list of principles: signal-agnostic (not tied permanently to any single technique), multi-signal (trust from independent evidence rather than one fragile check), continuous where sessions are high-value, contextual, privacy-aware, explainable, revocable for agent authority, and auditable for consequential actions. We publish what Proof of Actor is designed to establish. We are deliberately selective about how individual signals are evaluated.
Frequently asked questions
What is Proof of Actor in simple terms?
Proof of Actor is trust infrastructure, currently in development, that is designed to tell a digital service who or what is actually acting in an interaction: a human, a human using AI or an authorised AI agent, and who is accountable for the action.
What is actor trust?
Actor trust is the category of trust concerned with the entity actually performing a digital action, rather than only the account or credential used. It covers personhood, presence, continuity, human control, AI participation, delegation, scope of authority, intent and accountability.
What is actor trust infrastructure?
Actor trust infrastructure is a layer that applications can query before relying on a digital Actor. It supplies evidence about the Actor in a standard form, such as an Actor Attestation, which each application then evaluates against its own policy.
Is Proof of Actor available today?
Proof of Actor is in development. We are working with early design partners, and developers can join the Developer Preview to follow and shape the API design. API examples on this site are proposals and are labelled as such.
Does Proof of Actor block AI agents?
No. The model treats an Authorised Agent as a legitimate Actor state. The goal is to make agency explicit and attributable, so that services can welcome agents they can account for and set their own rules for the rest.
Help shape the category
Actor Trust Infrastructure is a new layer, and the right version of it will be built with the services that need it. If you operate an interaction you currently struggle to trust, or you are building agents that need to prove who they represent, we would like to work with you. Join the Developer Preview or become a design partner.
