A Trust Model for Humans and AI Sharing the Internet

A trust model for humans and AI sharing the internet is a way for digital services to establish, for any meaningful interaction, who or what is acting: a human, a human assisted by AI, an AI agent acting with delegated authority, or an actor whose nature cannot yet be established. It combines evidence about personhood, presence, human control, AI participation and delegated authority into a portable attestation, and leaves the decision about what is acceptable to the service that relies on it. That is the model Proof of Actor is designed around, and this essay sets it out in full.

Most of today's trust infrastructure answers narrower questions. Authentication tells a service whether an entity can access an account. Identity verification tells it who owns an identity. Bot detection estimates whether traffic looks automated. Each of these remains useful. None of them, alone or together, answers the question that matters once humans and AI agents operate side by side: who or what is performing this action, right now, under whose authority?

The assumption that quietly broke

The internet was built on an assumption that was rarely stated because it rarely needed to be: behind most meaningful digital activity is a human being.

That assumption carried an enormous amount of weight. A face on a video call suggested a person was present. A voice on a phone call suggested a person was speaking. A completed form suggested a person filled it out. A logged-in account suggested its owner was acting. A review suggested a customer wrote it. A purchase suggested the account holder intended it.

Generative AI, autonomous agents, synthetic media, remote-control tools and capable automation have weakened every one of those inferences. Seeing a face no longer establishes that a human is present. Passing authentication does not establish that the authenticated person is controlling the current interaction. Knowing who owns an account says nothing about whether that person, another person or an AI agent is acting through it.

The old question was "Is this user a bot?" It assumed two categories, human and malicious automation. The new reality has more categories, and many of them are legitimate. A professional drafting an email with an AI writing assistant is not a bot. A shopping agent booking a flight within a budget its owner set is not an attack. A support agent operated by a company and clearly disclosed as such is not deception.

The problem is not that AI participates. The problem is when agency becomes invisible. For a longer treatment of why login-time checks cannot carry this weight, see Authentication Is No Longer Enough.

The Actor model

An Actor is the entity actually responsible for producing or controlling a digital interaction. The model deliberately avoids treating every automated interaction as malicious. Its goal is transparency and accountability, not exclusion.

Proof of Actor uses four Actor states.

Actor state	Meaning	Example
Human	A human appears to be directly controlling the interaction.	A candidate completes an assessment personally, without meaningful external AI assistance.
Human + AI	A human remains responsible for the interaction, but AI materially assists.	A professional writes an email using an AI writing assistant.
Authorised Agent	An AI agent acts on behalf of an identified human or organisation, within delegated authority.	A shopping agent purchases a flight within a budget its user specified.
Unverified Actor	The service cannot establish the actor, human control or accountable principal with sufficient confidence.	An interaction arrives with no usable evidence about who or what is behind it.

Two points about this table matter more than the table itself.

First, Unverified does not mean malicious. It means the trust relationship is unknown. Plenty of ordinary traffic will sit in this state, and a service may be entirely comfortable with that for low-stakes actions.

Second, the states are descriptive, not a ranking. Human is not "better" than Authorised Agent. An agent with a clear principal and a narrow, verifiable mandate may be more trustworthy for a specific transaction than an anonymous human session. The essay Human, Human + AI, Agent: The Internet Needs a New Identity Model explores the classification in more depth.

Trust is contextual

Because no Actor state is universally better, the right answer to "should we allow this?" depends on what is being done. The same evidence can justify very different decisions in different settings.

Context	Acceptable actors (illustrative policy)
Hiring assessment	Human
Customer support interaction	Human or Authorised Agent
Online marketplace	Human, Human + AI or Authorised Agent
Bank approving a major transfer	Verified human identity + current human presence + explicit human intent

A hiring assessment is measuring the candidate's own ability, so material AI assistance changes what the result means. A support desk may be glad to deal with a customer's agent that can prove whom it represents. A marketplace may welcome all three legitimate states, provided each is labelled honestly. A bank moving a large sum may want the strongest combination available, including proof that a person approved this specific action.

This leads to the central division of labour in the model:

Proof of Actor supplies the evidence. The relying service decides the policy.

A trust layer that tried to decide policy for everyone would either be too strict for open communities or too permissive for regulated finance. Separating evidence from policy lets one model serve both.

The Actor Trust Stack

"Is this trustworthy?" is too coarse a question to answer well. The model decomposes it into ten distinct layers. Each asks a different question, can be established with different evidence and may or may not matter for a given interaction.

Personhood

Is there evidence that a real human exists behind this interaction?

Personhood is not identification. A forum may only need to know that each account belongs to a unique real person, without learning who that person is.

Identity

Is this human the person they claim to be?

Identity is optional by design. Many legitimate contexts should preserve anonymity or pseudonymity. The model aims to support an outcome such as "verified human, identity undisclosed".

Presence

Is the human actually present during this interaction?

Passing identity verification fifteen minutes earlier does not establish current presence. Presence is a property of now, not of the past.

Actor continuity

Is the same actor continuing throughout the session?

Continuity addresses hand-offs, substitution, session takeover, impersonation and remote assistance: cases where the actor who started an interaction is not the one finishing it.

Human control

Is the human actually controlling the interaction?

This is one of the most important layers and one of the least served today. Authentication proves access. Identity proves identity. Presence proves presence. None of them necessarily proves control. A person can be present, authenticated and verified while a script, a remote operator or an agent does the work. The essay What Is Human Control Verification? covers this layer in detail.

AI participation

Is AI materially participating in the interaction?

The honest answer is often graded rather than binary. Useful outputs include: no meaningful AI signal observed, possible AI assistance, probable AI assistance, declared AI assistance and autonomous agent activity. Declared assistance deserves special attention, because a system that rewards honest disclosure is healthier than one that only tries to infer.

Delegation

If an AI agent is acting, who authorised it?

The principal could be an individual, an organisation or another authorised service. Without a principal, an agent's actions have no one standing behind them.

Scope of authority

What is this actor allowed to do?

A mandate should be specific. Consider a procurement agent:

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

A merchant can check a requested action against a mandate like this. A purchase of a $1,200 subscription from an approved vendor sits inside it. Signing a master services agreement does not.

Intent

Did the human explicitly approve this action, at this time, under these conditions?

For consequential actions, standing authority may not be enough. A service may want evidence that a person approved this particular transfer, this particular contract or this particular change of beneficiary.

Accountability

Who ultimately stands behind this action?

Every meaningful attestation should make this answerable. Accountability is what turns an anonymous action into an attributable one.

Not every interaction needs every layer. A product review might need personhood and nothing else. A remote examination might need presence, continuity and human control. An agent purchase might need delegation, scope and accountability. The stack is a menu of questions, and a service asks only the ones that matter.

Three primitives: Human, Control, Authority

The ten layers cluster naturally into three verification primitives, which together form the platform we are building.

Primitive	Core question	Typical contexts
Proof of Human	Is a real human here?	Communities, social networks, reviews, dating, account creation, polls, anti-Sybil systems
Proof of Control	Is the human actually controlling this interaction?	Assessments, interviews, financial approvals, high-risk account actions, video communication
Proof of Authority	If an AI agent is acting, who authorised it and what may it do?	Agentic commerce, financial services, travel, procurement, insurance, enterprise automation

Proof of Human concerns personhood and presence. It is designed to establish that a real person is behind an interaction without, by default, establishing which person. Its relationship to the broader model is explained in Proof of Human vs Proof of Actor.

Proof of Control concerns continuity, human control and AI participation. It is where the model moves beyond "a human exists" to "a human is doing this, now". It is the primitive most relevant when the integrity of a result depends on who actually performed the work.

Proof of Authority concerns delegation, scope, intent and accountability for agents. It is designed to bind an agent to a principal, express what the agent may do, check a requested action against that mandate, and support expiry and revocation. The Missing Trust Layer for AI Agents discusses why this primitive matters as agents begin to transact.

The primitives are composable. A bank approving a large transfer initiated by an agent might ask for Proof of Authority to validate the agent's mandate, then Proof of Control to establish that the account holder personally approved this specific action.

Attestations and Trust Receipts

Evidence is only useful if it can be consumed. The output of the model is an Actor Attestation: a machine-readable statement of what could be established about an interaction, with what confidence, at what time.

The conceptual shape looks like this. Proposed API, illustrative only. The schema is evolving and does not describe a production interface.

{
  "actor": {
    "type": "human",
    "confidence": 0.97
  },
  "personhood": {
    "verified": true
  },
  "identity": {
    "verified": true,
    "disclosure": "private"
  },
  "presence": {
    "continuous": true,
    "confidence": 0.98
  },
  "human_control": {
    "confidence": 0.94
  },
  "ai_participation": {
    "level": "low",
    "confidence": 0.88
  },
  "session_continuity": {
    "confidence": 0.99
  }
}

Notice three design choices. Confidence is expressed explicitly rather than hidden behind a yes or no. Identity can be verified while remaining undisclosed. And each layer of the stack is reported separately, so a relying service can reason about the parts it cares about.

The human-readable counterpart is an Actor Trust Receipt. For an agent transaction, a receipt might read:

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

Receipts matter because trust decisions are eventually reviewed by people: auditors, support teams, dispute handlers, regulators and the principals themselves. A receipt makes the basis for a decision legible after the fact. More detail on the format is on the Actor Attestations page.

Any confidence value in an attestation should be read as a risk and evidence signal, not an absolute verdict. The model never claims that an interaction is "100% human". It reports what the evidence suggests and how strongly.

Prove what matters without revealing what doesn't

A trust layer that requires everyone to reveal everything would be worse than the problem it solves. The model is built around one privacy principle:

Prove what matters without revealing what doesn't.

In practice this means each claim is disclosed at the minimum granularity the relying service needs.

Service	Needs to know	Does not need to know
Community forum	Unique real human	Full name, date of birth, passport number
Merchant dealing with an agent	Agent is authorised to spend up to $500	The principal's home address
Hiring platform	The same verified candidate remained present during the assessment	Government identity data, stored permanently

Selective disclosure is not a feature bolted onto the end. It shapes the attestation format (claims are separable), the policy model (services request specific claims rather than whole profiles) and data handling (collect the minimum required for the requested claim). Our current thinking on data handling is set out on the privacy and security pages.

This principle also keeps the model away from surveillance. The purpose is to let an interaction carry the specific evidence it needs, not to build a dossier on every participant.

Policy: services declare what they need

If the trust layer supplies evidence and the service decides policy, the service needs a clean way to express that policy. The concept we are developing is a policy engine in which applications declare their trust requirements.

Proposed API, illustrative only. The interface below is a design sketch for the Developer Preview, not an available SDK.

// Proposed API - illustrative only
policy.require({
  actor: "human",
  presence: "continuous",
  control: 0.90,
  aiAssistance: "low"
});

A remote assessment might use a policy like the one above. A marketplace that welcomes agents might instead write:

// Proposed API - illustrative only
policy.allow({
  actor: ["human", "authorized_agent"],
  agentAuthority: {
    required: true
  }
});

Declarative policy has practical benefits. It makes trust requirements reviewable by security and compliance teams. It lets the same evidence feed different decisions across different flows in one product. And it lets a service tighten or relax requirements without rebuilding its verification stack.

Architecture principles

The model only works if the infrastructure under it follows a few firm principles. These are the principles our architecture is being developed around.

• Signal-agnostic. The architecture should not be permanently tied to webcams, biometrics or any single technique. Methods will change; the questions will not.
• Multi-signal. Trust should emerge from independent evidence rather than one fragile check.
• Continuous. High-value interactions often need evidence throughout the session, not only at login.
• Contextual. The evidence required to comment on a forum should differ from the evidence required to transfer $1 million.
• Privacy-aware. Collect the minimum information required for the requested claim.
• Explainable. Applications need to understand the evidence behind a trust outcome, not just the outcome.
• Revocable. Agent authority must be withdrawable, and withdrawal must take effect.
• Auditable. Consequential attestations should produce reliable records.
• Developer-first. Integration should eventually be easier than building internal verification infrastructure.

Readers who want to see how these principles shape the request and response flow can start with How It Works and the Developers overview.

How the model fits with existing infrastructure

The Actor model is additive. It does not replace authentication, identity verification, payments infrastructure or agent protocols. It sits alongside them and answers a different question.

Existing layer	Question it answers	What the Actor model adds
Authentication	Can this entity access this account?	Who or what is acting through the account right now?
Identity verification	Who owns this identity?	Is that person present and in control?
Bot detection	Does this traffic look automated?	Is the automation legitimate, and who stands behind it?
Proof of personhood	Is this a real human?	Is that human currently present and controlling this interaction?
Agent identity	Which agent is this?	Who authorised it, what may it do, and is this action inside that authority?

The emerging field has many contributors working on adjacent pieces, from personhood systems to agent identity and agent payments. The broader Actor problem asks how those pieces combine into a single answer a relying service can act on. What Does "Know Your Agent" Actually Need to Prove? and Why CAPTCHAs Cannot Solve the AI Agent Problem look at two of these adjacent approaches.

The long-term vision: agency made explicit

Today, websites carry transport security information that browsers can read and users have learned to expect. Over time, digital interactions could carry Actor information in a similar way.

A user might see a simple marker that the person they are speaking with is a verified human. A service might receive:

ACTOR: HUMAN
CONTROL: VERIFIED

An agent transaction might carry:

ACTOR: AI_AGENT
PRINCIPAL: VERIFIED
AUTHORITY: VALID
ACTION: WITHIN_SCOPE

And an uncertain interaction would simply say:

ACTOR: UNVERIFIED

None of these labels is a judgement. Each is a fact a service can apply its own policy to. The objective is not to make AI invisible, and not to push it out. It is to make agency explicit, so that every consequential action can establish who or what performed it, who authorised it and who is accountable.

This is the belief the whole model returns to:

AI does not need to disappear from digital interactions. It needs to become attributable.

An internet where humans and AI share the work is not a problem to be solved. An internet where nobody can tell who is acting is. The difference between the two is a trust layer.

Frequently asked questions

What is AI agent trust?

AI agent trust is the ability of a service to rely on an action taken by an AI agent. It depends on knowing which agent is acting, which human or organisation authorised it, what it is permitted to do, whether the specific action falls inside that permission, and who is accountable if something goes wrong. Agent identity alone is not enough; delegation, scope and accountability complete the picture.

Does this trust model try to block AI?

No. The model treats Human + AI and Authorised Agent as legitimate Actor states. Its purpose is to make AI participation visible and attributable so that each service can decide, by policy, where AI is welcome. Blocking all AI activity is neither realistic nor desirable.

How is human and AI agent trust different from bot detection?

Bot detection estimates whether traffic looks automated, usually to block it. A human and AI agent trust model asks a wider set of questions: whether a human is present and in control, whether AI is assisting, and, when an agent is acting, who authorised it and within what limits. It aims to distinguish legitimate automation from illegitimate automation rather than treating all automation as a threat.

Is Proof of Actor available today?

Proof of Actor is in development. We are building the infrastructure described here and working with early design partners. API examples on this site are labelled API Preview or Proposed API and are illustrative only.

Does the model require revealing personal identity?

No. Identity is one optional layer of the stack. The model is designed to support outcomes such as "verified human, identity undisclosed" and to disclose only the claims a relying service needs.

Help shape the model

The trust model described here is still being designed, and the most useful input comes from teams who already face interactions they cannot fully trust: agent transactions, remote assessments, high-risk account changes, communities under pressure from synthetic accounts. If that describes your work, we would value hearing from you. You can join the Developer Preview or apply to become a design partner, and follow ongoing work on the research page.