Agentic Commerce Protocol is a framework for letting AI agents complete commerce actions such as product discovery, ordering, and payment on behalf of a user or business. Technically, it defines how an agent authenticates, exchanges intent, and receives limited authorization so transactions remain auditable, policy bound, and identity aware.
What Agentic Commerce Protocol Adds to Commerce Automation
agentic commerce Protocol is more than a checkout integration. It defines a transaction pattern where an AI agent can act with constrained authority, so commerce actions remain attributable, policy bound, and understandable to both the merchant and the principal behind the action.
That matters because commerce is not just data exchange, it is an exchange of intent, permissions, payment authority, and liability. ACP sits at the point where an agent’s autonomy has to be bounded tightly enough that a transaction can still be trusted, reviewed, and disputed if needed.
Identity, Intent, and Limited Authorization
ACP’s core design question is how an agent proves it is acting for a valid principal without turning the agent into a blank cheque. The protocol therefore centers on authentication of the acting entity, the transmission of user or business intent, and scoped authorisation that is narrow enough for the requested commerce step.
This is why ACP is best understood as a trust-boundary protocol rather than a generic API format. It has to distinguish the human buyer, the business account, and the agent that is executing the task, while preserving enough context to explain why the action was allowed.
For a deeper identity view of this pattern, Agentic Commerce Identity Guide explains how mandates, tokenised credentials, and agent identity fit together in commerce flows.
Why ACP Needs Policy Boundaries and Auditability
Commerce actions are high consequence because they can create financial commitments, customer impact, and contractual obligations. ACP therefore has to support policy decisions that are per action, traceable, and limited in scope, rather than allowing an agent to reuse broad standing authority across many purchases.
Auditability is equally important. A merchant, platform, or risk team may need to reconstruct what the agent was allowed to do, what it actually did, and whether the resulting order or payment matched the principal’s intent. Without that traceability, the protocol would be hard to govern in regulated or high-value environments.
That governance layer is closely related to AI Agent Authorisation Guide, which focuses on task-scoped access, per-action policy decisions, and delegated authority.
Where ACP Fits in the Commerce Ecosystem
ACP belongs in the broader ecosystem of agentic commerce and payment standards, where discovery, ordering, confirmation, settlement, and receipts may all involve different systems and different trust assumptions. Its role is to define the handoff between intent and execution so an agent can participate without collapsing merchant controls or payment assurance.
That makes interoperability a major practical concern. A useful commerce protocol has to coexist with identity systems, payment rails, merchant policies, and transaction logging, while still being specific enough that each participant can validate what the agent is asking to do.
As the standard landscape develops, Agent Identity Standards Tracker is a useful reference for adjacent work across OAuth, FIDO, OpenID and other identity-related pieces that may underpin ACP deployments.
What Can Go Wrong in Agentic Commerce
ACP reduces some of the ambiguity of agent-led transactions, but it also introduces new failure modes. If the agent is over-authorised, a compromised prompt, tool, or session can turn a single purchase into broader unauthorized spending or account abuse. If intent is captured poorly, the system may record an action that is technically permitted but materially inconsistent with what the user meant.
Failure mechanism: The control boundary fails when the agent’s authority is broader than the user expected, or when downstream systems cannot verify that the transaction still matches the original intent and policy constraints.
Impact: The result can be fraudulent orders, unauthorized payment actions, weak non-repudiation, and disputes that are difficult to investigate because the transaction path lacks a clean identity and approval trail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | ACP depends on proving the agent or principal before it can transact. |
| NHI-05 — Overprivileged NHI | ACP’s limited authorization model directly addresses excessive agent privilege. | |
| NHI-07 — Long-Lived Secrets | Commerce agents often rely on credentials and tokens that should not persist beyond need. | |
| Recommendation — Use phishing-resistant authentication and bound tokens before allowing commerce actions. Constrain agent authority to the minimum scope needed for each commerce action. Prefer short-lived, scoped credentials and rotate any long-lived commerce secrets promptly. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | ACP governs delegated authority and prevents agents from exceeding approved scope. |
| ASI09 — Human-Agent Trust Exploitation | ACP is designed to preserve the user’s intent and prevent trust abuse in commerce. | |
| Recommendation — Enforce per-action authorization and reject agent requests that exceed delegated privilege. Require explicit confirmation for high-impact commerce actions that could misstate user intent. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | ACP requires controlled lifecycle management for agent and principal access paths. |
| Recommendation — Provision and revoke agent commerce access through governed account lifecycle processes. | ||
| NIST Zero Trust (SP 800-207) | 3.2 — Policy Engine and Policy Administrator | ACP’s per-action authorization maps to policy-driven decisions at request time. |
| 3.4 — Continuous Diagnostics and Mitigation | ACP benefits from ongoing verification of agent behaviour and access posture. | |
| Recommendation — Evaluate every commerce request through a policy engine before granting execution rights. Continuously reassess agent trust, posture and entitlement as transactions progress. | ||
| OWASP ASVS | V8 — Authorization | ACP requires strong action-level authorization for commerce operations. |
| V10 — OAuth and OIDC | ACP-style delegation commonly depends on federated identity and token exchange. | |
| Recommendation — Verify that each commerce action is explicitly authorized for the authenticated principal. Use standards-based federation and constrained token handling for delegated commerce access. | ||