American Express has introduced an Intent Intelligence Framework intended to stop AI agents from completing purchases that exceed, conflict with, or otherwise depart from a cardmember’s instructions. The framework records purchase constraints—including the permitted merchant, spending limit, and product preferences—then associates those conditions with an intent identifier and a tokenized payment credential that can be evaluated during a transaction. [1]
The announcement addresses a central problem in agentic commerce: finding products and initiating checkout is becoming technically straightforward, but reliably enforcing the limits of a user’s delegation is harder. A user may tell an agent to buy a laptop from a specified retailer for no more than a defined amount, but that instruction must remain enforceable if the price changes, the merchant changes, an accessory is added, or the agent selects a substitute. American Express is positioning intent as a transaction-level control rather than a one-time conversational instruction.
From natural-language request to payment constraint
AI agents introduce a new form of delegation. Conventional online checkout generally assumes that a person chooses an item, reviews the total, and explicitly authorizes payment. In an agent-led purchase, the user may instead provide a broad request and let software search, compare, negotiate, and transact on their behalf.
That model creates ambiguity at the point where language meets payment authorization. Instructions such as “buy the best available option under $500” can contain unstated questions: Does shipping count toward the cap? Are taxes included? Is a marketplace seller acceptable? Can the agent choose an unfamiliar brand? May it make a recurring purchase instead of a one-time order?
American Express’s framework seeks to make those limits machine-readable. Rather than treating a payment credential as an open-ended instruction to charge an account, it ties the credential to a recorded set of conditions. The reported controls include:
- Merchant restrictions, limiting where an agent may spend.
- Budget restrictions, defining a ceiling for an authorized purchase.
- Product preferences, allowing the user’s requirements to travel with the purchasing instruction.
- An intent identifier, providing a reference for the authorization context.
- A tokenized payment credential, which can be checked against the stated intent during the transaction flow.
The distinction matters. A simple spending limit can prevent an agent from buying an expensive item, but it cannot necessarily prevent the agent from buying the wrong item, purchasing from the wrong seller, or using a credential after the original task has changed. Binding transaction controls to an intent record aims to make payment authorization more specific than a generic card-on-file transaction.
Why payment enforcement is the agent-commerce bottleneck
Consumer-facing AI agents have rapidly improved at product search, recommendation, form completion, and navigation across merchant sites. Those capabilities do not automatically solve the trust problem. The purchase is the irreversible step: it moves money, creates delivery obligations, and can generate a dispute when an agent behaves unexpectedly.
For payment networks and issuers, this shifts the focus from whether an agent can act to whether its authority can be bounded and verified. An agent might be capable of completing a checkout sequence, but it should not be able to reinterpret a request without limits. The payment layer is one of the few points in the commerce stack where a proposed action can be evaluated before funds are committed.
American Express’s approach also creates a potential audit trail. If an intent identifier accompanies a transaction, participants may be able to compare the eventual charge with the delegated conditions: the authorized merchant, category of goods, and permitted total. That could be useful not only for cardmembers, but also for merchants deciding whether to accept agent-originated orders and for customer-service teams handling complaints.
The framework does not eliminate the difficult semantic question of how a system should interpret product preferences. A budget or merchant name is relatively precise. “Best,” “sustainable,” “business appropriate,” or “similar to the last one” is not. Effective controls will depend on how agent builders and commerce platforms translate those subjective instructions into explicit, inspectable rules before payment is attempted.
Tokenization changes the scope of delegated authority
Tokenized payment credentials are important because they can narrow the authority given to software. Instead of handing an autonomous system a reusable primary account number or broadly usable card credential, a token can be associated with a particular use case and checked against transaction conditions.
In the framework described by American Express, the tokenized credential is paired with the intent identifier. That architecture is designed to let the transaction be assessed against the user’s recorded parameters throughout the purchase process, rather than relying solely on the agent’s claim that it has permission. [1]
The practical value will depend on where and how those checks occur. Merchant systems need enough information to recognize an agent-backed transaction and process it correctly. Payment partners need a common way to transmit intent-related data. Agent developers need interfaces that can express constraints faithfully without reducing every shopping task to a narrow form. Cardmembers need a clear way to inspect, change, and withdraw authorization before an order is finalized.
Those implementation details matter because agent commerce often spans several organizations: an AI assistant, a shopping or travel platform, a merchant, a payment service provider, an acquirer, an issuer, and a network. A framework is most useful when the authorization context remains intact across those handoffs.
Adoption will determine whether the framework becomes infrastructure
The launch is significant as a statement of direction from a major card issuer and network, but its immediate value will be determined by ecosystem participation. A merchant that cannot receive or act on an intent restriction may see little difference from a conventional card authorization. An AI agent that does not structure requests around the framework’s controls cannot give users the corresponding safeguards.
Merchants have incentives to participate if intent data can reduce fraudulent or disputed orders, clarify whether an automated purchase was authorized, and support more reliable fulfillment. They may also be cautious. Extra data fields, new checkout logic, and unresolved questions about liability can create integration costs. Merchants will want to know whether the framework improves approval rates, reduces support burden, or adds friction at a time when checkout conversion remains a priority.
Agent builders face a related trade-off. Broad autonomy makes agents more useful, but tightly scoped credentials may be necessary for users to trust them with meaningful purchases. Products that let users set an amount, merchant list, delivery destination, and substitution policy could offer a safer path to routine delegated buying than agents operating with a permanently stored payment method.
Payment partners and commerce platforms will be pivotal because they can standardize how intent is represented across multiple merchants. If each network, agent provider, and retailer develops incompatible authorization schemas, users may face inconsistent controls and developers may face costly one-off integrations. If common patterns emerge, intent-aware authorization could become a normal feature of agent checkout.
Disputes, revocation, and the remaining policy questions
The framework also raises questions that extend beyond transaction approval. When an agent purchases an item that technically falls within a budget but violates the user’s expectations, the central dispute may be about interpretation rather than payment authentication. Card networks, issuers, merchants, and regulators will need to distinguish among unauthorized use, defective agent execution, merchant error, and a user’s ambiguous instruction.
That makes auditability especially important. A useful record would show what the user authorized, when the instruction was modified, which constraints were applied, and whether the transaction matched them. Without that evidence, disputes involving agents could become harder rather than easier: each participant could describe the same purchase as either an authorized delegated action or an unauthorized automated one.
Revocation is equally consequential. Users should be able to cancel an agent’s authority when a shopping task changes, a device is compromised, or an agent begins behaving unexpectedly. The announcement establishes the concept of intent-linked controls; the operational test will be whether those controls can be updated or withdrawn quickly enough to matter before an agent completes a transaction.
American Express’s framework is therefore best understood as an early attempt to build a permission layer for AI commerce. It does not resolve every issue around agent identity, product semantics, consumer protection, or liability. It does, however, focus on the point where practical safeguards are most needed: the moment software tries to turn a delegated instruction into a charge.
Editor’s Take
I think this is the right layer to attack. Giving an agent a card credential and hoping it follows a chat instruction is not a durable security model. A spend cap, a merchant boundary, and a transaction-linked intent record are far more useful because they constrain the action where money actually moves.
The feature to watch is not the framework’s name but its implementation at checkout. I would want to see a user set a precise mandate, inspect it in plain language, revoke it instantly, and later see exactly why a transaction was approved or rejected. If American Express, agent builders, and merchants can make that work across real purchase flows, agentic commerce becomes materially more trustworthy. If the controls exist only in a narrow demo path, the industry will still be relying on overly broad delegated payment authority.
