Attestation-Before-Access: A Pattern for Safe Agent Spending

When you give an AI agent a credit card, you're trusting it to spend wisely. But trust alone doesn't scale. As agents become more autonomous - purchasing cloud credits, API access, SaaS subscriptions - the industry needs patterns that make agent spending verifiable by default.

A standard is emerging: attestation-before-access. The idea is simple. Before an agent receives payment credentials, it must declare exactly what it intends to buy. That declaration gets logged, and the actual transaction is later matched against it. Mismatches get flagged.

This pattern separates two distinct operations that traditional payment flows conflate: authorization (can this agent spend?) and execution (here are the card details). By splitting them apart, you gain an audit trail that exists before money moves.

How the Pattern Works

The attestation-before-access flow has seven steps. Each one adds a checkpoint that traditional token delegation lacks.

1. Agent Requests Spend

Your agent determines it needs to make a purchase. Maybe it's provisioning infrastructure, subscribing to a data API, or renewing a software license. The agent knows what it needs and initiates the payment flow.

2. Agent Submits Intent

Before receiving any credentials, the agent submits a structured intent object. This captures the merchant, expected amount, purpose, and any other relevant context. The intent is timestamped and assigned a unique identifier.

Here's what that looks like in practice:

{
  "intent_id": "int_abc123",
  "agent_id": "agent_xyz",
  "declared_merchant": "aws.amazon.com",
  "declared_amount": 50.00,
  "declared_purpose": "monthly compute credits",
  "timestamp": "2026-01-15T10:30:00Z"
}

This object becomes the source of truth for what the agent claimed it would do. Notice that it includes the specific merchant domain, not just a category. The more precise the declaration, the more useful the downstream matching.

3. System Logs Attestation

The payment infrastructure persists this intent before any credentials are released. This creates an immutable record that exists independently of the agent's memory or logs. Even if the agent's context window is cleared or its logs are lost, the attestation remains.

Some implementations, like Nekuda's mandate model, go further. They cryptographically sign the intent using W3C Verifiable Credentials, making the attestation tamper-evident. The signature proves the agent declared this specific intent at this specific time.

4. Credentials Released

Only after the intent is logged does the system release payment credentials. These credentials might be a virtual card number locked to the declared merchant, a single-use token, or a short-lived access window to existing card details.

The key constraint: credentials are bound to the prior intent. The card might only authorize at the declared merchant. The spending limit might match the declared amount. The credentials might expire within minutes if unused.

5. Transaction Occurs

The agent executes the purchase using the released credentials. This happens at the merchant's checkout, through an API, or via browser automation. The mechanics vary, but the payment hits the card network like any other transaction.

6. System Matches Transaction Against Intent

When the transaction settles, the payment infrastructure compares what actually happened against what the agent declared. Did the merchant match? Was the amount within tolerance? Did the transaction occur within the expected timeframe?

This matching happens automatically. You don't need humans reviewing every agent purchase. The system knows what to expect because the agent told it in advance.

7. Mismatch Detection and Flagging

If the transaction doesn't match the declared intent, the system flags it. Maybe the merchant name differs slightly (AMAZON WEB SERVICES vs. aws.amazon.com). Maybe the amount exceeded the declaration by 20%. Maybe no transaction occurred at all despite credentials being released.

These flags feed into your alerting, dashboards, and policy engine. Frequent mismatches from a specific agent might trigger review. Certain mismatch types might freeze the card automatically.

Attestation Works Across Payment Primitives

One important clarification: attestation-before-access is a pattern, not a specific payment technology. It can be implemented on top of network tokens, dedicated virtual cards, or other payment rails. The pattern's value comes from the pre-declaration and matching - not from the underlying credential type.

Network tokens with mandates are a valid architecture. Platforms like Nekuda use Visa's network token infrastructure and add a mandate layer on top. The mandate captures intent, the token enables payment, and the matching verifies behavior. This works.

Dedicated virtual cards with attestation are also valid. This approach adds another layer: funding isolation. Each card has its own balance, so even if attestation fails to catch something, the blast radius is contained to that card's funds.

The question isn't "tokens vs. cards" - it's about how many layers of protection you need. Attestation alone catches behavioral anomalies. Funding isolation contains financial damage. Combined, they provide defense in depth.

For high-trust, well-constrained use cases, attestation on network tokens may be sufficient. For broader agent autonomy or higher spending limits, combining attestation with isolated funding adds meaningful protection. The right choice depends on your risk tolerance and how much you trust your agents.

Industry Adoption

This pattern is emerging across the agentic payments infrastructure layer, with implementations varying in their underlying architecture.

Nekuda calls their version "Mandates." As a Visa Intelligent Commerce launch partner, they've built an attestation layer on top of Visa's network token infrastructure. Before their payment executor reveals card details, the agent must submit a cryptographically signed statement of intent. The mandate captures what the agent is allowed to buy, under which conditions, and with what limits. This demonstrates that attestation-before-access can work effectively with network tokens as the underlying primitive.

PayOS implements similar concepts through their agent token flow. Their system validates agent requests against user-defined policies before releasing credentials. The token itself is bound to specific transaction parameters, and the Mastercard infrastructure they're built on enforces these constraints at the network level.

Signets takes a different architectural approach, combining attestation with funding isolation. Each agent gets dedicated virtual cards with separate balances, and the MCP server enforces intent declaration before revealing credentials. This defense-in-depth model means that even if an attestation mismatch slips through, the agent can only access funds allocated to that specific card.

The Cloud Security Alliance has documented attestation patterns in their guidance on the Agent Payments Protocol (AP2). They specifically call out mandates as "tamper-evident, cryptographically-signed digital contracts that serve as verifiable proof of user intent." Notably, their guidance is agnostic to the underlying payment rail - the pattern works regardless of whether credentials are network tokens or dedicated card numbers.

Implementation Considerations

If you're building agent payment flows, here's what to consider when adopting this pattern.

Intent granularity matters. Too vague ("buying cloud stuff") and the matching is useless. Too specific ("exactly $47.23 to AWS for r5.xlarge in us-east-1") and legitimate transactions fail matching due to price fluctuations or merchant naming variations. Find the middle ground.

Tolerance windows are necessary. Merchants often charge slightly different amounts than quoted. Currency conversion adds variance. Build in percentage tolerances for amount matching - typically 5-15% depending on category.

Merchant name normalization is tricky. The agent might declare "aws.amazon.com" but the transaction settles as "AMAZON WEB SERVICES AWS.AMAZON.COM". Your matching logic needs a merchant identity layer that handles aliases.

Failed matches aren't always bad. Sometimes legitimate transactions fail matching due to edge cases. Your flagging system should route to review, not automatic rejection. Over time, you'll tune the matching logic based on false positive patterns.

Credential lifetime should be short. The window between intent declaration and credential expiration should be minimal - minutes to hours, not days. This limits the blast radius if an agent's declared intent no longer reflects its actual behavior.

Why This Matters

Attestation-before-access isn't just about catching bad agents. It's about building systems where good behavior is the path of least resistance.

When agents must declare intent before spending, they're incentivized to be precise about what they need. When transactions are automatically matched against declarations, anomalies surface without human review. When mismatches are logged and flagged, you build institutional memory of how your agents actually behave.

This pattern turns agent spending from a black box into an auditable process. You don't just know what your agents bought - you know what they said they'd buy, and whether those match.

As agents take on more financial autonomy, patterns like this become the foundation for trust. Not trust in the sense of hoping agents behave, but trust in the sense of verifying they do.