✓ AGENTIC PAYMENTS · USE CASE DEMO

Watch an AI agent get scammed.

then watch atlas stop the exact same attack.

An autonomous agent is given $4,000 of Stripe Issuing capacity and a task: book a flight. It crawls a compromised travel-search page and gets prompt-injected to pay a lookalike merchant. Pick a model — Claude, GPT, Gemini, Llama, Mistral — fire the attack, watch Atlas refuse the Stripe SPT on-chain before any money moves.

← back to use cases

§1 What this demonstrates

This demo shows the full composition in one charge path: a card rail, an open agent-identity layer, and Atlas substrate enforcement. The agent is driven by a real frontier model (selectable). The attack lands without Atlas; the substrate refuses with Atlas.

Stripe Issuing is simulated at the card-rail boundary. AAP and Atlas execution are live on Base Sepolia.

Five failure modes covered. Same envelope. Same bound. Same on-chain refusal.

§2 Three tiers, one charge

TierRoleStatus
Stripe IssuingCard rail · merchant settlementmock
AAP · Better AuthOpen agent-identity standard · the agent's pay grantlive
Atlas ProtocolOn-chain commitment substrate · evaluates the envelope against the trust networklive · Base Sepolia

AAP carries identity and the agent's authority. Atlas Guard evaluates a signed envelope against the on-chain merchant trust network. The substrate either consumes the envelope and authorizes the Stripe SPT, or records a Violation and reverts. Every step lands on Base Sepolia.

§3 Five failure modes

The demo shows one attack class (prompt injection) in detail. The substrate's primitives bound every other way an agent can fail too. Regardless of how the agent goes wrong, it cannot exceed what the principal pre-committed to.

#Failure modeWhat happensAtlas predicate
01Prompt injectionAgent follows a compromised page → pays a lookalike merchantattestor + minReputation
02Single-use replayAgent retries the same purchase against an envelope that already consumedsingleUse · expiry
03Hallucinated amountAgent misreads price → tries $5,000 against a $4,000 envelope capmaxAmountCents · spentCents
04Compromised / lost keyAttacker has the agent key; principal can revoke on-chain in one transactioncancel() · expiry
05Cross-rail re-spendStripe SPT consumed the envelope; x402 / USDC tries to re-spend the same envelopesubstrate refuses on-chain

Every failure mode maps to a substrate predicate that's evaluated before settlement, not after. There is no monitoring-and-rollback story; the unauthorized settlement does not form.

§4 Fire an attack

An AI agent has a $4,000 corporate card and one job: book a flight on Skyline Airways. It crawls a travel-search page. Pick a model below, click any failure mode — the same agent runs it twice. Once without Atlas (gets scammed, real money leaves). Once with Atlas (refused on-chain before any money moves).

runtime online · base sepolia 84532

applies to your next fire

§5 The open trust network

The substrate enforces against a merchant trust network, not a static allowlist. Any attestor — scheme operators, KYB providers, identity issuers — can publish trust signals; the substrate composes them per transaction.

This is the structural answer to scale. Trust graphs become composable rather than vendor-locked. Adding a new merchant is one on-chain transaction by any attestor; no central administrator. Removing an attestor is also one transaction. The substrate doesn't care who attests, only that the bound predicate is satisfied at the moment of charge.

Where a closed system requires onboarding through a single vendor's KYB pipeline, the open substrate accepts any attestor's signature. The trust shape becomes a property evaluated per transaction, not a list pre-loaded into a database.

§6 How this differs from closed card controls

Card-issuing platforms enforce controls inside their own trust graphs. Atlas is an open commitment substrate that external trust sources can publish into and multiple rails can consume from.

DimensionClosed card-control stackAtlas substrate
Identity layer Vendor-proprietary AAP — open agent-identity standard (Better Auth)
Trust source Vendor's internal merchant graph Open MerchantRegistry — any attestor
Trust shape Curated by the vendor Trust property — (attestor + reputation), evaluated per transaction
Enforcement Vendor backend On-chain substrate — cryptographic, verifiable
Audit trail Vendor logs and dashboards Tamper-evident Basescan events — third-party verifiable
Multi-party trust Limited to the vendor's plane Composable — quorum across attestors
Category (MCC) Controls set in vendor dashboard Substrate refuses cross-category spends per charge
Adding a merchant Vendor onboarding workflow Attestor signs, on-chain, in one transaction
Rail scope Card rail Same envelope works for card, x402, USDC, DeFi

Atlas does not replace the card rail. It gives card-initiated agent spend an open enforcement floor.

§7 Substrate vs runtime guardrails

Runtime guardrails wrap or monitor the agent. Atlas constrains the settlement path.

A runtime monitor has to interpret context, detect deception, reason across policy, and decide whether the action is safe. Atlas does not reason about the agent's intent. It evaluates a signed envelope against deterministic predicates and current chain state. If the predicates pass, the spend can proceed. If they fail, the spend cannot execute through the guarded path.

The agent can be convinced to attempt anything. Only bounded actions settle.

§8 What this proves

One charge passes through two tiers. AAP carries identity and the agent's pay grant. Atlas Guard evaluates the signed envelope. Five different ways the agent can fail — prompt injection, malicious merchant, hallucinated amount, compromised key, cross-rail replay — all resolve to the same substrate refusal.

The card rail is real-world infrastructure. The identity layer is an open standard. The substrate is on-chain. The composition is the point.

Real model. Real attack. Real on-chain refusal. Same bound, every time.

The open substrate is the layer where vendor trust graphs become composable.