How do I configure automatic Agent payments and manual approval?

Use origins, recipients, automatic thresholds, per-payment limits, and daily budgets to define when an Agent can pay autonomously.

Configure these boundaries in the Agent's spending policy. Routine, low-risk payments can be approved automatically within explicit limits. Unknown targets or higher amounts require manual approval, while payments beyond hard limits are rejected.

Wallet signing is not the same as manual approval. Each new payment still needs a wallet signature, but the customer-hosted signer sidecar validates a short-lived execution grant and signs automatically. It does not require someone to open a wallet or remain at their computer.

Default behavior

A new Payment Agent starts with a conservative policy:

allowedOrigins and allowedPayTo are empty.
automaticPaymentThresholdAtomic is 0.
unknown origins and recipients require manual approval.

Consequently, normal payments enter manual approval until an operator creates and activates an explicit policy version. Policy versions are immutable. Create and activate a new version when changing the rules.

Configure the automatic-payment scope

You can configure this in either of the following two ways. Both write the same spending policy and produce the same active-payment rules:

Dashboard: Open Payment agents, find the target Agent, and select Manage. On the Agent detail page, complete Create spending policy version and select Create policy version. The new version remains inactive until you select Activate for it in the Spending policy versions list below.
Code: Run the management SDK example below. It creates and activates the equivalent policy programmatically. Use the dashboard for one-off manual setup, or the SDK when you need repeatable configuration in infrastructure code.

This sandbox example lets an Agent automatically pay a known service up to 0.25 USDC. A payment to the same target above the automatic threshold but no greater than 1 USDC requires manual approval, while a payment above 1 USDC is rejected:

const version = await management.agents.createPolicyVersion(agent.id, {
  network: 'eip155:84532',
  asset: {
    symbol: 'USDC',
    contractAddress: '0x036CbD53842c5426634e7929541eC2318f3dCF7e',
  },
  allowedOrigins: ['https://resource.example.com'],
  allowedPayTo: ['0x1234567890abcdef1234567890abcdef12345678'],
  automaticPaymentThresholdAtomic: '250000', // 0.25 USDC
  perPaymentLimitAtomic: '1000000', // 1 USDC
  agentDailyLimitAtomic: '5000000', // 5 USDC
  requireApprovalForUnknownOrigin: true,
  requireApprovalForUnknownPayTo: true,
})

await management.agents.activatePolicyVersion(agent.id, version.id)

The example amounts use the 6 decimals of Base Sepolia USDC. For another supported network, use the smallest unit of its configured asset and check the current support matrix.

After activation, each payment is evaluated as follows:

Condition	Outcome
Network or asset mismatch, or amount above `perPaymentLimitAtomic`	Rejected. Approval cannot override it
Origin and recipient are allowed, and amount is no greater than `automaticPaymentThresholdAtomic`	Automatically approved and signed
Unknown origin or recipient, or amount above the automatic threshold but within the per-payment limit	Awaits one-time manual approval
Organization or Agent budget exhausted, or another hard risk or pause control fails	Rejected. Approval cannot override it

The automatic threshold cannot exceed the per-payment limit. Effective daily spending is also constrained by the policy's Agent daily limit, the Agent budget, the organization budget, and platform ceilings. The strictest applicable limit wins.

Choose safe boundaries

Start with least privilege:

Allow only the HTTPS origins the Agent actually needs. Avoid broad domain scopes.
Allow only recipient addresses published by and verified for the seller. Do not trust an address supplied by the Agent.
Set the automatic threshold to the small amount expected for a routine call.
Use the per-payment limit as the maximum amount eligible for a human decision.
Use Agent and organization daily budgets to cap cumulative loss from a runaway loop.
Keep policies, wallets, signers, and budgets separate between Sandbox and Live.

Do not make an Agent unattended by giving it a Management API Key, an administrator session, or general-purpose wallet signing. Doing so bypasses the boundary between autonomous payments and human approval.

Signing while unattended

Run the signer sidecar as an always-on service alongside the Agent runtime:

listen only on loopback and use a high-entropy sidecar token.
persist authorization records so restarts preserve replay protection.
configure process restart, health checks, and alerts.
use a local test signer for EVM Sandbox, AWS KMS for EVM Live, or the customer-hosted local signer for Solana.

Every new payment authorization triggers one automatic signature. A safe retry of the same execution grant reuses the stored signature result, requires no human action, and does not create a different payment.

When manual approval is required

Treat awaiting_approval as durable business state instead of keeping the Agent process blocked:

Save the returned intentId, approvalId, and approvalExpiresAt.
Notify an administrator through the agent_payment.intent.awaiting_approval Webhook or your own notification system.
Let the Agent continue work that does not depend on this payment.
After approval, resume with the original intentId as resumeIntentId.

Approval is valid for 30 minutes by default. It authorizes only the locked origin, recipient, network, asset, and maximum amount. It does not modify the spending policy. See Why is a payment awaiting approval, and how do I resume it? for the complete recovery flow.