x401 Agent Identity Protocol for Product Managers

The Problem x401 Solves

When a human visits your website, you can infer identity from cookies, authentication tokens, and session state. When an AI agent visits, you know almost nothing. You know there is traffic, but you do not know who authorized the agent, what it is allowed to do, or whether the actions it takes reflect a real user's intent.

This was a minor issue in 2024. By late 2026 it is not. Browser agents, research agents, purchasing agents, and workflow agents are generating a measurable fraction of web traffic at major consumer and enterprise products. OpenAI's Dots agents, ChatGPT browser use, Anthropic's computer use, and third-party agent frameworks like CrewAI and AutoGen all make web requests on behalf of users. The requests look like traffic, but the verification problem is unsolved.

x402 (also from Proof) solved the payments layer in 2025: it gave agents a standard way to pay for access to APIs and web content using programmable money. x401 is the identity layer: it gives agents a standard way to prove who sent them and what they were authorized to do before the interaction happens.

No principal verification

Your server cannot confirm that the agent visiting your product was actually authorized by the account it claims to represent. Anyone can write an agent that claims to act on behalf of any user.

No scope declaration

Even if you trust the agent is legitimate, you do not know what it is allowed to do. Can it read only, or can it write? Can it make purchases, or only browse? The agent might not know its own limits accurately.

No audit trail

When an agent takes a damaging action, it is very hard to determine after the fact whether the user authorized that specific action or whether the agent exceeded its mandate. This is a legal and product liability gap.

No revocation mechanism

Users who revoke access to an app expect all downstream effects to stop. With unverified agents, revoking OAuth credentials from an app does not necessarily stop a persistent agent that has cached credentials or state.

How x401 Works (at the Level That Matters for PMs)

x401 is an open HTTP-based protocol. The core exchange happens in request headers. When an agent makes a request, it includes an x401 header that contains a signed credential bundle. The bundle has three parts: a principal claim (this agent was authorized by user X), a scope declaration (this agent is allowed to do Y and Z), and a cryptographic signature that proves the bundle was issued by the operator's signing key.

The receiving server validates the signature against the operator's public key, which is published at a well-known URL (similar to how DKIM DNS records work for email). If valid, the server knows: this is a legitimate agent acting on behalf of a real user, with declared authorization scopes, from an operator who has published their public key.

The operator

The company or developer whose agent is making requests. They issue signed credentials to their agents and publish their public key. Think Anthropic (for Claude's computer use), or your company if you ship agents to customers.

The agent

Software acting on behalf of a principal. It carries a signed credential bundle in every request it makes. It does not have to be an LLM-based agent; any automated client can implement x401.

The principal

The user or organization on whose behalf the agent is acting. The credential bundle names the principal and binds the agent's actions to an authorization record the principal created.

The target

The website, API, or product the agent is visiting. The target validates the x401 header, checks the declared scope against what the request is trying to do, and decides whether to allow it.

The analogy to OAuth is intentional and useful. OAuth solved the user identity delegation problem for apps: instead of giving a third-party app your password, you grant it scoped access via an authorization server. x401 solves the same problem for agents: instead of an agent presenting a user's session token (which cannot be scoped), it presents a purpose-built agent credential with explicit permissions.

The Two Sides Every PM Is On

Unlike most infrastructure decisions that live entirely within your engineering team, x401 requires product thinking on two fronts simultaneously. Most product teams will need to reason about both within the next 18 months.

You as an operator (your agents visit other products)

When this applies: When you ship any feature that sends AI agents to act on behalf of users. Examples: a workflow agent that reads invoices from a user's accounting software, a research agent that pulls data from third-party APIs, a browser agent that executes purchases on a user's behalf.

What you need to build: You need to implement x401 credential issuance: generate signing keys, define scope vocabularies for what your agents can do, and include signed credential bundles in outbound agent requests.

Risk of inaction: Without x401, the products your agents visit may start rate-limiting or blocking unverified agent traffic. This risk is not hypothetical: major web platforms have already begun treating unverified agent traffic differently than verified traffic.

You as a target (agents visit your product)

When this applies: When users of your product start sending agents to interact with it. Any product that has an API, a web UI, or a structured workflow is a potential target. If your product handles consequential actions (purchases, data writes, account changes), this is urgent.

What you need to build: You need to implement x401 validation: verify incoming agent credentials, enforce declared scopes, log agent interactions against the principal record, and expose a scope vocabulary so operators know what permissions to request.

Risk of inaction: Without x401 support, your product cannot distinguish a user acting directly from an agent acting on their behalf. When the agent takes a bad action, you have no clean audit trail, no scope enforcement record, and no obvious way to implement targeted revocation.

Learn to Build for the Agentic Web

The AI PM Masterclass covers agentic product design, identity, and authorization from a product perspective, taught live by a former Apple and Salesforce Sr. Director PM.

Four Product Design Decisions x401 Forces

Implementing x401 is not purely an engineering problem. It surfaces product decisions that teams typically defer until something goes wrong. Getting these right early saves a much harder retrofit later.

Define your scope vocabulary

Before you can validate incoming agent requests, you need to define what scopes mean in your product. What is the difference between 'read:invoices' and 'write:invoices'? Can an agent with 'purchase:order' also modify an order? Your scope vocabulary is a product decision about what granularity of authorization makes sense for your user base. Too coarse and you cannot enforce meaningful limits. Too granular and operators will not correctly configure their agents.

Choose your authorization UX

Users need to grant agent credentials before agents can act on their behalf. This authorization flow is a new product surface. Should it be in-product (similar to OAuth) or delegated to the agent operator? What happens when a user wants to revoke a credential mid-session? How do you communicate to the user what they authorized the agent to do? This UX determines whether users trust the agent ecosystem you are building.

Set your enforcement policy

When an agent presents a valid x401 credential but requests an action outside its declared scope, what happens? Reject and surface an error? Allow it anyway and log the violation? Alert the user? Your policy here determines whether x401 actually provides protection or becomes security theater. The most common mistake is implementing x401 validation but writing lenient enforcement that never actually blocks anything.

Design your audit data model

One of the most valuable things x401 gives you is a clean record of which actions were taken by agents versus humans, and on whose behalf. This data is useful for support, compliance, billing, and debugging. Design the data model before you implement, because retrofitting an audit schema onto an existing event log is painful. Minimum useful fields: principal id, agent operator id, declared scopes at time of action, action taken, timestamp, whether scope enforcement was triggered.

Risks and Open Questions

x401 was launched in October 2026 and the ecosystem around it is still forming. There are real risks in waiting but also real risks in betting too early on a specific implementation.

Protocol adoption risk

x401 only works if both sides implement it. If major platforms do not adopt it, the verification problem persists even for teams that implement correctly. Watch for adoption by OpenAI, Anthropic, and Google as the leading signal. Their agent platforms generating x401-compliant traffic is the demand signal that makes target-side implementation worthwhile.

Credential theft attack surface

Signed credentials are only as secure as the signing keys. An operator whose private key is compromised can have their credentials forged indefinitely. x401 includes a revocation list mechanism, but it requires operators to update that list quickly after compromise. This is the same key management problem that makes certificate revocation hard in TLS.

Scope inflation over time

Over-requesting scope is the standard pattern in OAuth and will be the same in x401. Agents will be configured with broad scopes to avoid having to handle scope errors. This erodes the security model over time. Design your scope enforcement to log over-scoped requests even when you allow them: this data becomes useful when you want to tighten enforcement later.

Regulatory alignment is unclear

How x401 credentials interact with GDPR data subject requests, the EU AI Act's accountability requirements, and emerging US state AI laws is not settled. If your product is in a regulated vertical, get your compliance team involved before you design the scope vocabulary and audit data model.

What to Do in the Next 90 Days

x401 is too new to require a full implementation commitment today. But it is not too new to start thinking about. The decisions you make about authorization, audit, and enforcement in the next product planning cycle will determine how much work a retrofit costs in 12 months.

Audit your current agent traffic exposure

How much of your inbound traffic is agent-generated today? If you do not have server-side instrumentation that distinguishes agents from humans (User-Agent parsing is a start, not a finish), add it. You cannot manage a risk you cannot measure.

Define your scope vocabulary on paper

Do not wait for x401 adoption to force this. Write down what the meaningful permission boundaries in your product are. This work is useful even if x401 never takes off: it directly informs your API design, your rate-limiting policies, and your security review process.

Decide which side to build first

If your product is sending agents to other products, focus on operator-side implementation: get your signing infrastructure in place and start issuing narrow-scoped credentials. If your product is a high-value target (financial data, purchasing, account management), focus on target-side validation. Most teams should pick one and ship it before trying to do both simultaneously.

Watch the three leading indicators

OpenAI adding x401 to Dots agent traffic, Anthropic adding it to computer use, or a major consumer platform requiring it for agent access. Any of these makes target-side implementation urgent. Until one happens, you have time to design well rather than rushing to implement.

x401 Agent Identity Protocol: What Product Managers Need to Know