Agent identity is not commercial authority

Why is agent identity not enough?

Identity answers a recognition question: which user, service, workload, device, or organization is making a request? Commercial authority answers a decision-rights question: may this actor take this action for this principal, with this counterparty, at this value, under these conditions, now?

The two questions are related, but they are not interchangeable.

An employee can be strongly authenticated and still lack permission to sign a supplier contract. A purchasing service can hold a valid workload credential and still exceed its budget. An agent can act for the correct company while using an expired mandate. A payment credential can prove that a payment was authorized without proving that the underlying commercial terms were validly agreed.

As software agents move from retrieval and recommendation into action, the distinction becomes a systems requirement. Authentication can tell a supplier that a request came from buyer-agent-17. It cannot, by itself, tell the supplier whether that agent may order 5,000 units, accept a price increase, disclose a forecast, or waive a service-level term.

The 2026 authorization work is becoming more agent-aware

Standards work is starting to represent the problem more precisely. In June 2026, the OpenID Foundation published two new working group drafts from AuthZEN: the Authorization Agent Requesting Party draft and the Context Optimization for Authorization draft.

The first models authorization prerequisites that can occur before a decision is made, including approval, consent, delegation, attestation, and risk. The second maps Model Context Protocol tool requests into AuthZEN's subject, action, resource, and context structure. These are working group drafts, not final standards. Their importance is architectural: agent authorization cannot be reduced to one static role or one bearer token.

The foundation's Authorization API 1.0, finalized in January 2026, defines a standard request and response between an enforcement point and a decision point. That separation is valuable for agents. The model may propose an action. A policy decision point can evaluate the action. An enforcement point can permit or refuse execution. The model does not need to become the final authority.

NIST has also made software-agent identity and authorization a current standards question through its AI Agent Standards Initiative and a February 2026 concept paper on identity and authority for software agents. The initiative is evidence that the problem is recognized. It does not mean a complete cross-company authority architecture has been standardized.

Authentication, authorization, and authority are different

Three terms are routinely compressed into “access.” They should be separated.

Authentication

Authentication establishes a claimed identity or credential holder. It can apply to a person, software workload, agent instance, organization, or device. The result may be strong and cryptographically verifiable.

Authorization

Authorization evaluates whether a subject may perform an action on a resource in a context. A policy engine might decide that a sourcing agent may call a supplier-search tool but may not execute an order.

Commercial authority

Commercial authority concerns actions that can create obligations, transfer rights, disclose protected information, allocate resources, or move value for a principal. It includes authorization, but adds principal-agent relationships, mandate scope, approval conditions, transaction context, and evidence suitable for another organization.

An internal authorization result can be enough to protect an internal API. It may not be enough for a counterparty. The counterparty needs a scoped basis for relying on an external act without gaining access to the principal's private policy system.

The Machine Commercial Authority Model

Plural Worlds models machine commercial authority through seven linked elements.

1. Identity: which actor performed or requested the action?
2. Mandate: which principal delegated power to that actor?
3. Scope: which actions, resources, categories, counterparties, and jurisdictions are covered?
4. Limits: which value, duration, volume, and risk constraints apply?
5. Context: which transaction, current state, evidence, and environmental conditions matter?
6. Approval: which additional person or system must consent to this exact action?
7. Evidence: what lets an authorized reviewer establish how the decision was reached?

Weak designs skip from identity to action. Stronger designs bind all seven elements to the decision.

Consider a procurement agent with permission to buy laboratory consumables. The identity is valid. The mandate covers the legal entity's Dutch operations. The scope excludes controlled substances. The limit is EUR 20,000 per transaction and EUR 100,000 per month. The context shows that the supplier is approved and the quote has not expired. A human must approve non-standard payment terms. The evidence records the policy version, decision, approval, and resulting order.

No single element is sufficient. Together they make the act interpretable.

Why roles and scopes stop working at the boundary

Role-based access control works well when a shared administrator defines roles. Cross-company commerce has no such shared administrator.

A supplier cannot safely interpret the buyer's internal role PROCUREMENT_POWER_USER. The name reveals little, and the meaning can change. A broad OAuth scope such as purchase:write may be useful for an API, but it does not express a price ceiling, approved supplier list, delivery region, or requirement for human approval.

The counterparty needs a claim or decision with narrower semantics. For example: this agent may accept proposal P-1842-v3 for the named buyer, up to EUR 48,500, before 17:00 UTC, provided the settlement term remains net 30.

That statement can be checked against the transaction. It does not require the supplier to understand the buyer's organization chart.

This is the principle of counterparty-legible authority: an organization should be able to communicate enough authority for another party to validate a specific commercial act while keeping internal policy and strategy private.

Approval must bind to the action

Human approval is often proposed as the safety answer for agents. It is useful only when the approval is specific.

An “approve” click in a chat interface can be ambiguous. The terms may change after the person reviews them. The agent may apply the approval to another transaction. A supplier may not be able to tell what was approved.

A robust approval binds at least:

• the approving identity;
• the exact proposed action or content hash;
• the transaction and counterparty;
• the time and validity period;
• the policy condition that required approval;
• any limits or qualifications attached by the approver.

The execution system should recheck these bindings immediately before acting. If the proposal changed, the approval is stale. If the mandate was revoked, the old approval should not revive it. If the supplier substituted a term, the system should treat the result as a new action.

This design keeps people in a meaningful control loop. It also makes progressive autonomy possible. Routine actions can pass automatically. Novel, high-value, or policy-sensitive actions can escalate with an exact review object rather than an unstructured summary.

Revocation is a race, not a checkbox

Delegated authority changes. Employees leave. Budgets close. Credentials leak. Suppliers become restricted. A principal may stop an agent during an incident.

Revocation therefore has temporal semantics. A verifier needs to know whether authority was valid when the action occurred, whether a revocation should have been visible, and whether the system failed closed when status could not be determined.

The practical design questions include:

• how quickly a revocation becomes effective;
• which systems receive it;
• whether cached authority decisions have a maximum life;
• what happens during an outage;
• whether already formed obligations remain valid;
• how emergency suspension differs from permanent revocation.

The unsafe default is to treat an unavailable authority service as permission. For commercial acts, unavailability should usually pause or escalate the action unless a narrowly defined continuity policy says otherwise.

Agent chains multiply the problem

Agents rarely act alone. A supervisor agent may ask a sourcing agent to find offers, which asks a browser tool to inspect a site, which calls a payment agent after approval.

Identity can trace the technical chain. Authority must control delegation across it.

A delegated agent should not gain more power than its delegator. Each hop should preserve the principal, narrow or retain scope, and make purpose visible. The final enforcement point should evaluate the action itself, not assume that an upstream agent checked it correctly.

This prevents a common failure: an agent with permission to research suppliers passes a task to a tool that has standing purchase credentials. The tool's technical capability exceeds the initiating agent's mandate. Without end-to-end authority context, a harmless research instruction can become an order.

Identity systems and agreement systems should compose

No one protocol should own the entire problem.

Identity systems can bind keys, workloads, organizations, and credentials. Authorization systems can evaluate policies. Agent communication protocols can carry requests. Commerce protocols can represent checkout or payment mandates. Agreement systems can bind authority decisions to proposals, acceptances, obligations, and evidence.

A202 is relevant at the last boundary. It is an open protocol developed by Plural Worlds for verifiable agreements in agent-led commerce. It represents delegated commercial authority and signed commercial actions, and it keeps agreement state separate from carrier messages. It does not replace OpenID, OAuth, AuthZEN, MCP, A2A, or payment systems.

The useful composition is:

• identity establishes the actor and issuer;
• an authorization service evaluates internal policy;
• a mandate or scoped proof communicates counterparty-legible authority;
• the commercial action refers to that authority and the current transaction state;
• the agreement record preserves what both sides accepted;
• external execution systems return receipts.

This keeps probabilistic reasoning separate from deterministic enforcement.

What enterprises should require now

An enterprise evaluating action-taking agents should ask for more than authentication and an audit log.

Require a clear principal for every commercial action. Require transaction-level scopes and value limits. Require approvals to bind to exact actions. Require short-lived or re-evaluated authority for sensitive operations. Require revocation behavior to be tested under outage conditions. Require agent chains to preserve the original purpose and limits. Require evidence that can be interpreted without replaying private model reasoning.

Most importantly, test refusal. An authority system is defined by what it prevents as much as what it permits.

Identity is essential infrastructure for the agent economy. It tells us who is at the door. Commercial authority determines whether that actor can make the organization answer for what happens next.

Related Plural Worlds research

The autonomous counterparty places authority inside a broader organizational boundary. Introducing A202 explains how scoped authority can bind to proposals, agreement state, and evidence.