Agent Commerce · Features
Policy-gated transactions
A policy-gated transaction is a payment that must pass a structured policy evaluation before it can execute. For autonomous AI agents, this is not optional — it is the mechanism that makes autonomous spending safe.
Agent Commerce's payment policy engine evaluates every agent spend request against configurable rules — limits, merchant restrictions, rail controls, human review thresholds — and returns a decision with a recorded reason before any money moves.
The three decision outcomes
Every policy evaluation returns exactly one of these outcomes — with a reason.
authorized
The request passed all policy checks. The payment is dispatched to the rail. A signed receipt is issued on execution.
blocked
The request violated at least one policy rule (spend limit exceeded, merchant not on allowlist, forbidden rail, etc.). No payment executes. The blocked decision and reason are recorded.
needs_review
The request is above the configured human review threshold or triggered a review condition. The payment is held until a designated human reviewer explicitly approves or rejects it. The agent cannot proceed without that approval.
The evaluation pipeline
Checks run in sequence. The first failure determines the outcome.
Request received
The agent submits a structured spend request: amount, currency, merchant, rail, purpose tag, and idempotency key.
Rail check
The policy engine checks whether the requested rail is enabled for this agent. Disabled or unsupported rails are blocked immediately.
Merchant check
If a merchant allowlist is configured, the merchant is checked against it. Payments to non-allowlisted merchants are blocked.
Spend limit check
The per-transaction ceiling and daily cumulative limit are evaluated. Requests that would exceed either limit are blocked or escalated.
Human review threshold
If the amount exceeds the human review threshold, the outcome is needs_review regardless of other limits. No payment executes until a human approves.
Decision recorded
The outcome (authorized / blocked / needs_review), reason codes, policy version, and actor identity are written as a decision lineage entry before any rail dispatch.
Why gating matters for autonomous systems
Traditional payment controls assume a human is making the payment decision. When an autonomous agent is making the payment, the control layer must move upstream — into the system that evaluates the request before dispatch, not after.
Policy gating is that upstream control. Every agent spend request is evaluated by the policy engine before any payment executes. This is fundamentally different from monitoring or rate-limiting: it is prevention, not detection.
The policy is the agent's principal — the structured authority that the agent must satisfy before acting.
Frequently asked questions
What is a policy-gated transaction?
A policy-gated transaction is a payment that must pass a structured policy evaluation before it can execute. For AI agents, this means every spend request is checked against configurable rules — spend limits, merchant restrictions, rail allowances, purpose tags — before any money moves. The policy engine returns a decision (authorized, blocked, or needs_review) with a recorded reason.
How is policy gating different from fraud detection?
Fraud detection is reactive — it identifies suspicious patterns after transactions occur. Policy gating is preventive — it applies explicit rules before any transaction executes. A policy-gated system does not need to detect that something went wrong; it prevents the wrong thing from happening.
What happens to a blocked transaction?
A blocked transaction does not execute. The policy engine records the blocked decision — including the reason (e.g., 'per_transaction_limit_exceeded', 'merchant_not_allowlisted') and the policy version that applied. No money moves, and no payment is issued. The blocked attempt is in the audit trail.
Can the agent see why a transaction was blocked?
Yes. The policy engine returns structured reason codes with the blocked decision. These reason codes are part of the decision record and are available to the agent, the developer, and reviewers for debugging and audit.
Who can change the policy?
Policy configuration is a separate administrative operation from payment execution. The agent cannot modify its own policy. Policy changes require explicit administrative access — making it impossible for a compromised or misbehaving agent to expand its own spending authority.
What is the needs_review outcome?
needs_review is returned when a request is above the configured human review threshold or triggers a review condition. The payment is held in a pending state. A designated human reviewer must explicitly approve or reject it before execution. The agent cannot proceed without that approval — it must wait for the review decision.
Add policy gating to your agent payments
Agent Commerce enforces your payment policy before any agent payment executes — not after.