Authentication verifies that an entity can prove possession of valid credentials for an account. Authorisation determines what that authenticated account is allowed to do. Neither tells a service who or what is actually performing the current action. A correct password, a passkey or a valid session token proves access, not control. In an internet where humans, humans assisted by AI and autonomous AI agents all act through the same accounts, a third question now matters as much as the first two: who or what is actually acting?
This essay explains authentication vs authorization accurately, shows where each one stops, and introduces the Actor question that sits beyond both.
Authentication vs authorization: the short answer
Authentication answers "Are you who you claim to be?" in the narrow sense of "can you present credentials bound to this account?" Authorisation answers "What are you allowed to do?" once that has been established.
A useful way to remember it: authentication is about the key, authorisation is about which doors the key opens.
Both terms are often abbreviated as "AuthN" (authentication) and "AuthZ" (authorisation). American English spells the second one "authorization"; British English, which we use on this site, often spells it "authorisation". They mean the same thing.
Authentication in practice
Authentication mechanisms establish that the party presenting credentials controls something associated with an account. Common factors include:
- Something you know: a password, PIN or passphrase.
- Something you have: a phone receiving a one-time code, a hardware security key, or a device holding a passkey.
- Something you are: a biometric used to unlock a local authenticator.
Multi-factor authentication combines two or more of these. The output of authentication is usually a session, a cookie or a token that the service trusts for some period of time.
Authorization in practice
Authorisation takes an authenticated identity and decides whether a specific request is permitted. Typical models include role-based access control (an "admin" can delete records, a "viewer" cannot), attribute-based access control (access depends on properties of the user, the resource and the context) and scoped tokens.
A widely used example of the split is the relationship between OAuth 2.0 and OpenID Connect. OAuth 2.0 is defined as an authorisation framework: it lets an application obtain limited access to a service on behalf of a user, using access tokens. OpenID Connect is described by its specification as an identity layer on top of OAuth 2.0, which lets the application verify who the end user is based on authentication performed by an authorisation server. One protocol is about permissions; the other adds identity.
HTTP status codes reflect the same distinction, if with confusing names. A 401 Unauthorized response generally means the request lacks valid authentication credentials. A 403 Forbidden response means the server understood who is asking but will not permit the request. The first is an authentication problem; the second is an authorisation problem.
Comparison table
| Authentication | Authorisation | |
|---|---|---|
| Core question | Can this entity prove it holds credentials for this account? | Is this account permitted to perform this request? |
| Common shorthand | AuthN | AuthZ |
| Happens | First, usually at login or token issue | After authentication, on each protected request |
| Typical inputs | Password, passkey, one-time code, security key, biometric unlock | Roles, scopes, attributes, policies, resource ownership |
| Typical output | Session, cookie, ID token | Allow or deny decision, access token scope |
| Example standard | OpenID Connect (identity layer) | OAuth 2.0 (authorisation framework) |
| Failure response | Often HTTP 401 | Often HTTP 403 |
| What it does not tell you | Who is operating the session after login | Whether the entity using the permission is the account holder |
The last row is the reason this essay exists.
The gap after the login
Both authentication and authorisation were designed around an assumption that held for most of the web's history: behind a logged-in session is the person who logged in. Once credentials were checked, a service could reasonably treat every subsequent click, form submission and message as coming from that person.
That assumption is weakening. After a successful login, any of the following can happen without a single credential changing:
- The account holder gives an AI agent control of the browser session to complete a booking.
- The account holder uses an AI assistant to draft every answer in a written assessment.
- A different person takes over the keyboard while the original person remains logged in.
- Remote-access software allows someone in another location to operate the device.
- A session token is copied and replayed by an automated system.
- The account holder delegates future actions to an agent, which then acts hours later while the human is asleep.
From an authentication standpoint, all of these sessions are valid. From an authorisation standpoint, every action falls within the account's permissions. Yet the entity actually producing the interaction may be a human, a human working with AI, an autonomous agent acting on genuine instructions, or something the account holder never sanctioned.
Some of those situations are perfectly acceptable. A customer using a shopping agent they deliberately configured is not doing anything wrong. A professional drafting an email with an AI assistant is not doing anything wrong. The issue is not that AI is involved. The issue is that the service cannot tell, and therefore cannot apply the policy it actually wants.
The third question: who or what is acting?
We describe the entity actually responsible for producing or controlling a digital interaction as the Actor. The Actor question is distinct from both established questions:
| Question | Layer | What it establishes |
|---|---|---|
| Can this entity access the account? | Authentication | Possession of credentials |
| What is this account allowed to do? | Authorisation | Permissions attached to the account |
| Who or what is performing this action right now? | Actor | The nature, control and authority of the party acting |
Answering the Actor question means looking at several properties that authentication and authorisation do not cover:
- Presence: is a human actually present during this interaction, not merely fifteen minutes ago at login?
- Continuity: is the same Actor continuing throughout the session, or has there been a hand-off?
- Human control: is the human directing the interaction, or is something else operating it?
- AI participation: is AI materially involved, and if so, is that declared?
- Delegation and scope: if an AI agent is acting, who authorised it, and is this action inside the authority it was given?
- Accountability: who ultimately stands behind the action?
We explore the full set of layers, from personhood to accountability, in What Is Proof of Actor?.
Four Actor states
To keep this practical, Proof of Actor is designed around four understandable Actor states:
- Human: a human appears to be directly controlling the interaction.
- Human + AI: a human remains responsible, but AI materially assists.
- Authorised Agent: an AI agent acts on behalf of an identified human or organisation within delegated authority.
- Unverified Actor: the service cannot establish the Actor, human control or accountable principal with sufficient confidence. This means "trust relationship unknown", not "malicious".
We discuss why AI-assisted humans deserve their own category in our essay on a new identity model for humans, AI-assisted humans and agents.
Why stronger authentication does not close the gap
A natural response is to make authentication stronger: more factors, phishing-resistant passkeys, shorter session lifetimes, step-up prompts. These are valuable, and services should adopt them. They make it much harder for an unauthorised party to obtain access in the first place.
But stronger authentication still answers the same question. A passkey ceremony proves that someone with the enrolled device and local unlock was present at that moment. It does not describe what happens in the forty minutes after the ceremony, or whether the account holder subsequently handed the session to an agent. Re-prompting for authentication more often adds friction to every user without distinguishing between the human who is genuinely acting and the human who has just unlocked a session for something else to use.
Similarly, finer-grained authorisation narrows what an account can do, but it applies the same rules regardless of who or what is exercising the permissions. A scope that allows "make purchases up to $500" says nothing about whether the account holder, an agent they configured, or an unknown automated process is making the purchase.
The Actor layer is complementary, not a replacement. Think of it as the layer that begins where authentication ends.
What the Actor layer looks like in a real decision
Consider three situations a relying service might face, all from fully authenticated, fully authorised sessions.
A hiring assessment. A candidate logs in and completes a technical test. The employer's policy is that the candidate should complete it personally. What the employer needs is evidence that the same verified candidate remained present and in control throughout, and whether AI materially participated. See hiring for how this context shapes policy.
A high-value transfer. A banking customer adds a new payee and sends a large payment. The bank may want verified identity, current human presence and explicit human intent for this specific action at this specific time.
An agent purchase. A travel agent built by a third party books a flight on behalf of its user. The airline may be entirely happy to accept agent traffic, as long as it can establish which principal stands behind the agent and that the purchase falls inside the agent's delegated limit.
In each case the policy is different. The evidence each service needs is different. None of it is supplied by a login.
A conceptual policy
The following is illustrative only. It shows how a relying service might express Actor requirements alongside its existing authorisation rules.
Proposed API (illustrative, Developer Preview - API design is evolving)
ACTOR POLICY: payee_change
Authentication Required (existing)
Authorisation Account role: owner (existing)
Actor
Allowed Human
Presence Current
Human control High confidence
Intent Explicit approval for this action
Agent access Not permitted for this action
And for an agent-friendly flow:
ACTOR POLICY: flight_booking
Actor
Allowed Human, Human + AI, Authorised Agent
If Authorised Agent
Principal Verified
Mandate Valid, not revoked
Action Inside delegated scope
The principle we design around is simple: Proof of Actor supplies trust evidence. The customer determines acceptable policy. Nothing in this model assumes one Actor type is universally better than another.
How Proof of Actor approaches the problem
Proof of Actor is in development. We are building it as three related primitives that a service can request depending on what it actually needs to know:
- Proof of Human asks whether a real human is here.
- Proof of Control asks whether that human is actually controlling this interaction.
- Proof of Authority asks, when an agent is acting, who authorised it and what it may do.
The intended output is an Actor Attestation: a machine-readable record of what could be established about an interaction, with a human-readable form we call an Actor Trust Receipt. The architecture is being designed to be multi-signal, contextual and privacy-aware: a service should be able to learn "verified human, identity undisclosed" without receiving data it does not need.
We are deliberately not publishing how individual signals are evaluated. What matters for the reader here is the shape of the answer: a confidence-based description of the Actor, not a binary verdict, and never a claim of certainty.
Frequently asked questions
What is the difference between authentication and authorization?
Authentication verifies that an entity holds valid credentials for an account, for example by password, passkey or one-time code. Authorisation (or authorization, in American spelling) decides what that authenticated account is permitted to do, using roles, scopes or policies. Authentication comes first; authorisation is applied to each request afterwards.
Which comes first, authentication or authorization?
Authentication normally comes first, because a service needs to know which account is making a request before it can decide what that account may do. Some systems issue tokens that carry both identity information and permission scopes, but the logical order remains: establish the account, then evaluate permissions.
Is OAuth authentication or authorization?
OAuth 2.0 is an authorisation framework. It lets an application obtain limited access to a resource on a user's behalf. OpenID Connect adds an identity layer on top of OAuth 2.0 so that applications can also authenticate the user.
Does multi-factor authentication prove a human is in control?
Multi-factor authentication provides strong evidence that the account holder, or someone with their factors, was present at the moment of login. It does not, by itself, establish who or what operates the session afterwards, whether AI is participating, or whether control has passed to an agent or another person.
What does "Actor" mean in this context?
The Actor is the entity actually responsible for producing or controlling a digital interaction. It may be a human, a human assisted by AI, an authorised AI agent acting for a principal, or an unverified Actor whose nature or authority cannot be established. The concept is explored further in From Authentication to Actor Attestation.
Building beyond the login
Authentication and authorisation remain essential. They are simply no longer the whole answer. As more interactions are performed by agents and AI-assisted people through ordinary accounts, services will need a way to ask who or what is actually acting, and to receive evidence they can apply to their own policy. We are building that layer now, in the open on the concepts and carefully on the details. If your service has an interaction it currently struggles to trust, we would value hearing about it: join the Developer Preview or become a design partner.
