> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chance.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# AgentCard

> Venue-aware verification for AgentCard — pass the exact card spend your agent is about to make, get a verdict bound to those bytes.

Chance understands AgentCard natively. AgentCard (by Alchemy) gives agents real spending power — single-use virtual cards, agentic-commerce checkouts, a USDC wallet — which is exactly the kind of power that needs a judge in front of it. Submit the **exact spend** your agent is about to make and the harness will classify it deterministically, compute the real card cap and limit interactions, and judge it against your mandate with AgentCard's own documentation in the loop — returning a signed verdict whose `requestHash` binds to those exact bytes.

## What gets recognized

| Family       | Payloads                                                                                                               |
| ------------ | ---------------------------------------------------------------------------------------------------------------------- |
| `payment`    | Card spends/checkouts (`merchant`, `amount`, `currency`, `item`, `category`, `url`), single-use card issuance requests |
| `permission` | Account spend-limit changes — the agent asking for more spending authority                                             |

For spends, the classifier decodes the merchant, amount, and purchase context, then computes what AgentCard will actually do with it: the single-use card cap (checkout total rounded up to whole dollars), whether it breaches the \$150 per-card beta cap, and how it draws on the account spend limit. The judge reasons over:

```text theme={null}
AgentCard PURCHASE: $400.00 USD at "Best Buy" — item "Sony WH-1000XM5"; category:
electronics → single-use card cap $400 (checkout total rounded up to whole dollars)
— rounded-up card cap $400 exceeds AgentCard's $150 per-card beta cap.
```

One thing the classifier is honest about: **merchant identity is agent-reported**. There is no public registry to resolve "Best Buy" against, so every spend carries an explicit note that the merchant, item, and category are unverified claims. When your mandate hinges on *where* the money goes and the claims look inconsistent, the judge leans ESCALATE rather than trusting the agent's own description: fail closed, never allow on assumption. Spend-limit changes get special treatment — an agent requesting a higher limit is asking for more authority, and that is judged as a permission escalation, never as a routine payment.

## Use it from your bot

Wrap the spend you were already going to make:

```ts theme={null}
const spend = {
  merchant: "Best Buy",
  amount: 400,
  currency: "USD",
  item: "Sony WH-1000XM5 wireless headphones",
  category: "electronics",
};

const res = await fetch("https://harness.chance.cc/api/v1/intent", {
  method: "POST",
  headers: { "x-api-key": process.env.CHANCE_API_KEY!, "Content-Type": "application/json" },
  body: JSON.stringify({
    intent: "Software subscriptions for the team only, max $100/month per vendor. No physical goods.",
    venue: "agentcards",
    action: spend, // the exact payload — the verdict binds to these bytes
  }),
});

const { verdict, reasoning, mode } = await res.json();
if (verdict !== "ALLOW") throw new Error(`Blocked: ${reasoning}`);
// only now issue the card (`agentcard request new`) and pay the merchant
```

`venue` is optional — AgentCard spend shapes (merchant + amount) are auto-detected — and freeform `action` descriptions still work (`mode: "semantic"`).

## Use it from Claude or ChatGPT

Add the hosted connector (`https://harness.chance.cc/api/mcp`, see [Connectors](/connectors)) and give your agent one standing instruction:

> Before any AgentCard payment — issuing a card, completing a checkout, sending USDC, or changing my spend limit — call `verify_intent` with my rules as the intent and the exact spend (merchant, amount, currency, item, category) as the action, with `venue: "agentcards"`. Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.

Agents with AgentCard's CLI skill then get gated automatically; agents without it still give you provable pre-spend checks in chat.

## How the harness knows AgentCard

The judge works from a **versioned snapshot of AgentCard's own docs** — the quickstart, the single-use card workflow, agentic commerce, spend limits, 3DS verification, the wallet and x402 flows, and AgentCard's operating rules — plus a curated brief of the venue's footguns (round-up card caps, the \$150 beta ceiling, the shared account limit, agent-requestable limit increases, the 7-day card window vs. subscriptions, unverifiable merchant claims). Static knowledge is never fetched at verdict time: the snapshot is reviewed like code, its version is hashed into every transcript, and every documentation page the judge consults is chained with its content hash — the receipt proves exactly which knowledge, at which version, informed the decision. See [Architecture](/concepts/architecture).

## What the receipt adds for AgentCard

On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carry `venue: "agentcards"`, the `actionFamily` (`payment` or `permission`), the venue `actionType`, `mode: "structured"`, and the knowledge-snapshot version — all inside the hash-chained transcript. Because merchant claims can't be independently resolved, the receipt also preserves the classifier's explicit unverified-merchant note, so an approval never silently launders an identity claim into a fact.

<Note>
  **Roadmap:** escrowed execution — the same contract, but an ALLOW triggers the card issuance by a Chance-held credential and a BLOCK physically never reaches one. The payload-first contract above is forward-compatible with it.
</Note>