The internet needs an identity model that describes who or what is acting, not just which account or credential is in use. We propose four Actor states: Human (a person acting directly), Human + AI (a person in control, with AI materially assisting), Authorised Agent (an AI system acting for an identified human or organisation within delegated authority) and Unverified Actor (the service cannot establish the Actor or its authority with sufficient confidence). This model sits alongside existing human identity and non-human identity (NHI) practices. It does not replace them.
Two buckets that no longer cover the field
For most of the history of enterprise and consumer identity, the world has been divided into two kinds of identity.
Human identities belong to people: employees, customers, citizens. They are verified at onboarding, authenticated at login and governed by user-access policies.
Non-human identities belong to software: service accounts, API keys, OAuth client credentials, machine certificates, workload identities, CI/CD tokens and similar. They allow systems to authenticate to other systems. Non-human identity management has become a significant discipline in its own right, because in many organisations these credentials vastly outnumber human accounts and are often long-lived, over-privileged and poorly inventoried.
This two-bucket model worked because each bucket had a clear behavioural profile. Humans exercised judgement but acted slowly and in person. Software acted quickly and at scale, but deterministically, doing what its code specified.
AI agents break that clean separation. And AI-assisted humans blur it from the other direction.
What non-human identity covers, and what it does not
It is worth being precise, because "non-human identity" is increasingly used in conversations about AI agents.
Non-human identity management is primarily concerned with:
- Inventory: which machine credentials exist, and where.
- Ownership: which team or system is responsible for each one.
- Least privilege: whether each credential has only the permissions it needs.
- Lifecycle: issuance, rotation, expiry and revocation of secrets and certificates.
- Authentication between workloads: how one service proves to another that it is the expected service.
These are important problems, and they apply to AI agents too: an agent calling an API needs credentials, and those credentials should be managed well.
But NHI answers a question about the credential: what is this key, who owns it, and what can it access? It does not, on its own, answer the questions a relying service now has about the Actor:
- Is this request being produced by a deterministic integration, an AI agent exercising judgement, or a human?
- If it is an agent, which human or organisation does it represent?
- What did that principal actually authorise it to do, and is this action inside that scope?
- Is the authority still valid, or has it been revoked?
- If a human is involved, are they present and in control, or has AI taken over most of the work?
A service account for a nightly data export and an AI agent negotiating a purchase on a person's behalf may both present an API key. Treating them as the same kind of thing loses exactly the information a merchant, bank or platform needs.
Non-human identity vs Actor identity
| Non-human identity (NHI) | Actor model | |
|---|---|---|
| Primary subject | Credentials and workloads | The entity actually producing an interaction |
| Typical examples | Service accounts, API keys, certificates, workload identities | Human, Human + AI, Authorised Agent, Unverified Actor |
| Core question | What is this credential and what can it access? | Who or what is acting, who controls it, who authorised it? |
| Concern with humans | Mostly out of scope | Central: presence, control and AI participation |
| Concern with delegation | Permissions granted to a workload | Principal, mandate, scope, expiry and revocation for an agent |
| Accountability | Owning team or system | The human or organisation that stands behind the action |
The two are complementary. A well-managed agent credential is a good input to the Actor question. It is not the answer to it.
Why AI agents need their own category
An AI agent is not simply a faster script. Three properties make it different from traditional non-human identities.
Agents act with discretion. A traditional integration calls the same endpoint with the same shape of request every time. An agent decides which actions to take, in which order, and how to interpret ambiguous instructions. Two runs with the same instruction can produce different actions.
Agents represent someone. A shopping agent is acting for a particular person. A procurement agent is acting for a particular company. The relying service often cares more about that principal than about the agent software itself.
Agents carry bounded authority. "Book me a flight under $600 to Mumbai next Friday" is a mandate with a scope, a limit and an implicit expiry. Whether a given action falls inside that mandate is a question no ordinary API key can answer.
This is why "AI agent identity" or "agentic AI identity" has to mean more than "a credential for the agent". A useful agent identity binds together:
- the agent (which system is acting),
- the principal (which human or organisation it represents),
- the authority (what it is permitted to do, with what limits, until when), and
- the action (whether this specific request is inside that authority).
We explore what each of these needs to prove in What Does "Know Your Agent" Actually Need to Prove? and in The Missing Trust Layer for AI Agents. In Proof of Actor, this is the territory of Proof of Authority.
Why AI-assisted humans are a distinct case
The less discussed, and arguably harder, category is the human who is working with AI.
A person using an AI writing assistant to draft a message is still the Actor in a meaningful sense: they chose to send it, they are accountable for it, and they are present. But the content of the interaction has been materially shaped by AI. For some contexts, that is irrelevant. For others, it is the whole point.
Consider a few cases:
- A customer drafting a support request with AI help. Almost no service would object.
- A professional writing a client report with AI assistance. Often acceptable, sometimes subject to disclosure rules.
- A candidate answering a technical assessment that is meant to measure their own ability. Many employers would want to know.
- A product review where the account holder used AI to generate the text. A review platform may want that disclosed.
The existing two-bucket model has no place for this. The account is human. The credential is human. The person is genuinely present. Yet the interaction is not purely human either.
Labelling these interactions as "bot" would be inaccurate and unfair. Ignoring AI participation entirely would remove information a service legitimately needs. A distinct Human + AI state solves this: it acknowledges that a human remains responsible, while making AI participation explicit.
We also think the model should avoid overconfident binaries. AI participation is often a matter of degree and evidence. Proof of Actor is designed to describe it in graded terms, such as "no meaningful AI signal observed", "possible AI assistance", "declared AI assistance" or "autonomous agent activity", rather than a single yes or no.
The four Actor states
Putting this together, Proof of Actor is designed around four states.
| Actor state | Who is acting | Example | Often appropriate for |
|---|---|---|---|
| Human | A human directly performs the interaction | A candidate completes an assessment personally | Assessments, high-value approvals, identity-sensitive actions |
| Human + AI | A human remains responsible; AI materially assists | A professional drafts an email with an AI assistant | Everyday productivity, communication, many marketplace actions |
| Authorised Agent | An AI agent acts for an identified principal within delegated authority | A shopping agent buys a flight within its user's budget | Agentic commerce, customer service, procurement, scheduling |
| Unverified Actor | The service cannot establish the Actor, control or principal with sufficient confidence | An automated session with no declared principal | Low-risk browsing; higher-risk actions may need more evidence |
Two points are important.
First, Unverified Actor does not mean malicious. It means the trust relationship is unknown. Many legitimate interactions will start there, and a service can decide what to permit before more evidence is available.
Second, no state is universally better than another. Trust is contextual. A hiring assessment might require Human. A customer support channel might allow Human or Authorised Agent. A marketplace might allow Human, Human + AI or Authorised Agent. A bank approving a large transfer might require verified identity, current presence and explicit human intent. The model provides vocabulary and evidence; the relying service decides policy.
The Actor graph
A simple way to visualise the model:
ACTOR
|
+-----------+-----------+
| | |
HUMAN HUMAN+AI AGENT
|
PRINCIPAL
|
AUTHORITY
|
ACTION
For humans and AI-assisted humans, the important questions are about personhood, presence, continuity and control. For agents, the important questions move down the graph: who is the principal, what authority was delegated, and is this action inside it? In both cases the chain ends in accountability: who ultimately stands behind this action?
What this means for builders
If you are building an AI agent, the Actor model suggests your agent should eventually be able to present not only a credential, but evidence of its principal and the scope of its mandate. If you run a platform, it suggests your policies should distinguish between "an account did this" and "a human, an AI-assisted human or an authorised agent did this".
Proof of Actor is in development. We are designing three primitives that map onto the model: Proof of Human for personhood and presence, Proof of Control for whether a human is actually directing the interaction, and Proof of Authority for agent delegation. The proposed output is an Actor Attestation, a machine-readable record that a service can evaluate against its own rules. The architecture is privacy-aware by design: a platform should be able to learn "verified human, identity undisclosed" or "agent authorised by a verified organisation" without receiving more personal data than it needs.
You can see how the states play out in specific settings, such as marketplaces and social networks, on our use-case pages.
Frequently asked questions
What is a non-human identity?
A non-human identity (NHI) is a digital identity used by software rather than a person, such as a service account, API key, OAuth client credential, certificate or workload identity. NHI management focuses on inventory, ownership, least privilege and the lifecycle of these credentials.
Is an AI agent a non-human identity?
An AI agent typically uses non-human credentials, so it has an NHI. But an agent also acts with discretion and on behalf of a principal, with bounded authority. Describing it fully requires agent identity, principal identity and the scope of delegated authority, not only the credential.
What is agentic AI identity?
Agentic AI identity refers to how an autonomous AI agent identifies itself and proves who it acts for. A useful agentic identity binds the agent, its principal, the authority it was given and whether a particular action falls within that authority, so that a relying service can decide whether to accept the action.
Why not just classify everything as human or bot?
Because many real interactions are neither purely human nor purely automated. A person using AI assistance is still present and accountable, and an authorised agent may be entirely legitimate. A binary model either over-blocks legitimate activity or hides information services need.
Towards a shared vocabulary
The internet does not need AI to disappear from digital interactions. It needs AI to become attributable. A shared vocabulary for Human, Human + AI, Authorised Agent and Unverified Actor is a first step towards that. We are building the infrastructure to supply evidence for it, and we are working with early partners to test the model against real interactions. If this describes a problem you face, join the Developer Preview or become a design partner.
