If you give an AI agent a credit card, it will spend money. The question is: whose rules does it follow?
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. Here's how the system works, end to end.
The six-state machine
Every payment on Ovra moves through a strict 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.
Issue. The grant triggers virtual card issuance through the card issuing API. A new Visa card number 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 is resolved to the actual card details at the payment boundary - the merchant's checkout - and 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 the agent sees vs. what exists
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.
Policy engine internals
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 + global). They're evaluated in order, and the most restrictive rule wins.
Risk scoring
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.
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, this audit trail is the compliance artifact. PSD2 requires strong customer authentication records. 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.