Bottom line: Most agent frameworks let the agent enforce its own spending limits — the equivalent of asking an employee to self-report overspending on a corporate card. Ovra moves enforcement to the infrastructure layer: a six-state machine where policy is evaluated before any credential exists, card data is encrypted with AES-256-GCM and never leaves the server, and every state transition is logged into an immutable audit trail. This is the same pre-authorization pattern AP2 standardized at the network level — running today in private beta on a sandbox card issuer, with the same interface that ships to real Visa rails when our regulated EMI partnership lands.
Why agent-side policy enforcement fails
Most agent frameworks punt on this. The agent gets credentials, makes calls, and if something goes wrong, you find out on your bank statement. Policy enforcement, if it exists at all, lives inside the agent's own code — which means the agent is trusted to enforce its own constraints.
That's like giving an employee the company credit card and asking them to self-report if they overspend. At Ovra, policy enforcement happens at the infrastructure level. The agent can't bypass it because it never touches the actual payment credential.
How does Ovra enforce spending limits?
Every payment on Ovra moves through a strict six-state sequence. No state can be skipped.
Intent → Policy Check → Grant → Issue → Redeem → Settle
Intent. The agent declares what it wants to buy: merchant, amount, currency, purpose. This is a structured request, not a freeform charge. The intent includes the agent's ID, the wallet it's drawing from, and optional metadata.
Policy Check. The intent hits the policy engine before anything else happens. The engine evaluates the intent against:
- Amount limits — per-transaction, daily, monthly
- Merchant rules — allowlists, blocklists, category restrictions
- Velocity caps — max transactions per hour/day
- Approval workflows — some intents require human confirmation
- Risk scoring — fraud signals, geo-checks, behavioral anomalies
If the intent fails any check, it's denied. No credential is created. The agent gets a structured rejection with the reason.
Grant. If the intent passes, a grant is issued — an authorization that says "this specific agent is allowed to spend up to €X at merchant Y within the next Z minutes." The grant has a TTL. If unused, it expires. This grant is the application-level analogue of AP2's Cart Mandate — a scoped, time-limited authorization bound to a specific transaction.
Issue. The grant triggers virtual card issuance through the card issuing API. A new Visa virtual card is created, locked to the grant's constraints. The PAN is encrypted with AES-256-GCM before storage. The agent never sees the raw card number — it receives a credential token.
Redeem. The agent presents the credential token to complete the purchase. The token resolves to actual card details only at the payment boundary — the merchant's checkout — and is immediately invalidated after use.
Settle. The transaction settles through Visa's network. Ovra matches the settlement to the original intent, updates the ledger, and fires webhooks. If the settled amount differs from the intent (partial shipment, currency conversion), the discrepancy is logged and flagged.
What does the agent actually see?
This distinction is the core security property.
The agent sees:
- An intent ID
- A credential token (opaque string)
- Transaction status updates
The agent never sees:
- Card numbers (PAN)
- CVV/CVC codes
- Expiry dates
- Raw card data of any kind
The card data exists only inside Ovra's encrypted storage and at the Visa network level. Even Ovra's own API never returns raw PAN — only masked versions (**** **** **** 4242) for dashboard display.
This is what we call zero-knowledge checkout. The agent completes a purchase without possessing the information needed to make unauthorized purchases. It's also what makes prompt-injection-driven theft structurally impossible — the secret the attacker would want isn't in the agent's context.
How are policies expressed?
Policies in Ovra are declarative rules attached to agents or wallets. A policy looks like this:
{
"name": "procurement-standard",
"rules": {
"maxTransactionEuros": 500,
"maxDailyEuros": 2000,
"maxMonthlyEuros": 10000,
"merchantAllowlist": ["aws.amazon.com", "github.com", "vercel.com"],
"categoryBlocklist": ["gambling", "crypto"],
"requireApproval": false,
"velocityLimit": { "maxPerHour": 10 }
}
}
Policies are evaluated synchronously during the intent phase. There's no async "check later" — the policy engine is in the critical path. If the engine is down, no intents are approved. Fail-closed, not fail-open.
Multiple policies can apply to a single agent (agent-level + wallet-level + workspace-level). They're evaluated in order, and the most restrictive rule wins.
How does risk scoring fit in?
On top of policy rules, every intent runs through a risk scoring pipeline:
- Amount anomaly — is this purchase significantly larger than the agent's historical average?
- Merchant trust — has this merchant been seen before? What's the chargeback rate?
- Velocity spike — is the agent suddenly making more transactions than usual?
- Geo-mismatch — is the merchant's country consistent with the agent's operating region?
The risk score feeds back into the policy check. Configurable thresholds determine whether a high-risk intent is auto-denied, held for review, or flagged for post-transaction audit.
This is also where Mastercard's Verifiable Intent (open-sourced March 2026 with Google, Fiserv, IBM, Checkout.com, and Basis Theory) starts to integrate naturally — the linkage of consumer identity, agent instruction, and transaction outcome is the same audit trail risk scoring already produces.
What's in the audit trail?
Every state transition is logged. Every policy evaluation is logged. Every credential issuance and destruction is logged. The audit trail is immutable and queryable.
For a single payment, you can reconstruct the entire decision chain: which agent requested it, which policy evaluated it, what the risk score was, which card was issued, when it was used, what the merchant charged, and how it settled.
This isn't just for debugging. For regulated industries, the audit trail is the compliance artifact. PSD3 and the PSR reached provisional agreement on November 27, 2025, with mandatory Verification of Payee, strengthened Strong Customer Authentication, and new platform liability for fraud — all of which presume an auditable consent and authorization chain. AML requires transaction monitoring. GDPR requires data access logging. The audit trail covers all three.
What breaks without this?
Without infrastructure-level spend control, you get:
- Agents that overspend because there's no pre-authorization
- Shared credentials that can't be attributed to specific agents
- Policy violations discovered days later on bank statements
- No audit trail for compliance
- Credential leakage through prompt injection or model errors
With it, you get agents that transact autonomously within provable constraints. That's the difference between a demo and production.
Ovra is payment infrastructure for AI agents. If you're deploying agents that need to make purchases, get in touch.
Frequently asked questions
- How does Ovra prevent AI agents from overspending?
- Every payment moves through a six-state machine — Intent → Policy Check → Grant → Issue → Redeem → Settle — with policy evaluated before any credential exists. Limits, merchant allowlists, velocity caps, and approval workflows are enforced at the infrastructure level, not inside the agent. The agent never sees raw card data, so it cannot bypass controls. This pattern mirrors AP2's verifiable mandate model and meets PSD3/PSR's pre-authorization expectations.
- What does the agent actually see during a payment?
- The agent sees an intent ID, a credential token (opaque string), and transaction status updates. It never sees PAN, CVV, expiry, or any raw card data. The card data exists only inside Ovra's encrypted storage (AES-256-GCM) and at the Visa network level. Even Ovra's own API never returns raw PAN — only masked versions like '**** 4242' for dashboard display. We call this zero-knowledge checkout.
- What happens if the policy engine is down?
- Fail-closed. No intents are approved if the engine is unreachable. Policy evaluation is synchronous and on the critical path of every payment — there is no async 'check later' fallback. This is the only design that works for autonomous agents: a brief outage is preferable to silently approved transactions during the gap.
- How does Ovra's spend control compare to AP2 mandates?
- Conceptually identical, different layer. AP2's Cart Mandate and Intent Mandate cryptographically bind user authorization to a specific transaction before a credential is issued. Ovra's Intent → Grant → Issue does the same at the application layer — the intent is policy-checked and signed-off before any card data exists. As AP2 ships at the network level, Ovra plugs in directly without changing its developer interface.
- What's in Ovra's audit trail?
- Every state transition, every policy evaluation, every credential issuance and destruction, every webhook fired. For a single payment you can reconstruct the full decision chain: which agent requested it, which policy evaluated it, what the risk score was, which card was issued, when it was used, what the merchant charged, and how it settled. The trail is immutable and queryable — the compliance artifact for PSD3/PSR, GDPR, and AML reporting.