Securing Agents with Policies

An agent without policies is an open wallet. This guide walks through configuring the policies, alerts, and controls that make Conto valuable in production, from basic spend caps to x402 micropayment budgets.

Prerequisites

An active agent with a linked wallet

Familiarity with the payment request/execute flow (Quickstart)

How Policies Work

Before diving in, three rules to remember:

AND logic: All assigned policies are evaluated. The most restrictive outcome wins.
First deny stops: If any policy returns DENY, evaluation stops immediately.
Wallet limits first: Wallet-level per-transaction/daily/weekly/monthly limits are checked before policy rules.

Payment Request
  → Wallet Limits (per-tx, daily, weekly, monthly)
    → Org-Level Policies
      → Agent-Level Policies
        → Result: APPROVED / DENIED / REQUIRES_APPROVAL

Layer 1: Spending Limits

The foundation. Every production agent should have spend caps.

Daily Budget

Prevents a runaway agent from draining the wallet in a single day.

Create the policy

Go to Policies → Create Policy.

Field	Value
Name	Daily Budget: $100
Policy Type	SPEND_LIMIT

Add rule

Field	Value
Rule Type	DAILY_LIMIT
Operator	LTE
Value	100
Action	ALLOW

The agent can spend up to $100 per day across all transactions. Resets at midnight UTC.

Assign to agent

Go to the agent’s Permissions tab and assign this policy.

Per-Transaction Cap

Prevents any single large transaction, even if the daily budget has room.

Field	Value
Rule Type	MAX_AMOUNT
Operator	LTE
Value	25
Action	ALLOW

Add this as a second rule in the same policy, or create a separate policy. Both approaches work. Conto evaluates all rules regardless.

Human Approval for Large Payments

Automatically escalate payments above a threshold for human review.

Field	Value
Name	Approval Above $50
Policy Type	APPROVAL_THRESHOLD
Rule Type	REQUIRE_APPROVAL_ABOVE
Operator	GREATER_THAN
Value	50
Action	REQUIRE_APPROVAL

Payments over $50 show up in Pending Approvals in the dashboard. The agent receives REQUIRES_APPROVAL and can poll or use webhooks to check status.

A common pattern: set MAX_AMOUNT to

200 (hard deny above) and REQUIRE_APPROVAL_ABOVE to

50 (human review in the middle). Payments under

50 flow automatically,

50-

200 need approval, and above

200 are blocked outright.

Layer 2: Counterparty Controls

Control who your agent can pay, not just how much.

Allowlist Known Recipients

Only permit payments to pre-approved addresses.

Create the policy

Field	Value
Name	Approved Recipients Only
Policy Type	COUNTERPARTY

Add rule

Field	Value
Rule Type	ALLOWED_COUNTERPARTIES
Value	Comma-separated list of addresses
Action	ALLOW

Only addresses in this list can receive payments. All others are denied.

Block Specific Addresses

Alternatively, allow all recipients except specific blocked ones:

Field	Value
Rule Type	BLOCKED_COUNTERPARTIES
Value	`0xSuspiciousAddress1, 0xSuspiciousAddress2`
Action	DENY

Trust Score Threshold

Require counterparties to have a minimum trust score before receiving payments:

Field	Value
Rule Type	TRUST_SCORE
Operator	GTE
Value	0.5
Action	ALLOW

New, unknown counterparties start with a low trust score. As transaction history builds, their score increases. See Trust Providers for how scoring works.

Layer 3: Time Controls

Restrict when your agent can make payments.

Business Hours Only

Allow payments Monday-Friday, 9am-6pm in the policy evaluator's local time

Create the policy

Field	Value
Name	Business Hours Only
Policy Type	TIME_WINDOW

Add time window rule

Field	Value
Rule Type	TIME_WINDOW
Start Time	09:00
End Time	18:00
Action	ALLOW

Add day-of-week rule

Field	Value
Rule Type	DAY_OF_WEEK
Value	`["Mon", "Tue", "Wed", "Thu", "Fri"]`
Action	ALLOW

Both rules must pass (AND logic). Payments outside business hours or on weekends are denied.

Policy-rule time windows use the server’s local time. Use wallet-level time windows when you need an explicit IANA timezone such as America/New_York.

Blackout Periods

Block payments during specific date ranges (holidays, maintenance windows):

Field	Value
Rule Type	BLACKOUT_PERIOD
Start Date	2025-12-24
End Date	2025-12-26
Action	DENY

Layer 4: x402 Micropayment Controls

If your agent pays for APIs using the x402 protocol, add dedicated micropayment policies.

Cap Per API Call

Prevent a single expensive API call from draining the budget:

Field	Value
Rule Type	X402_MAX_PER_REQUEST
Operator	LTE
Value	0.10
Action	ALLOW

No single x402 payment can exceed $0.10.

Budget Per Service

Limit total spending on a specific API service:

Field	Value
Rule Type	X402_MAX_PER_SERVICE
Operator	LTE
Value	`{"maxAmount": 50, "period": "DAILY"}`
Action	ALLOW

Total spend per service domain cannot exceed $50.

Allowlist Approved Services

Only allow x402 payments to known API providers:

Field	Value
Rule Type	X402_ALLOWED_SERVICES
Operator	IN_LIST
Value	`["api.example.com", "data.provider.io"]`
Action	ALLOW

Payments to any other x402 service domain are denied.

Layer 5: Alerts

Policies prevent bad transactions. Alerts tell you when something interesting happens.

Recommended Alert Configuration

Go to Alerts in the sidebar and configure:

Alert Type	Threshold	Why
High-Value Transaction	$50+	Know when large payments execute
Spend Limit Warning	80% of daily limit	React before the agent hits its cap
Low Balance	$50 remaining	Top up before payments start failing
Policy Violation	Any	Track what the agent is trying to do that gets blocked
New Counterparty	First transaction	Know when the agent pays someone new

x402-Specific Alerts

If using x402 micropayments, also enable:

Alert Type	Why
Price Spike	API suddenly charging more than usual
High Frequency	Agent making unusually many API calls
New Service	Agent paying a service for the first time
Budget Burn Rate	Approaching x402 budget limits

Putting It Together: Example Configuration

Here’s a production-ready policy stack for a typical AI agent:

Policy	Rules	Effect
Spend Controls	MAX_AMOUNT ≤ $50, DAILY_LIMIT ≤$ 200	Hard caps on individual and daily spending
Human Review	REQUIRE_APPROVAL_ABOVE $25	Manager reviews payments $25-$ 50
Known Recipients	ALLOWED_COUNTERPARTIES: [list]	Only pays approved addresses
Business Hours	TIME_WINDOW 9-18, DAY_OF_WEEK M-F	No weekend/overnight payments
x402 Guardrails	MAX_PER_REQUEST ≤ $0.10, MAX_PER_SERVICE ≤$ 20	Micropayment safety net

With this stack, the agent can:

Automatically pay up to $25 to known recipients during business hours
Request human approval for $25-$ 50 payments
Never exceed $50 in a single transaction or$ 200/day
Pay for x402 APIs up to $0.10/call and$ 20/service

Verifying Your Policies

After setting up, verify with the setup endpoint:

curl https://conto.finance/api/sdk/setup \
  -H "Authorization: Bearer $CONTO_API_KEY"

The policies array shows all active policies and their rules. Run a few test transactions to confirm enforcement before going live.

Troubleshooting

Policy assigned but not enforcing

Policies must be assigned to the agent in the Permissions tab. Creating a policy doesn’t apply it automatically. Also verify the policy status is ACTIVE (not DRAFT or DISABLED).

Too many violations, agent can't do anything

Policies stack with AND logic. If you have 5 restrictive policies, the agent must pass all of them. Review each policy’s rules and consider loosening thresholds or removing redundant policies.

Org-level policy still denying

Organization-level policies apply to all agents and stack with agent policies. If an org policy caps transactions at

25, an agent-level policy allowing

100 won’t override it. Check with your org admin.

Wallet limits vs. policy limits confusion

Wallet-level limits (set when linking a wallet) are checked first and separately from policies. If the wallet per-transaction limit is

10 but your policy allows

50, the wallet limit wins. Edit wallet limits from the agent detail page.

Next Steps

Recipes

Copy-paste policy configurations for common scenarios

Advanced Policies

x402, MPP, geographic, and DeFi policy rules

Trust Providers

Counterparty trust scoring and verification

Policy Testing

Step-by-step policy enforcement testing

Start

Products

Build

Guides

Reference

Changelog

Securing Agents with Policies

Securing Agents with Policies

Prerequisites

How Policies Work

Layer 1: Spending Limits

Daily Budget

Per-Transaction Cap

Human Approval for Large Payments

Layer 2: Counterparty Controls

Allowlist Known Recipients

Block Specific Addresses

Trust Score Threshold

Layer 3: Time Controls

Business Hours Only

Blackout Periods

Layer 4: x402 Micropayment Controls

Cap Per API Call

Budget Per Service

Allowlist Approved Services

Layer 5: Alerts

Recommended Alert Configuration

x402-Specific Alerts

Putting It Together: Example Configuration

Verifying Your Policies

Troubleshooting

Next Steps

Recipes

Advanced Policies

Trust Providers

Policy Testing

​Securing Agents with Policies

​Prerequisites

​How Policies Work

​Layer 1: Spending Limits

​Daily Budget

​Per-Transaction Cap

​Human Approval for Large Payments

​Layer 2: Counterparty Controls

​Allowlist Known Recipients

​Block Specific Addresses

​Trust Score Threshold

​Layer 3: Time Controls

​Business Hours Only

​Blackout Periods

​Layer 4: x402 Micropayment Controls

​Cap Per API Call

​Budget Per Service

​Allowlist Approved Services

​Layer 5: Alerts

​Recommended Alert Configuration

​x402-Specific Alerts

​Putting It Together: Example Configuration

​Verifying Your Policies

​Troubleshooting

​Next Steps

Recipes

Advanced Policies

Trust Providers

Policy Testing

Securing Agents with Policies

Prerequisites

How Policies Work

Layer 1: Spending Limits

Daily Budget

Per-Transaction Cap

Human Approval for Large Payments

Layer 2: Counterparty Controls

Allowlist Known Recipients

Block Specific Addresses

Trust Score Threshold

Layer 3: Time Controls

Business Hours Only

Blackout Periods

Layer 4: x402 Micropayment Controls

Cap Per API Call

Budget Per Service

Allowlist Approved Services

Layer 5: Alerts

Recommended Alert Configuration

x402-Specific Alerts

Putting It Together: Example Configuration

Verifying Your Policies

Troubleshooting

Next Steps