What is an AI-agent payment mandate?

Why an agent needs a mandate

An AI agent can plan, search, compare, negotiate, fill forms, and request an action. Those capabilities do not answer whether the business authorized a particular purchase. The agent may misunderstand a user, operate on stale context, encounter hostile instructions, or choose an option outside the user’s intent.

A mandate turns broad intent into a boundary the agent cannot rewrite. Instead of telling a model, “Be careful and do not overspend,” an operator can define a $2,000 monthly budget, a $250 autonomous transaction limit, allowed categories, blocked categories, merchant rules, allowed countries, an expiration date, and conditions that require human approval.

The agent remains useful because it can initiate routine work. The business remains in control because the authority comes from a separate, inspectable object.

A concrete example

Imagine a small company creates an agent named Procurement Desk. Its purpose is to renew everyday software and order ordinary office equipment. The owner activates this mandate:

• Monthly budget: $2,000.
• Maximum autonomous transaction: $250.
• Allowed categories: software and office equipment.
• Blocked categories: cryptocurrency and gambling.
• New merchants: human approval required.
• Allowed country: United States.
• Expiration: end of the current quarter.

The text is understandable to a person, but the active policy is structured data. That distinction allows the authorization engine to evaluate the same facts the same way every time.

How a request moves through the system

1. 01User intentThe owner defines the agent’s job and reviews the proposed rules.
2. 02Agent identityA scoped credential authenticates Procurement Desk and its organization.
3. 03Purchase requestThe agent submits merchant, amount, currency, category, country, and a unique request key.
4. 04Policy evaluationDeterministic code checks the active mandate, budget, limits, scope, and expiration.
5. 05Risk evaluationSeparate signals assess anomaly, merchant novelty, velocity, category mismatch, and geography.
6. 06DecisionThe system returns APPROVED, APPROVAL_REQUIRED, or DECLINED with reasons.
7. 07Human resolutionIf queued, a reviewer approves or declines the single request and adds evidence.
8. 08Audit recordThe complete chain points to the exact mandate version used.

The three decisions are intentionally different

APPROVED means the request fits the active authority and did not trigger a required review. In a simulation, it means only that the authorization result was approved; no money moves. In a future provider integration, a separate adapter could consume a tightly bound authorization.

APPROVAL_REQUIRED means the request is eligible for a person to resolve but cannot proceed autonomously. A new merchant or an amount above the autonomous threshold can create this state.

DECLINED means a hard boundary failed: the agent is paused, the mandate expired, the budget is exhausted, the merchant or category is blocked, or geography is disallowed. A reviewer should not erase that result with a casual override. They can change policy deliberately and submit a new request.

A mandate is not a prompt

A prompt is an instruction presented to a model. It can guide interpretation, but it is not a reliable enforcement mechanism. A mandate is validated data evaluated outside the model. The agent and the model cannot declare that their own request is approved.

Natural language can make mandate creation easier. A model may translate “Let my procurement agent renew ordinary software but ask me before using a new vendor” into proposed fields. The user should inspect the result, resolve ambiguity, and activate a specific version. The model never activates the mandate or evaluates transactions.

This separation also contains prompt injection. Malicious content may influence what an agent asks for, but it cannot change the authenticated agent identity, active budget, allowed categories, or policy code.

A mandate is not an API key

The mandate defines authority. The API key identifies the caller and limits which interface that caller can use. They work together but solve different problems.

A scoped key for Procurement Desk might permit only transaction submission for that agent. It should not allow the holder to create users, activate mandates, read other agents, or change budgets. When the server receives a request, it derives the organization and agent from the credential and loads the matching active mandate.

Putting keys beneath an agent or mandate in the interface helps an operator understand which authority the credential can invoke. The secret itself should be shown once, stored only as a hash, rotated when necessary, and revoked immediately if exposed.

A mandate is not a payment credential

A card number, bank token, or payment-provider credential enables interaction with financial rails. A mandate expresses business permission. The two should not be confused or stored together casually.

Mandate’s current MVP is a simulation. It records intent, evaluates rules and risk, queues human review, and preserves decisions. It does not process real payments, store card details, or claim that an approved request was settled.

A future integration could place a provider adapter after authorization. That adapter would still need provider authentication, fraud controls, settlement handling, refunds, disputes, reconciliation, and regulatory review. The mandate remains the upstream authority record.

What belongs inside a mandate

Risk complements the mandate

A mandate cannot predict every suspicious pattern. A request may be technically eligible but unusually large for the agent, arrive at abnormal velocity, involve a first-time merchant, or mismatch expected geography. A risk engine can identify those factors and escalate the request.

Risk should be monotonic: it can move an eligible request toward more scrutiny, never move a blocked request toward approval. A low risk score cannot make cryptocurrency eligible when the mandate blocks it. A high score should come with named factors rather than an unexplained number.

Policy evidence and risk evidence should remain separate in the audit trail so an operator can tell whether the action lacked authority or merely looked unusual.

Versioning makes the record defensible

Suppose the owner raises the autonomous limit from $250 to $500 next month. A transaction evaluated today must still point to the $250 version. Rewriting the old mandate in place would make historical decisions appear to have been evaluated under rules that did not yet exist.

Each activated version should record who changed it, when it became active, what fields changed, and why. Pausing or revoking an agent should append lifecycle events. Human approvals should append resolutions without deleting the original APPROVAL_REQUIRED result.

A hash-linked audit trail can make later tampering evident, but the interface must also render a human-readable chain. Hashes alone do not explain authority.

What a production mandate system still needs

A production system needs more than a clean three-state demo. It needs strong tenant isolation, secure sessions, key rotation, rate limiting, idempotency, database constraints, backups, monitoring, incident response, access reviews, and independent security testing. Real payment integration adds provider-specific controls and legal obligations.

Mandates also need operational governance: owners, approval roles, policy review schedules, change receipts, exportable evidence, and a process for exceptions. The product should never label synthetic data as real activity or imply a connection that does not exist.

The architecture remains valuable before those integrations. It establishes the key boundary: agents request; people define authority; deterministic systems decide; humans resolve exceptions; evidence survives.

The simplest test

Ask whether the agent, the model, or untrusted content can expand the authority used to approve the same request. If it can, the design is circular. A genuine mandate lives outside that loop.

To create one, follow the practical guide to setting AI-agent spending limits. To see the full operational sequence, use the agentic commerce field guide.