An actor attestation is a signed, time-bound, machine-readable statement describing who or what performed a digital interaction: whether a human was present and in control, whether AI participated, and, if an AI agent acted, which principal authorised it and whether the action fell within its mandate. It extends authentication, which establishes that an entity could access an account, into evidence about the actor performing a specific action. This article walks from the familiar session model to an attestation model, for engineers and standards practitioners who want to reason about the design rather than the marketing.
Proof of Actor is in development. The schemas and endpoints below are labelled API Preview or Proposed API: they are illustrative, and the design is evolving.
What a session actually proves
Consider the standard web flow. A user authenticates with a password, a one-time code or a passkey. The server issues a session cookie or an access token. For the lifetime of that session, requests carrying the token are treated as coming from the authenticated principal.
The guarantee here is narrow and precise: at time T0, an entity demonstrated control of a credential bound to this account. Everything after T0 is inference. The token says nothing about:
- whether the same entity is still the one sending requests at T0 + 40 minutes;
- whether a human is present at all, or an agent is driving the browser through the user's session;
- whether a remote operator, a second person or an automation tool has taken over input;
- whether AI is materially producing the content being submitted;
- whether the specific action being requested was intended by the account holder.
Strong authentication methods improve the T0 guarantee significantly. WebAuthn, the W3C standard behind passkeys, uses origin-scoped public key credentials that resist phishing far better than shared secrets. But even a perfect login only answers "can this entity access this account?". The essay Authentication Is No Longer Enough develops this gap; here we focus on what fills it.
The attestation pattern
The idea of attestation is not new, and it is worth borrowing vocabulary from work that has already been done. The IETF's Remote ATtestation procedureS (RATS) architecture, published as RFC 9334 in January 2023, describes roles that map cleanly onto the actor problem:
- an Attester produces evidence about itself;
- a Verifier appraises that evidence against policy and produces Attestation Results;
- a Relying Party consumes the results to decide whether to trust the Attester.
RATS was written primarily with devices and platforms in mind, but the separation of roles generalises. In the Actor model:
| RATS role | Actor model analogue |
|---|---|
| Attester | The interaction environment (and, for agents, the agent and its principal) |
| Verifier | The Actor Trust service, which appraises evidence about the actor |
| Attestation Results | The Actor Attestation |
| Relying Party | The application deciding whether to accept the action |
The key design consequence is that the relying party does not need the raw evidence. It needs a trustworthy summary of what was established, from a verifier it trusts, in a format it can evaluate.
Claims, evidence and confidence
Three terms are easily blurred and should not be.
Evidence is the material collected during an interaction from which conclusions are drawn. In an actor context, evidence may be sensitive. Proof of Actor does not publish which signals it uses or how they are weighed, and the architecture is deliberately signal-agnostic so that methods can change without changing the interface.
Claims are the conclusions: statements such as "a human was present", "the same actor continued throughout the session", "this agent is bound to this principal" or "the requested action is inside the mandate". Claims map onto the layers of the Actor Trust Stack: personhood, identity, presence, continuity, human control, AI participation, delegation, scope of authority, intent and accountability.
Confidence expresses how strongly the evidence supports a claim. Some claims are close to binary because they rest on cryptographic verification (a delegation signature either verifies or it does not). Others are inferential and should never be presented as certainties. Human control and AI participation fall in the second category.
This yields a simple rule: relying parties receive claims and confidence; evidence stays with the verifier wherever possible. It is better for privacy, because sensitive inputs do not propagate to every service. It is better for robustness, because publishing evidence formats invites optimisation against them. And it is better for integration, because applications reason about stable claims rather than shifting signals.
Anatomy of an Actor Attestation
Here is the conceptual attestation shape. API Preview: this schema is illustrative only 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
}
}
A few properties of this shape are deliberate.
- Per-layer claims. Each layer of the trust stack is reported separately. A forum may read only
personhood; an assessment platform may care most aboutpresence,human_controlandsession_continuity. - Explicit confidence. Inferential claims carry a confidence value. These values are risk and evidence signals, not verdicts, and should be treated that way in policy.
- Graded AI participation. Rather than a boolean, AI participation is expressed as a level. Conceptually the range includes no meaningful AI signal observed, possible assistance, probable assistance, declared assistance and autonomous agent activity.
- Identity without disclosure.
"verified": true, "disclosure": "private"expresses that identity was established without passing identity attributes to the relying party.
In a production format, the attestation would also need an envelope: an issuer, a subject or session reference, issuance and expiry times, an attestation identifier and a signature. Those elements are what make it verifiable and auditable rather than merely descriptive.
Freshness and continuity
Authentication is a point-in-time event. Many actor claims are about intervals.
Freshness concerns how recently a claim was true. "A human was present at 12:41 UTC" is useful at 12:42 and much less useful the next day. Attestations should carry issuance times and short validity windows for claims that decay, and relying parties should reject stale attestations for consequential actions. RATS treats freshness as a first-class concern for the same reason: evidence about a past state says little about the present one.
Continuity concerns whether a claim held across a span. "The same verified candidate remained present for the whole assessment" is a different and stronger statement than "a verified candidate was present when the assessment started". Continuity is what addresses hand-offs, substitution and session takeover, and it is central to Proof of Control.
The practical implication is that an attestation request should specify not just which claims are wanted but over what window. A request at login and a request covering an entire high-value session are different requests.
Selective disclosure
The governing principle is: prove what matters without revealing what doesn't. A merchant dealing with an agent may need "authorised to spend up to $500", not the principal's home address. A forum may need "unique real human", not a name or date of birth.
Two mechanisms help.
First, claim minimisation at request time. The relying party asks only for the claims its policy requires, and the attestation contains only those.
Second, cryptographic selective disclosure where a credential has to travel. Established work exists here. The W3C Verifiable Credentials Data Model 2.0, published as a W3C Recommendation in May 2025, defines a standard way to express claims made by an issuer about a subject in a verifiable form. The IETF's SD-JWT specification (RFC 9901, November 2025) defines a way for an issuer to sign a JSON payload so that the holder can later reveal only chosen claims, with optional binding to a holder-controlled key. Formats like these show that "reveal this claim, withhold that one" is an engineering problem with standardised answers, not an aspiration.
Proof of Actor is designed to align with this direction: separable claims, minimal disclosure by default and formats that can interoperate with existing credential ecosystems where that serves relying parties. Our wider position is on the privacy page.
Agents: signed delegation, scope and revocation
When the actor is an AI agent, the most important claims are not inferential at all. They concern authority, and authority can and should be cryptographic.
OAuth 2.0 already recognises the distinction between impersonation and delegation. RFC 8693 (OAuth 2.0 Token Exchange) describes delegation as one party acting on behalf of another while remaining identifiable as itself, and defines an act (actor) claim to express that relationship in a token. This is a useful foundation: an agent should not be indistinguishable from its principal.
An attestation for AI agents needs to carry more than "A acts for B", though. A relying party evaluating an agent action needs:
| Element | Question it answers |
|---|---|
| Agent identity | Which agent is this? |
| Principal | Which human or organisation stands behind it? |
| Binding | Is there a verifiable link from principal to agent? |
| Scope | What kinds of action are permitted? |
| Limits | What amounts, counterparties or categories apply? |
| Expiry | Until when is the authority valid? |
| Revocation status | Has the principal withdrawn the authority? |
| Intent | For this action, did a human explicitly approve it? |
A concrete mandate makes this tangible:
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
Revocation deserves emphasis. A delegation that cannot be withdrawn is a liability. Revocation status must be checkable at the moment of the action, not cached from the moment the mandate was issued, which ties revocation directly to freshness.
Intent is the final layer. Standing authority covers routine actions. For consequential ones, a relying party may require evidence that a human approved this action, at this time, under these conditions. That is a distinct claim, produced by a distinct step, and it should appear distinctly in the attestation. Proof of Authority is the primitive designed for this layer.
How a relying party consumes an attestation
The interaction pattern we are designing is straightforward. Proposed API, illustrative only. These endpoints describe the Developer Preview design direction, not available services.
The relying party first declares its requirements:
POST /v1/verifications
{
"requirements": {
"human_presence": true,
"continuous_control": true,
"ai_disclosure": true
}
}
It then retrieves the actor status for that verification:
GET /v1/verifications/{verification_id}
{
"actor_type": "human",
"confidence": 0.97,
"human_presence": "verified",
"human_control": 0.94,
"ai_participation": "low",
"continuity": 0.99
}
For agent actions, it checks a requested action against the agent's authority:
POST /v1/authority/verify
{
"agent_id": "agt_48291",
"requested_action": {
"type": "purchase",
"amount": 420,
"currency": "USD"
}
}
{
"agent": "verified",
"principal": "verified",
"mandate": "valid",
"action_authorised": true,
"maximum_amount": 500
}
Where the action requires explicit human approval, the relying party can request intent:
POST /v1/intent
And it can retrieve the signed record of what was established:
GET /v1/attestations/{id}
The crucial step happens on the relying party's side. It verifies the attestation's signature and freshness, then applies its own policy. A hiring platform might require actor_type of human with high continuity and low AI participation. A marketplace might accept human, human + AI or an authorised agent. A bank might require verified identity, current presence and explicit intent for a large transfer. Proof of Actor supplies evidence; the relying party decides what is acceptable. The How It Works page shows this flow end to end.
Auditability and the trust receipt
Consequential decisions get reviewed: in disputes, audits, incident response and regulatory enquiries. An attestation model should therefore produce records that survive the moment of decision.
The Actor Trust Receipt is the human-readable representation of an attestation:
ACTOR TRUST RECEIPT
Actor Human
Personhood Verified
Identity Verified privately
Presence Continuous
Human control High confidence
AI involvement Low
Session continuity High confidence
Issued 12:41 UTC
Attestation ID act_91fk28...
For auditability, the receipt should reference a signed attestation by identifier, record issuance time, and be tamper-evident. It should also respect the same minimisation as the attestation itself: a receipt that leaks the evidence it summarises defeats the purpose. Further detail on the format lives on the Actor Attestations page.
Design considerations for standards work
For readers working on standards, several open questions seem worth stating plainly.
- Claim vocabulary. Interoperability depends on shared definitions of presence, continuity, human control and AI participation. Agreement on what a claim means matters more than agreement on wire format.
- Confidence semantics. Numeric confidence is only portable if its meaning is documented. Coarse bands may travel better between issuers than raw numbers.
- Delegation chains. Agents may delegate to sub-agents. Attestations should be able to express a chain back to an accountable principal, with scope narrowing at each step.
- Revocation at the speed of action. Agent transactions are fast. Revocation checks need to be fast too, or relying parties will skip them.
- Declared AI assistance. A healthy ecosystem rewards honest declaration. Formats should give declared assistance a clear, first-class representation distinct from inferred assistance.
We are exploring these questions openly and publish our thinking on the research page.
Frequently asked questions
What is an actor attestation?
An actor attestation is a signed, machine-readable statement describing what could be established about who or what performed an interaction: personhood, presence, continuity, human control, AI participation and, for agents, delegation and scope of authority. A relying party verifies it and applies its own policy.
What is a trust receipt?
A trust receipt, or Actor Trust Receipt, is the human-readable representation of an actor attestation. It records what was established, when and under which attestation identifier, so that decisions can be reviewed later in audits or disputes.
How does attestation for AI agents differ from attestation for humans?
Human attestations rely mainly on inferential claims, such as presence and control, expressed with confidence. Attestation for AI agents relies mainly on verifiable authority: a signed binding between agent and principal, a defined scope with limits and expiry, current revocation status and, for consequential actions, explicit human intent.
Does an actor attestation replace OAuth or passkeys?
No. Passkeys and OAuth remain the right tools for authentication and authorisation of access. An actor attestation adds evidence about who or what is acting after authentication, and can complement delegation constructs that already exist in those ecosystems.
Contribute to the design
The attestation model is still being designed, and we expect it to improve through contact with real integration constraints. If you are building systems that need to consume evidence about actors, or working on related standards, we would value your input. You can join the Developer Preview or become a design partner, and review the current interface direction on the Developers page.
