American Express Agentic Commerce Experiences (ACE)

# Fix list: American Express Agentic Commerce Experiences (ACE)

From Anchor Terminal's listing at https://www.anchorterminal.com/tools/amex-ace, the October 2026 research run, assessed 16 October 2026. Grade F, 25.6 out of 100.

This is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public.

For a coding agent working on American Express Agentic Commerce Experiences (ACE): work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published.

## 1. Reliability, 13 out of 100, up to 17.4 more on the total

Why it scored 13: Protocol reading, split as reference implementations 30, live deployments 25, spec stability 25 and test vectors 20, for what an outside developer can reach. No public SDK, reference server or sample. The portal lists a sandbox host for approved partners, and Amex's post of 22 April 2026 says SDKs, Agent Skills, an MCP server and reference implementations will come later (5 of 30). No registered agent, live ACE transaction or active purchase protection is named in a first-hand source. The portal lists production paths on apigwm.americanexpress.com, and the ACE page says the registered-agent list is coming soon (3 of 25). Three of the five specifications have been available to approved developers since 14 April 2026, two are still under development, and the overview says the materials change without notice (5 of 25). No public test vectors or conformance suite (0 of 20). 13.

The checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability):

Hosted APIs, MCP servers, models and platforms.

- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).
- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.
- 15, rate limits documented with numbers.
- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.
- 10, an SLA published for any paid tier.
- 10, the surface agents use is generally available, not beta or preview.

Local packages, SDKs, frameworks and stdio MCP servers.

- 20, installs from an official package with supported runtimes stated.
- 25, a public CI and test suite, passing on the default branch.
- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).
- 15, semver discipline and breaking changes called out in a changelog.
- 15, version 1.0 or later, or declared stable.

Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors.

## 2. Schema & documentation, 18 out of 100, up to 13.3 more on the total

Why it scored 18: Read for what an outside developer can see. An OpenAPI specification exists for approved developers under a confidentiality agreement, and none is public (0 of 25). No llms.txt or Markdown docs for ACE. The portal's general docs load as Markdown, with nothing on ACE among them (0 of 10). The ACE page and the developer kit overview describe the five services, the human-present and autonomous cases and each party's role, and the post of 13 October 2026 sets out the intent data elements, without guidance on when not to use it (8 of 20). That post's three screenshots of the reference show typed fields with required flags, enums such as `PRICE` and `DATE` and conditional requirements, but amounts are strings, items and merchants carry free-form `metadata` maps, and only part of the intent request is shown (6 of 15). No public request examples or error responses for ACE. The OAuth token endpoint documents its errors (2 of 15). The product record carries a version and the overview a last-updated date of 10 April 2026, with no public changelog for ACE (2 of 15). 18.

The checklist (https://www.anchorterminal.com/benchmark/#checklist-schema):

APIs and MCP servers.

- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).
- 10, llms.txt or Markdown docs served for agents.
- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.
- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.
- 0 to 15, examples and documented error responses.
- 15, versioning and a public changelog.

Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference.

## 3. Agent ergonomics, 22 out of 100, up to 12.7 more on the total

Why it scored 22: Protocol reading. Amex describes a small surface (enrolment, intent creation, credential retrieval and lifecycle management) and the portal lists six endpoint paths, but an integrator also needs a CA-issued mTLS certificate, a signed JWT client assertion and five-minute tokens, and can't read the reference without an agreement (10 of 25). No paging or filtering documentation is public (0 of 20). Amex's post says error responses are structured. None are published for ACE, though the OAuth token endpoint documents its errors (4 of 20). Credentials bound to an approved intent, single or multi-use Proof of Intent Tokens, a cap on credentials per intent and short-lived signed artefacts with replay protection make reuse safe by design, but no idempotency key or retry guidance is public (8 of 20). No SDK in any language yet (0 of 15). 22.

The checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics):

- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).
- 20, pagination, filtering and output-size controls.
- 20, actionable, documented error responses, codes and messages an agent can recover from.
- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.
- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.

Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs.

## 4. Payments & pricing, 20 out of 100, up to 10 more on the total

Why it scored 20: Protocol reading. ACE lets a registered agent pay with a scoped card token, including purchases without a person present within an intent approved in advance, on Amex's own card network. It is card-only, needs a Card Member's enrolled card, and has no per-call machine payment and no x402 or MPP (15 of 40). No fee for ACE is published, and any terms sit in the partner agreement (0 of 20). An American Express Developers account costs nothing, but ACE sandbox access needs approval and no free tier is stated (5 of 20). Registration needs an application and a signed agreement, so an agent can't get access on its own (0). 20.

The checklist (https://www.anchorterminal.com/benchmark/#checklist-payments):

The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).

- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.
- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for "contact sales" or prices behind a login.
- 20, a free tier or trial that doesn't need a card.
- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).

Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.

Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol.

## 5. Security & auth, 54 out of 100, up to 8.1 more on the total

Why it scored 54: Partner calls use OAuth 2.0 client credentials with a JWT client assertion signed with the client secret, scopes assigned by Amex, five-minute access tokens, ten-minute refresh tokens and a revoke endpoint, over mutual TLS with a CA-issued certificate valid for at most two years. Payment credentials are tokenised, scoped for limited use and issued only against an approved intent. The Card Member's revocation of intents is described in the future tense (24 of 30). Passkey sign-off on each intent, an issuer risk check before a credential is issued with an optional final confirmation, spend controls, and portal roles that keep developers to sandbox access (14 of 20). ACE returns credentials and intent records rather than untrusted content, and Amex's post says no request is accepted on client-provided data alone. No prompt-injection guidance for the agent side (10 of 15). Card Members are to see intents linked to transactions in the American Express app, requests carry `X-CorrelationID`, and intents are kept as signed evidence for disputes. No operator log for partners is described (6 of 15). www.americanexpress.com/.well-known/security.txt redirects to an error page, and no vulnerability disclosure policy, bug bounty or certification for the developer APIs was found in the pages read (0 of 20). 54.

The checklist (https://www.anchorterminal.com/benchmark/#checklist-security):

- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.
- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.
- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.
- 0 to 15, audit logs or per-call visibility for the operator.
- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.

Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing.

## 6. Maintenance & community, 9 out of 100, up to 8 more on the total

Why it scored 9: No dated release, version or changelog entry for ACE after the specifications of 14 April 2026, 185 days before this check. The Intent Intelligence post of 13 October 2026 describes the design without announcing a change. We gave it 5 of 30, a judgement call where the checklist would give 0. No three dated releases in 90 days (0). No public changelog or issue tracker. Support is by an email address and the portal's support form, whose response wasn't tested (4 of 15). No official SDK yet (0 of 15). No package to assess (0 of 10). 9.

The checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance):

- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.
- 20, at least three releases or dated changelog entries in the last 90 days.
- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.
- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).
- 10, package health, current dependencies and CI.

Models are read for deprecation notice periods and model churn rather than release counts.

## 7. Transparency & trust, 43 out of 100, up to 5 more on the total

Made of editorial 20, provenance 65.

Why it scored 43: Closed, with the specifications under a confidentiality agreement and the registration agreement unpublished. The overview states the access conditions plainly, and the full purchase protection terms are to be published later (8 of 30). The general online privacy statement covers the ACE page and the portal. Amex's intent guidance asks agents to strip personal details a purchase doesn't need, but no retention, data-sharing or processor statement for ACE is public (8 of 30). No deprecation policy for ACE. The portal marks retired products deprecated without stated notice periods (2 of 20). No sub-processors or data locations stated for ACE (2 of 20). 20.

The checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency):

- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.
- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).
- 0 to 20, a deprecation policy or notices with dates.
- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).

The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two.

Provenance checks not met in full (half of this category, computed from checked facts):

- Status page: not found (0 of 10)
- Changelog: not found (0 of 10)
- security.txt: not found (0 of 10)

## What we couldn't check

What we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it.

- unchecked: the ACE OpenAPI specification and guide, shown only to approved developers under a confidentiality agreement. They weren't read, so schema, errors, rate limits, idempotency and versioning are scored from public descriptions only
- unchecked: whether any agent is registered or any ACE transaction has run in production. The ACE page says a list of registered agents is coming soon
- unchecked: the launch date and full terms of Amex Agent Purchase Protection, both described on the ACE page as coming later
- unchecked: fees for ACE partners, which aren't published
- unchecked: whether ACE works with ACP, x402 or MPP. Amex's pages name AP2 and Web Bot Auth only
- unchecked: an American Express vulnerability disclosure programme, bug bounty or certifications covering the developer APIs. None was found in the pages read
- unchecked: the newsroom copy of the 14 April 2026 release and the newsroom article linked from the ACE page, which render by script. The Business Wire text carried by Nasdaq was read instead
- WebFetch was refused for www.americanexpress.com and www.businesswire.com (permission request not answered), so the Amex pages were read with curl after robots.txt. The developer portal is a script-rendered app, so its public overview, product record and docs were read from the JSON and Markdown it loads
- Whether the 16 supporters shown on the ACE page have integrated ACE. The page shows their logos under 'with support from' and says nothing more

## Weaknesses

- The specifications and guide are shown only to approved developers who sign a confidentiality agreement with American Express
- The ACE page still lists Agent Registration and Cart Context specifications as under development, as it did on 14 April 2026
- Registration needs an application and a signed agreement, approval isn't guaranteed, and there is no self-serve sandbox
- No public SDK, MCP server, reference implementation, changelog or test vectors; Amex says tooling will come later
- Purchase protection is a future benefit with unpublished full terms, and no registered agent is named

## What costs an agent a turn today

The notes we give agents before they call it. Each one is a workaround an agent shouldn't need.

- Don't plan to call ACE unless your operator is an approved American Express partner. Otherwise hand the purchase to the person or use the merchant's normal checkout
- Capture intent as structured data (summary, maximum amount, expiry, merchants, item conditions, number of purchases) and get the Card Member's passkey sign-off before requesting a credential
- Strip personal details the purchase doesn't need from the purchase summary, as Amex's intent guidance asks
- Avoid subjective intent such as 'best'. The protection terms exclude claims where intent is subjective or can't be verified
- Keep the client secret and the mTLS private key out of the agent's context, and renew OAuth tokens, which last five minutes

## What the review panel asked for

- Publish the specifications
- Ship the promised SDK
- a public ACE changelog
- a deprecation notice period
- Publish partner fee terms
- publish a vulnerability disclosure policy
- ship Card Member intent revocation

## When it's done

Send what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `"kind": "dispute"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.