Agent Commerce · Core Concept
Payment policy engine
A payment policy engine is a runtime system that evaluates and enforces rules governing AI agent payments. It sits between what is allowed — defined by authorization — and what actually executes.
Every spend request from an AI agent passes through the policy engine before money moves. If it fails any rule, the payment is blocked. No exceptions, no fallback execution.
Where this fits in the lifecycle
Policy evaluation runs after an authorization request is received and before payment execution begins.
What the policy engine evaluates
Rules are evaluated in sequence. The first failure short-circuits the evaluation — the payment is blocked immediately, and a reason code is recorded. If no policy exists for an agent, the request is blocked by default.
Rail allowlist
blocked_railIs the requested payment rail (Stripe, USDC, ETH) permitted for this agent?
Currency allowlist
blocked_currencyIs the currency permitted? A policy may allow USD but not ETH.
Merchant allowlist
blocked_merchantIs the payee on the approved merchant list for this agent?
Amount ceiling
amount_exceeds_limitDoes the requested amount exceed the per-transaction limit?
Purpose tag filter
blocked_purpose_tagIs the payment purpose (data_access, api_call, saas_renewal) permitted?
Human review threshold
requires_human_reviewDoes the amount require human approval before execution?
Outcomes: authorized · blocked · needs_review
Why authorization alone is not enough
Authorization defines intent: what an agent is generally permitted to do. But AI agents operate dynamically — they encounter merchants, amounts, and scenarios that were not explicitly anticipated when the authorization was set up.
The policy engine enforces rules at the moment of execution, against the specific payment being requested. It applies the same deterministic logic to every transaction — regardless of context, timing, or what the agent was told to do.
This is the difference between an agent being allowed to spend money and a specific payment request being permitted under current policy.
Policy engine vs governance
Policy engine
- —Enforces rules in real time
- —Evaluates each payment request individually
- —Runs deterministically — same input, same outcome
- —Short-circuits on first rule failure
- —Produces a decision record for every evaluation
Governance
- —Defines and evolves the rules themselves
- —Monitors patterns across many payments
- —Handles escalation and human review
- —Produces audit trails and compliance reports
- —Sets the policy the engine enforces
The policy engine is operational. Governance is structural. Both are required for a trustworthy system.
Every evaluation produces a decision record
When the policy engine evaluates a payment, it records the decision — what was requested, which rules were evaluated, what outcome was returned, and which policy version was active at the time.
This record is not overwritten if the payment later succeeds or fails. It is a permanent log of what the policy engine decided and why.
Authorization decisions feed directly into the decision lineage — a queryable record of every approved, blocked, and escalated payment request across all agents.
Explore further
The policy engine is one part of a larger system. The detailed rule schema and event types live in the Agent Commerce protocol reference.
AI spend governance
How the rules the policy engine enforces are defined, monitored, and evolved over time.
Read about governance →
Payment authorization
How authorization requests are constructed and what they define before the policy engine evaluates them.
Read about authorization →
Event taxonomy
The canonical event types emitted by the policy engine — authorization.evaluated, outcomes, and downstream events.
View event taxonomy →
Policy-gated transactions
How every agent payment request passes through policy evaluation before any money moves.
Read more →
Build policy-governed payments
Agent Commerce enforces your payment policy before any agent payment executes — not after.