Machine View
Policy Overview
Source: https://conto.finance/docs/policies/overview
# Policy Overview
> Control agent spending with policies
- Human URL: https://conto.finance/docs/policies/overview
- Raw Markdown: https://conto.finance/docs/policies/overview.md
- Terminal view: https://conto.finance/ai/docs/policies/overview
Documentation group: Products
# Policy System
The policy system is the core of Conto's spending controls. Policies define rules that govern how AI agents can spend funds.
## What is a Policy?
A policy is a set of rules that determine whether a payment should be:
- **APPROVED** - Payment can proceed
- **DENIED** - Payment is blocked
- **REQUIRES_APPROVAL** - Manual approval needed
## Starter Guardrails for New Organizations
New human organizations start with two active starter policies:
- **Starter guardrails**: `$25` maximum per transaction and `$100` maximum per day
- **Starter approval threshold**: payments above `$10` require explicit approval
The starter policies are ordinary assigned policies visible in the dashboard. Active starters are
linked to new agents automatically and combine with organization baselines and any policies assigned
to the agent or wallet. You can edit, deactivate, or delete them when you are ready to use your own
controls.
Organizations that already had no policies may also see these starter controls after an account
update. This prevents a new or previously unconfigured organization from approving every payment
by default. Approval requests initially go to the owner's email notification channel; see
[Notification Channels](https://conto.finance/integrations/notification-channels) to configure where reviews are sent.
## Policy Types
### Spend Limit
Link: https://conto.finance/policies/spend-limits
Control maximum amounts per transaction, day, week, or month
### Time Window
Link: https://conto.finance/policies/time-windows
Restrict transactions to specific hours and days
### Counterparty
Link: https://conto.finance/policies/counterparties
Control which recipients are allowed based on trust
### Geographic
Link: https://conto.finance/policies/advanced#geographic-restrictions-ofac
OFAC sanctions screening and country restrictions, built-in and configurable
### AgentScore Compliance
Link: https://conto.finance/policies/advanced#agentscore-commerce-rules
Require verified humans, enforce jurisdiction allowlists, and trigger identity step-up before
settlement
### Category
Allow or block specific spending categories
### Contract Allowlist
Link: https://conto.finance/policies/advanced#contract-allowlist
Restrict interactions to approved smart contracts and protocols via Contract Registry
### Approval Threshold
Require manual approval above certain amounts
### Agent Identity
Link: https://conto.finance/policies/advanced#agent-identity-enforcement
Restrict payment authority by environment, risk tier, owner role, identity tags, and attestation
mode
### Velocity
Limit transaction frequency to prevent rapid drain
### Whitelist
Only allow specific pre-approved addresses
### x402 Controls
Link: https://conto.finance/policies/advanced#x402-protocol-rules
Price ceilings, service allowlists, and session budget caps for x402 micropayments
### MPP Controls
Link: https://conto.finance/policies/advanced#mpp-protocol-rules
Session budgets, concurrency limits, and duration caps for MPP payments
### Budget Allocation
Link: https://conto.finance/policies/advanced#budget-allocations
Allocate budgets by department or project with period tracking
### Expiration
Link: https://conto.finance/policies/advanced#expiration-policies
Time-limited permissions with start and end dates
## Policy Evaluation
Policies are evaluated fail-closed. Every active organization baseline plus every policy assigned to
the selected agent, wallet, or card must pass. The first DENY stops evaluation immediately.
Counterparty or relationship review is considered only after hard wallet and policy controls pass,
so an approval route cannot turn a denied payment into an approvable request.
### Policy scope
Every policy has one explicit scope:
- **Organization** — a mandatory baseline applied automatically to every payment in the organization.
- **Assigned** — applies only through an explicit agent, wallet, or card assignment. An unassigned
policy is a draft control and is not enforced.
Use organization scope for universal compliance and safety limits. Use assigned scope for rules that
vary by agent, wallet, or card. Organization baselines cannot be bypassed by removing an assignment.
### Evaluation Order
1. **Pre-checks**: Agent must be ACTIVE with linked wallets
- `DEV` and `STAGING` agents can use only known testnet wallets; mainnet and unclassified chains
fail closed
2. **Geographic & Sanctions**: OFAC country check + address sanctions screening (always active, no policy needed)
3. **Counterparty Trust**: Pre-fetch trust level and network trust score for use in policy rules
4. **Wallet Policies**: Spend limits, wallet-level time windows (timezone-aware), and other configured policy rules
- Identity allow rules evaluate environment, risk tier, owner role, tags, and attestation mode;
missing identity context fails closed
5. **Merchant Identity Gates**: Optional AgentScore assess results can add verified-human, KYC, sanctions, and jurisdiction context before final settlement
6. **Counterparty Rules**: Block list, trust requirements, network intelligence
7. **Relationship Controls**: Per-agent payee limits, category allowlists, approval requirements,
and temporary access expiry
8. **Final Decision**: Aggregate results
Protocol-specific budget rules only count transactions recorded through the matching protocol
flow, so ordinary wallet transfers do not reduce protocol allowances.
Protocol rules also fail closed when a configured control depends on context that the caller did
not provide. For example, facilitator and scheme controls require matching x402 pre-authorization
fields, while MPP session controls require a stable `sessionId`. Endpoint velocity and service call
counts include every item in a recorded batch, not just the aggregate settlement row.
Budget caps can use daily, weekly, monthly, quarterly, or yearly UTC periods and can be scoped by
department, project, or category. Conto aggregates pending, confirming, and confirmed transactions
that match the selected agent, wallet, period, and scope.
Velocity rules use recorded transaction history instead of spend-counter approximations. Hourly and
daily rules use rolling one-hour and 24-hour windows; weekly and monthly transaction-count rules use
UTC calendar periods. Count-based rules accept an optional `scope`: the default `WALLET` counts all
of the wallet's transactions in the window, while `RECIPIENT` counts only transactions to the
current recipient address, which limits rapid repeated payments to one counterparty without
counting unrelated activity. Wallet execution also counts other executing payment reservations that have
not produced a transaction record yet, and card authorization counts approved or executing
reservations, so concurrent requests cannot pass by observing the same stale count. If required
history or the rule configuration is unavailable, the payment fails closed.
For Conto-managed wallets, the full policy set is evaluated again immediately before custody
dispatch. A new denial stops execution and releases the reservation. If policy evaluation is
unavailable, execution fails closed and no funds are moved.
For new organization-controlled managed wallets, Conto executes as a separate additional signer
after those same policy and approval checks. EVM signing also has a provider-level stablecoin and
per-transaction baseline policy. The customer root owner can authorize actions or key export outside
Conto, so application policy is not a cryptographic restriction on the owner path. Use a
contract-enforced wallet when every possible transfer must require the governed path. See [Custody
Modes](https://conto.finance/guides/custody-modes).
Info:
Address sanctions screening is active by default and uses maintained compliance data. A sanctions
match can deny a payment even when every configured policy would otherwise allow it.
| Outcome | Condition |
| --------------------- | -------------------------------------------------------------- |
| **DENIED** | Any check denies |
| **REQUIRES_APPROVAL** | No denial, and at least one rule or workflow requires approval |
| **APPROVED** | All checks pass |
### Counterparty lifecycle and agent controls
Counterparty lifecycle state and per-agent relationship controls are evaluated independently:
- A counterparty can move through `DISCOVERED`, `PENDING_REVIEW`, `APPROVED`, `TRUSTED`,
`MONITORED`, `QUARANTINED`, and `BLOCKED`.
- `DISCOVERED`, `PENDING_REVIEW`, `MONITORED`, and `QUARANTINED` route payments to approval.
- `BLOCKED` denies the payment.
- Each agent-to-counterparty relationship can add stricter per-payment, daily, and monthly limits,
require approval, restrict categories, or expire at a specific time.
Approving a counterparty globally does not remove a stricter agent-specific approval requirement.
An expired relationship returns the payment to review.
### Evaluation Semantics
Policy rules use simple AND logic. Every active organization policy and every active policy assigned
to the selected agent, wallet, or card is evaluated once, and every rule inside those policies must
pass unless it is a `DENY` or `REQUIRE_APPROVAL` trigger that does not match.
| Action | Meaning |
| ------------------ | ---------------------------------------------------------------------------------------------------------- |
| `ALLOW` | The condition describes what is permitted. If the condition does not match, the payment is denied. |
| `DENY` | The condition describes what is blocked. If the condition matches, the payment is denied. |
| `REQUIRE_APPROVAL` | The condition describes what needs review. If it matches and no DENY fires, the payment requires approval. |
`priority` is sort order, not override precedence. A higher-priority `ALLOW` cannot override a
lower-priority deny or a failed allowlist. Use one wider allowlist rule when you need
alternatives, not two competing policies.
For a hands-on walkthrough of how evaluation works, see the [Policy Testing guide](https://conto.finance/guides/policy-testing).
## Creating Policies
### Via Dashboard
Go to **Policies** in the sidebar and click **Create Policy**.
| Field | Description | |-------|-------------| | Name | Human-readable name | | Type | Policy
type (spend limit, time window, etc.) | | Priority | 0-100 (higher = evaluated first, but never
overrides a failing rule) | | Scope | Entire organization or only assigned targets | |
Description | What this policy does |
Define the specific rules for this policy.
For assigned scope, link the policy to agents, wallets, or cards.
### Via API
```bash
curl -X POST https://conto.finance/api/policies \
-H "Authorization: Bearer $CONTO_ORG_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Daily Spend Limit",
"description": "Limits daily spending to $1000",
"policyType": "SPEND_LIMIT",
"scope": "organization",
"priority": 50,
"isActive": true
}'
```
## Policy Properties
| Property | Type | Description |
| ------------- | ------- | ------------------------------------------------- |
| `name` | string | Human-readable name |
| `description` | string | Detailed description |
| `policyType` | enum | Type of policy |
| `scope` | enum | `organization` baseline or `assigned` targets |
| `priority` | number | Evaluation order (0-100), not override precedence |
| `isActive` | boolean | Whether policy is enforced |
| `rules` | array | Specific rules for this policy |
## Assigning Policies
Policies can be assigned to:
- **Agents** - Apply to specific agents
- **Wallets** - Apply to specific wallets
- **Cards** - Apply to specific cards
Only policies with `scope: "assigned"` can be assigned. Organization policies apply automatically.
### Assign to Agent
```bash
curl -X POST https://conto.finance/api/agents/{agentId}/policies \
-H "Authorization: Bearer $CONTO_ORG_API_KEY" \
-d '{
"policyId": "cmm5c0pol000l49h7dmsuc11p"
}'
```
## Example: Standard Agent Setup
A typical agent configuration with multiple policies:
```json
[
{
"name": "Spend Limits",
"policyType": "SPEND_LIMIT",
"priority": 50,
"rules": [
{ "ruleType": "MAX_AMOUNT", "operator": "LTE", "value": "200", "action": "ALLOW" },
{ "ruleType": "DAILY_LIMIT", "operator": "LTE", "value": "1000", "action": "ALLOW" },
{ "ruleType": "MONTHLY_LIMIT", "operator": "LTE", "value": "10000", "action": "ALLOW" }
]
},
{
"name": "Business Hours",
"policyType": "TIME_WINDOW",
"priority": 50,
"rules": [
{
"ruleType": "TIME_WINDOW",
"operator": "BETWEEN",
"value": "{\"start\": \"09:00\", \"end\": \"18:00\", \"timezone\": \"America/Los_Angeles\"}",
"action": "ALLOW"
},
{
"ruleType": "DAY_OF_WEEK",
"operator": "IN",
"value": {
"days": ["Mon", "Tue", "Wed", "Thu", "Fri"],
"timezone": "America/Los_Angeles"
},
"action": "ALLOW"
}
]
},
{
"name": "Trusted Vendors Only",
"policyType": "COUNTERPARTY",
"priority": 50,
"rules": [{ "ruleType": "TRUST_SCORE", "operator": "GTE", "value": "0.6", "action": "ALLOW" }]
}
]
```
## Best Practices
Create policies at different priority levels to keep evaluation order easy to understand:
- **HIGH (90-100)**: Security/Compliance (sanctions, blocked addresses)
- **MEDIUM (40-60)**: Business Rules (limits, time windows)
- **LOW (0-20)**: Defaults (catch-all rules)
Priority changes evaluation order only. It does not let an allow rule override a stricter rule
that runs later.
Begin with strict policies and relax based on operational needs. Recommended starting limits for new agents: $100/tx, $500/day, $5,000/month.
- Day 1: $100/day limit, 3 trusted vendors
- Week 2: $500/day, add 5 more vendors
- Month 2: $1,000/day, category-based restrictions
Note: Auto-created wallet defaults are higher (daily: $1,000, weekly: $5,000, monthly: $20,000). Override these with policy-level limits for tighter control.
Don't block high-value transactions entirely - require approval:
```json
{
"policyType": "APPROVAL_THRESHOLD",
"rules": [
{ "ruleType": "REQUIRE_APPROVAL_ABOVE", "operator": "GREATER_THAN", "value": "500", "action": "REQUIRE_APPROVAL" }
]
}
```
Use descriptions to explain policy intent:
```json
{
"name": "OFAC Compliance",
"description": "Blocks transactions to OFAC-sanctioned countries. Required for regulatory compliance. Do not modify without legal approval."
}
```
## Available Rule Types
The value formats and operators for rule types live in [Advanced Policies](https://conto.finance/policies/advanced). Quick index:
| Category | Rule Types |
| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Spend limits](https://conto.finance/policies/advanced#supported-rule-types) | `MAX_AMOUNT`, `DAILY_LIMIT`, `WEEKLY_LIMIT`, `MONTHLY_LIMIT`, `BUDGET_CAP` |
| [Time controls](https://conto.finance/policies/advanced#supported-rule-types) | `TIME_WINDOW`, `DAY_OF_WEEK`, `DATE_RANGE`, `BLACKOUT_PERIOD` (aliases: `MAINTENANCE_WINDOW`, `BLOCKED_TIME_WINDOW`) |
| [Counterparty & address](https://conto.finance/policies/advanced#supported-rule-types) | `ALLOWED_COUNTERPARTIES`, `BLOCKED_COUNTERPARTIES`, `TRUST_SCORE`, `COUNTERPARTY_STATUS` |
| [Category & contract](https://conto.finance/policies/advanced#contract-allowlist) | `ALLOWED_CATEGORIES`, `BLOCKED_CATEGORIES`, `CONTRACT_ALLOWLIST` (aliases: `ALLOWED_CONTRACTS`, `PROTOCOL_ALLOWLIST`) |
| [Geographic & compliance](https://conto.finance/policies/advanced#geographic-restrictions-ofac) | `GEOGRAPHIC_RESTRICTION`, sanctions screening, jurisdiction checks |
| [x402 protocol](https://conto.finance/policies/advanced#x402-protocol-rules) | `X402_MAX_PER_REQUEST`, `X402_PRICE_CEILING`, `X402_MAX_PER_ENDPOINT`, `X402_MAX_PER_SERVICE`, `X402_ALLOWED_SERVICES`, `X402_BLOCKED_SERVICES`, `X402_ALLOWED_FACILITATORS`, `X402_VELOCITY_PER_ENDPOINT`, `X402_SESSION_BUDGET` |
| [MPP protocol](https://conto.finance/policies/advanced#mpp-protocol-rules) | `MPP_MAX_PER_REQUEST`, `MPP_PRICE_CEILING`, `MPP_MAX_PER_ENDPOINT`, `MPP_MAX_PER_SERVICE`, `MPP_ALLOWED_SERVICES`, `MPP_BLOCKED_SERVICES`, `MPP_VELOCITY_PER_ENDPOINT`, `MPP_SESSION_BUDGET`, `MPP_MAX_SESSION_DEPOSIT`, `MPP_MAX_CONCURRENT_SESSIONS`, `MPP_MAX_SESSION_DURATION`, `MPP_BLOCK_SESSION_INTENT` |
| [AgentScore commerce](https://conto.finance/policies/advanced#agentscore-commerce-rules) | `AGENTSCORE_REQUIRE_VERIFIED`, `AGENTSCORE_ALLOWED_JURISDICTIONS`, `AGENTSCORE_BLOCKED_JURISDICTIONS` |
## Denial Explanations
When a payment is denied, the response includes a customer-facing explanation that is safe to show
to an operator or end user:
```json
{
"status": "DENIED",
"reasons": ["This payment exceeds a configured spending limit."]
}
```
Use the dashboard's policy and wallet views when an authorized operator needs to review the
configured controls.
## Test a policy before you enable it
`POST /api/policies/simulate` replays a candidate policy against your real recent transactions and
reports what it would have decided, without saving anything. No policy is created, no approval runs,
and no money moves. Use it to see exactly which currently-allowed payments a new limit would block
before you turn it on.
```bash
curl -X POST https://conto.finance/api/policies/simulate \
-H "Authorization: Bearer $CONTO_ORG_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"candidatePolicy": {
"name": "Cap vendor payments",
"policyType": "SPEND_LIMIT",
"rules": [{ "ruleType": "MAX_AMOUNT", "operator": "LTE", "value": "500", "action": "ALLOW" }]
},
"sampleSize": 200
}'
```
The response returns a per-transaction `wouldBe` decision (`ALLOW`, `DENY`, `REQUIRE_APPROVAL`) and a
`summary` with `newlyBlocked` and `newlyAllowed` counts.
The simulation evaluates the rule types a single historical transaction fully determines (amount,
category, counterparty, agent identity, x402/MPP service). Rule types whose decision depends on
state that is not on a payment row (cumulative daily/weekly/monthly limits, velocity, live trust
scores, geography, and time-of-day windows) are not replayed and are listed under
`summary.contextDependentRuleTypes`, so the simulation never reports a decision it cannot stand
behind.
## Next Steps
### Spend Limits
Link: https://conto.finance/policies/spend-limits
Configure amount-based limits
### Time Windows
Link: https://conto.finance/policies/time-windows
Set up time-based restrictions