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 to configure where reviews are sent.

Policy Types

Spend Limit

Control maximum amounts per transaction, day, week, or month

Time Window

Restrict transactions to specific hours and days

Counterparty

Control which recipients are allowed based on trust

Geographic

OFAC sanctions screening and country restrictions, built-in and configurable

AgentScore Compliance

Require verified humans, enforce jurisdiction allowlists, and trigger identity step-up before settlement

Contract Allowlist

Restrict interactions to approved smart contracts and protocols via Contract Registry

Approval Threshold

Require manual approval above certain amounts

Agent Identity

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

Price ceilings, service allowlists, and session budget caps for x402 micropayments

MPP Controls

Session budgets, concurrency limits, and duration caps for MPP payments

Budget Allocation

Allocate budgets by department or project with period tracking

Expiration

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

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
Geographic & Sanctions: OFAC country check + address sanctions screening (always active, no policy needed)
Counterparty Trust: Pre-fetch trust level and network trust score for use in policy rules
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
Merchant Identity Gates: Optional AgentScore assess results can add verified-human, KYC, sanctions, and jurisdiction context before final settlement
Counterparty Rules: Block list, trust requirements, network intelligence
Relationship Controls: Per-agent payee limits, category allowlists, approval requirements, and temporary access expiry
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.

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.

Creating Policies

Via Dashboard

Navigate to Policies

Go to Policies in the sidebar and click Create Policy.

Configure 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 |

Add Rules

Define the specific rules for this policy.

Assign if needed

For assigned scope, link the policy to agents, wallets, or cards.

Via API

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

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:

[
  {
    "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

Layer Your Policies

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.

Start Restrictive

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.

Use Approval Thresholds

Don’t block high-value transactions entirely - require approval:

{
  "policyType": "APPROVAL_THRESHOLD",
  "rules": [
    { "ruleType": "REQUIRE_APPROVAL_ABOVE", "operator": "GREATER_THAN", "value": "500", "action": "REQUIRE_APPROVAL" }
  ]
}

Document Your Policies

Use descriptions to explain policy intent:

{
  "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. Quick index:

Category	Rule Types
Spend limits	`MAX_AMOUNT`, `DAILY_LIMIT`, `WEEKLY_LIMIT`, `MONTHLY_LIMIT`, `BUDGET_CAP`
Time controls	`TIME_WINDOW`, `DAY_OF_WEEK`, `DATE_RANGE`, `BLACKOUT_PERIOD` (aliases: `MAINTENANCE_WINDOW`, `BLOCKED_TIME_WINDOW`)
Counterparty & address	`ALLOWED_COUNTERPARTIES`, `BLOCKED_COUNTERPARTIES`, `TRUST_SCORE`, `COUNTERPARTY_STATUS`
Category & contract	`ALLOWED_CATEGORIES`, `BLOCKED_CATEGORIES`, `CONTRACT_ALLOWLIST` (aliases: `ALLOWED_CONTRACTS`, `PROTOCOL_ALLOWLIST`)
Geographic & compliance	`GEOGRAPHIC_RESTRICTION`, sanctions screening, jurisdiction checks
x402 protocol	`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	`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	`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:

{
  "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.

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.

​Policy System

​What is a Policy?

​Starter Guardrails for New Organizations

​Policy Types

Spend Limit

Time Window

Counterparty

Geographic

AgentScore Compliance

Category

Contract Allowlist

Approval Threshold

Agent Identity

Velocity

Whitelist

x402 Controls

MPP Controls

Budget Allocation

Expiration

​Policy Evaluation

​Policy scope

​Evaluation Order

​Counterparty lifecycle and agent controls

​Evaluation Semantics

​Creating Policies

​Via Dashboard

​Via API

​Policy Properties

​Assigning Policies

​Assign to Agent

​Example: Standard Agent Setup

​Best Practices

​Available Rule Types

​Denial Explanations

​Test a policy before you enable it

​Next Steps

Spend Limits

Time Windows

Policy System

What is a Policy?

Starter Guardrails for New Organizations

Policy Types

Policy Evaluation

Policy scope

Evaluation Order

Counterparty lifecycle and agent controls

Evaluation Semantics

Creating Policies

Via Dashboard

Via API

Policy Properties

Assigning Policies

Assign to Agent

Example: Standard Agent Setup

Best Practices

Available Rule Types

Denial Explanations

Test a policy before you enable it

Next Steps