C=US · Control Plane Notes← Identity vs. runtime overview

Cocktail-napkin summary · real event, not hypothetical

Cocktail-napkin diagram showing a sponsor, agent identity, narrow scope, independent allow or deny decision, and decision proof that records who sponsored and endorsed the agent. It emphasizes that endorsement is not permission and that checkout may pass while purchase-history access may fail.
The implemented control path: identity and accountable sponsorship travel with a narrow, relying-party-specific authorization decision.
See the full case study, with verified evidence ↓

Case study · real event, real fix, verified live

What actually happened, and how c=US's own mechanism would grant the scope

Meta launched its Muse AI agent September 8, 2026. Amazon blocked it from its retail site September 20, 2026. This isn't a hypothetical — it's a real, dated, multiply-reported dispute, modeled here using c=US's own identity and authorization mechanism, then actually run against a live local gateway to produce the evidence below.

Scope note. This models the dispute's mechanism using c=US's own demo infrastructure and a stand-in certificate; it is not a real integration with Meta, Amazon, or the FTC, and no named organization has participated in, sponsored, endorsed, approved, or adopted this work.

Directory assumption. For this illustrative model only, Meta and Amazon are treated as o=-level certified endorsers in the X.500 directory. That status is assumed by the fixture; it is not a claim that either organization currently holds, recognizes, or participates in such a directory role.

What actually happened

  1. Sep 8, 2026

    Meta launches Muse, a personal AI agent that can browse, fill forms, and make purchases on a user's behalf, partnered with Walmart, GameStop, Sephora, Expedia, OpenTable, and Shopify.

  2. Sep 20, 2026

    Amazon blocks Muse from Amazon.com. Users see a warning that access by an unauthorized AI agent violates Amazon's Conditions of Use.

  3. Amazon's stated reasons

    Muse did not identify itself as an agent in its HTTP requests, violating Amazon's own May 2025 Agent Terms; Meta never obtained Amazon's authorization for Muse to shop there; and Muse could access customer data (account pages, purchase history) Amazon considered undisclosed third-party access.

Mapped onto c=US's own mechanism

Meta's endorsement of Muse (its own sponsor/registration) is a real, structural part of c=US's identity model — but it only ever establishes who the agent is. Whether it's allowed to act is a separate decision, made independently by whichever relying party's resources it's trying to use. Amazon, as the relying party, never issued that grant. Three real Amazon requirements map directly onto c=US's own layers:

Amazon's stated reasonc=US layer it maps to
No agent-identification headerAmazon's own relying-party policy, layered on top of (not replacing) c=US's own certificate-based identity
No Amazon-granted authorizationcequsAuthorizationGrant — specifically, none existed naming Muse's DN and a scope Amazon controls
Undisclosed data accessScope granularity — c=US scopes are narrow and independent by design, so "checkout" and "read purchase history" are never bundled

Built and run, not just diagrammed

Two new scopes were added to this project's own scope vocabulary, kept deliberately separate: amazon.checkout.execute and amazon.account.read.purchase-history. The policy gateway (security/mtls/server.py) was generalized so each endpoint checks its own scope independently (previously it could only ever check one hard-coded scope — a real, separately-logged defect, SW-2026-09-19-01, fixed as part of this). The agent client now sends the exact header format Amazon's own terms require, User-Agent: Agent/<name>, derived from the agent's own c=US identifier.

Four scenarios were then actually run against a live local gateway, real certificate, real TLS handshake — not simulated by hand:

DENY

Before any grant: Muse's identity is recognized (sponsored by Meta, endorsed by nobody), but amazon.checkout.execute is requested with zero scopes granted. "reason": "requested scope is not granted" — matches the real initial rejection.

401

Missing Amazon's own header: the same request, without User-Agent: Agent/<name>, is rejected before the directory is even consulted — Amazon's rule enforced as its own layer, independent of c=US's identity check.

ALLOW

After a hypothetical Amazon review: a new grant is issued — cequsEndorsedBy: cn=Amazon Trust and Safety,..., scope amazon.checkout.execute only, a real time window. Checkout is now allowed.

DENY

Purchase history, same grant: requested separately — still denied. The remediation was narrow, not blanket, directly addressing Amazon's actual stated concern about undisclosed data access rather than papering over it.

Full request/response JSON for all four runs, the exact code changes, and the defect record are in SOFTWARE_DEFECTS.md (SW-2026-09-19-01) and security/mtls/ in this project's repository.

Sources