> ## Documentation Index
> Fetch the complete documentation index at: https://conto.finance/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Securing Agents with Policies
> Production-ready policy configurations for spending limits, time controls, counterparty rules, and alerts
# 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](/quickstart/setup))
## How Policies Work
Before diving in, three rules to remember:
1. **AND logic**: All assigned policies are evaluated. The most restrictive outcome wins.
2. **First deny stops**: If any policy returns DENY, evaluation stops immediately.
3. **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.
Go to **Policies** → **New Policy**.
| Field | Value |
| ----------- | ------------------- |
| Name | Daily Budget: \$100 |
| Policy Type | SPEND\_LIMIT |
| 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.
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.
| Field | Value |
| ----------- | ------------------------ |
| Name | Approved Recipients Only |
| Policy Type | COUNTERPARTY |
| 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](/integrations/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
```
| Field | Value |
| ----------- | ------------------- |
| Name | Business Hours Only |
| Policy Type | TIME\_WINDOW |
| Field | Value |
| ---------- | ------------ |
| Rule Type | TIME\_WINDOW |
| Start Time | 09:00 |
| End Time | 18:00 |
| Action | ALLOW |
| 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](/sdk/x402-payments), 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:
```bash theme={null}
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](/guides/testing-payments) to confirm enforcement before going live.
## Troubleshooting
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).
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.
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-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
Copy-paste policy configurations for common scenarios
x402, MPP, geographic, and DeFi policy rules
Counterparty trust scoring and verification
Step-by-step policy enforcement testing