Spending caps
A per-request cap rejects any single challenge above a fixed amount. It stops one surprise, such as a server that quotes a hundred times its usual price.
Limit: many small payments each pass a cap. Pair it with a rolling budget.
Rolling budgets
A rolling budget sums allowed payments over a sliding window, for example the last 24 hours, and denies a request that would push the total over the limit. It bounds the cost of loops, retries and slow drains.
Limit: the sum comes from the local ledger. Allowed payments that fail to settle must be reconciled, or the budget becomes too strict; payments made outside the layer are not counted at all.
Network and asset allowlists
Challenges may offer several networks and assets. The policy accepts only those the operator lists, by network identifier and token contract. Anything else is dropped before evaluation, and a challenge with no acceptable option is denied.
Limit: an allowlist trusts the listed contract. Verify contract addresses from the issuer's own documentation, never from a challenge.
Quote expiry
The engine records when a challenge arrived and refuses to authorize it after a maximum age, and never later than the server's own maxTimeoutSeconds. A stale quote is refetched, not paid.
Replay protection
x402 payment schemes include their own replay protection, such as single-use authorizations. PAY//AGENT adds a client-side record of nonces and payment identifiers, so the agent never submits the same authorization twice and duplicated challenges are flagged.
Prompt-injection risks
Text from web pages, tool results and documents can contain instructions. An injected instruction might ask the agent to pay a new address, raise its own limit, or treat a payment as urgent.
- The agent cannot edit the policy, the payee list or the signer configuration. These live outside its tools.
- Payees are pinned per origin. A changed payee is denied with
PA_PAYEE_NOT_ALLOWED, whatever the agent was told. - Verdicts never depend on model output. The model can request; only the rules decide.
- Denials are returned as structured errors, so a manipulated agent cannot quietly retry with different wording.
No policy makes an agent trustworthy. It limits how much an untrustworthy decision can cost.
Wallet isolation
- Use a dedicated spending wallet per agent, holding only a small working balance.
- Keep its key in a separate process, hardware module or custodial service. Never put it in the agent's environment, prompt or logs.
- Top up deliberately and on a schedule, not automatically from a treasury wallet.
Revocation
Setting active to false denies every later request with PA_POLICY_INACTIVE. Removing a payee, network or asset takes effect on the next evaluation. For a suspected key compromise, also move the remaining balance out of the spending wallet; revoking the policy does not stop someone who holds the key.
Escalation
Payments at or above a threshold wait for a person. The approval request shows the origin, payee, amount, policy hash and the agent's stated reason. Unanswered requests expire and are denied. The approval channel is pluggable in the concept; none is implemented.
Responsible disclosure
If you find a flaw in this design or in the playground code, please report it privately before publishing.
- Security contact
- [Placeholder: security contact to be published by the maintainer.] No contact address exists yet.
- Encryption key
- [Placeholder: PGP key fingerprint to be published.]
- Response target
- [Placeholder: acknowledgement and fix timelines to be set by the maintainer.]
- Bounty
- None. There is no bug bounty program.
Until a contact is published, do not post exploit details publicly. Flaws in the x402 protocol itself belong with the official project, listed in the whitepaper references.