Amex Built a Leash for AI Agents That Spend Your Money

By Lazar Milicevic · Published October 14, 2026 · 9 min read

Your agent has a card number in its config, a prompt that says "stay under $200," and nothing else standing between a looping bug and your bank balance. A prompt is a suggestion, not a control. On October 13, 2026, American Express published a framework that treats purchase authorization as signed data instead of instructions, and you can build the same pattern at your size in an afternoon.

What Amex Actually Published

Amex announced its Intent Intelligence framework on October 13, 2026. It is designed to capture and authenticate a customer's purchase intent before an AI agent completes a transaction. The framework ships through the Amex Agentic Commerce Experiences (ACE) Developer Kit, which launched April 14, 2026 with five services: Agent Registration, Account Enablement, Intent Intelligence, Payment Credentials, and Cart Context. According to Amex's agentic commerce page, the Account Enablement, Intent Intelligence, and Payment Credentials specifications have been available since April 14, 2026, while Agent Registration and Cart Context were still under development. Check that page again for current status.

The flow, per Amex's announcement:

1. A Create Intent API call captures the customer's instructions and constraints, such as the merchant and a maximum budget.
2. The customer authenticates and signs off on the intent the agent captured.
3. The system creates an Intent ID (a unique identifier) and a Proof of Intent Token representing the intent's high-level constraints.
4. At checkout, the agent uses a scoped digital payment credential instead of the customer's real card number.

Amex's VP of Agentic Partnerships and Strategy, Hannah Bozian, told TechCrunch that these transactions involve three parties: a consumer, a merchant, and an agent.

Notice what's missing from the announcement: no price, no adoption figures, no list of companies using it, and no date for Agent Purchase Protection (FourWeekMBA's read). Also, Amex's Agent Purchase Protection terms refer to Card Members and to U.S. credit cards issued by American Express National Bank and American Express Travel Related Services Company (see the agentic commerce page). I found nothing saying this covers business or corporate cards, so don't assume it does. Amex hopes this becomes a common industry approach; it is not an industry standard today.

The Intent Payload Is a Spec You Can Steal

The interesting part isn't the card network plumbing. It's the shape of the intent object. According to Amex's technical documentation, the payload includes:

• a max amount
• an intent expiry
• merchant data
• item-level conditions (for example, flight insurance only if the flight is bought)
• a maximum number of transactions, which maps to the maximum number of payment credentials that can be issued
• order context and purchase criteria

The Proof of Intent Token is a JSON Web Token. It expires on the date the user sets and confirms, and it can be single-use or multi-use, so it can generate credentials for one or several merchants.

That's a complete authorization record. Every field answers a question a dispute reviewer will ask: how much, who, when does it expire, what exactly, how many times. Here's the same shape as a table you can run today:

CREATE TABLE approved_intents (
  intent_id        TEXT PRIMARY KEY,
  vendor           TEXT NOT NULL,
  item_description TEXT NOT NULL,
  max_amount_usd   NUMERIC(10,2) NOT NULL,
  max_transactions INTEGER NOT NULL DEFAULT 1,
  used_transactions INTEGER NOT NULL DEFAULT 0,
  expires_at       TIMESTAMPTZ NOT NULL,
  approved_by      TEXT NOT NULL,
  approved_at      TIMESTAMPTZ NOT NULL,
  conditions       JSONB DEFAULT '{}'
);

CREATE TABLE purchase_attempts (
  id          BIGSERIAL PRIMARY KEY,
  intent_id   TEXT,            -- NULL when no matching intent existed
  vendor      TEXT NOT NULL,
  amount_usd  NUMERIC(10,2) NOT NULL,
  outcome     TEXT NOT NULL,   -- 'executed' | 'blocked' | 'escalated'
  reason      TEXT,
  attempted_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Two tables. The first is what you authorized. The second is everything the agent tried, including what got blocked.

Authorization Is Data, Not a Prompt

The core design rule: the agent proposes, a deterministic gate disposes. The model never decides whether it's allowed to spend. A plain function does, and that function reads from the approval table.

from datetime import datetime, timezone
from decimal import Decimal

def check_purchase(db, vendor: str, amount: Decimal, intent_id: str | None):
    """Return (allowed: bool, reason: str). No LLM involved."""
    now = datetime.now(timezone.utc)

    if intent_id is None:
        return False, "no_intent_id"

    intent = db.fetch_one(
        "SELECT * FROM approved_intents WHERE intent_id = %s", intent_id
    )
    if intent is None:
        return False, "unknown_intent"
    if intent.expires_at <= now:
        return False, "intent_expired"
    if intent.vendor != vendor:
        return False, "vendor_mismatch"
    if amount > intent.max_amount_usd:
        return False, "over_max_amount"
    if intent.used_transactions >= intent.max_transactions:
        return False, "transaction_cap_reached"

    return True, "ok"


def attempt_purchase(db, notify, vendor, amount, intent_id, execute_fn):
    allowed, reason = check_purchase(db, vendor, amount, intent_id)

    db.execute(
        "INSERT INTO purchase_attempts (intent_id, vendor, amount_usd, outcome, reason) "
        "VALUES (%s, %s, %s, %s, %s)",
        intent_id, vendor, amount,
        "executed" if allowed else "blocked", reason,
    )

    if not allowed:
        notify(f"Blocked: {vendor} ${amount} ({reason}). Approve or ignore.")
        return None

    db.execute(
        "UPDATE approved_intents SET used_transactions = used_transactions + 1 "
        "WHERE intent_id = %s", intent_id
    )
    return execute_fn()

Note the ordering: the log write happens before the purchase executes. If the process dies mid-purchase, you still have a record of the attempt. In a real system, wrap the counter increment and the log insert in one transaction so two concurrent agent calls can't both squeeze past the cap.

This is also your defense against prompt injection. If a malicious product listing convinces the agent to buy something else, vendor_mismatch or over_max_amount fires, and the injection gets a blocked row instead of a charge. The agent can be fooled; the gate can't be sweet-talked.

Give the Agent a Credential That Can't Exceed Its Job

Amex's framework scopes the payment credential to the authorized intent, so the agent never holds the real card number. You can approximate that today with whatever your payment provider offers, and the principle matters more than the product: the credential itself should cap the damage even if your code has a bug.

Practical options, from least to most work:

• A dedicated virtual or prepaid card with a hard limit equal to the most you'd tolerate losing in a bad day. Not your main business card.
• Per-vendor or per-merchant-category restrictions, if your card or bank supports them.
• One credential per approved intent, if your provider can issue single-use or limited-use numbers. This mirrors what Amex describes, where the maximum number of transactions maps to the maximum number of credentials issued.

Two layers, two failure modes. The approval gate catches logic errors and injections. The credential cap catches bugs in the gate itself. Neither alone is enough. For the broader picture of treating agents as accounts with scoped access, see Securing AI Agents as Identities: A Small-Team Guide.

Who Approves, and How

The weakest link in any authorization scheme is the human step. Amex's documentation says intent sign-off can happen with a passkey, or the issuer can delegate sign-off to a third party such as the agent or a wallet provider, with issuers possibly requiring extra data to support that delegation.

Read that second option as a warning. If the agent can sign off on its own intent, you've rebuilt the sloppy setup with extra steps. For your own system, the rule is simple: the approver must be a different identity than the proposer. In practice:

• The agent writes a pending intent row and sends you a Telegram or email message with the vendor, max amount, expiry, and item.
• You tap approve. That tap flips the row to approved and stamps approved_by and approved_at.
• The agent's database role has INSERT on pending intents and SELECT on approved ones. It cannot UPDATE the approval status.

That last line is the one people skip. If the agent's DB credentials can write the approval, your approval log is theater. Separate the permission, not just the process.

For recurring, low-risk spend you can pre-approve a multi-use intent, which matches the single-use versus multi-use token distinction in Amex's design. Set a short expiry and a transaction cap, and review it weekly rather than leaving it open-ended.

Why Logs Win Disputes, and What's Still Unproven

The reason card networks are moving here is the gray zone: with an agent, "I bought it" and "I didn't" are joined by a third answer, "I told it to, sort of." A signed intent record converts that into evidence. Google's AP2 protocol formalizes the same idea with Intent, Cart, and Payment Mandates, and its specification includes a dispute case where an agent autonomously buys something that violates the user's signed Intent Mandate, such as going over budget. The evidence there is the Intent Mandate compared against the cart transaction details (AP2 specification). Same logic, different protocol. Amex was among AP2's launch partners when Google Cloud announced it on September 16, 2025.

On June 10, 2026, Visa and OpenAI announced tokenized Visa credentials for agent-initiated checkout in ChatGPT and Codex, with spending limits enforced before any payment is authorized (summary here). That is a secondary source; verify specifics on visa.com before relying on them. The pattern across all three: scoped credential, user-defined constraints, check before the money moves.

Be clear-eyed about what's not here yet:

• Amex Agent Purchase Protection is a future commitment, not live coverage. Amex says it will protect eligible customers from charges caused by agent error when a registered, ACE-integrated agent sends the authenticated purchase intent. No date or full liability terms have been given, and the terms say claims may be unavailable where intent is subjective or non-verifiable.
• Agent Registration and Cart Context were still in development per Amex's page. Check current status.
• Approval doesn't make the cart honest. An authorized intent says "up to this amount at this merchant." It doesn't automatically prove the agent bought the right item inside that envelope. That's why item-level conditions in the payload matter, and why you should log the cart contents, not just the total.

Your own log is what you'd hand to a bank. Amex's announcement doesn't change that for you; it just confirms the direction. For the failure mode where every tool call is technically valid but the business rule is broken, see Correct Tool Calls, Broken Business Rules: Agent Guardrails.

A One-Afternoon Build Checklist

Here's exactly how I'd set this up for a small team, in order:

1. Create the dedicated payment method with a hard cap. Name it after the agent.
2. Create the two tables above. Give the agent's DB role insert-only on pending intents, read-only on approved, insert-only on attempts.
3. Write the gate function as plain code. No model call inside it.
4. Wire the approval message to wherever you actually read: Telegram, email, SMS. One tap to approve, with vendor, amount, and expiry shown.
5. Route every purchase through attempt_purchase. No other code path touches the credential.
6. Alert on blocked attempts, not just executed ones. A burst of vendor_mismatch rows is your earliest signal of an injection attempt or a misbehaving loop.
7. Test the failure cases on purpose: expired intent, over-amount, counter exhausted, unknown intent. Run each once and confirm the block row appears.

Ad spend, software subscriptions, and vendor reordering are the three places I'd start, because in each one the cost of a single wrong action exceeds the time the agent saves you that week.

Where bizflowai.io Fits

This is how I'd set up an agent system if the goal is something a small team can leave running and defend afterward, rather than the most autonomous one possible: put the spending limit in first and the clever parts after. That means a separate payment method with a hard cap, an approval table the agent can read but not write, approval pings to Telegram or email, and an attempt log covering both executed and blocked actions. You can find more of my work on automation at bizflowai.io.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week. Search for BizFlowAI on YouTube to find new tutorials.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.