Policies

The agent owner sets policies for each agent. Conto checks them before the agent pays.

What is a policy?

A policy is a set of rules that decides whether a payment can proceed. Every applicable policy must pass, and the payment gets one of three outcomes:

Outcome	Condition
DENIED	Any check denies
REQUIRES_APPROVAL	No denial, and at least one rule or workflow requires approval
APPROVED	All checks pass

How policies are evaluated covers scope, evaluation order, and how rules combine. The policy rule reference lists every rule type.

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. Approval requests go to the owner’s email first. See Notification Channels to change where reviews are sent.

Policy types

The policy type groups rules in the dashboard. The rules decide the outcome.

Spend limits: per-payment, daily, weekly, and monthly caps
Time windows: allowed hours and days, and blackout periods
Counterparties: recipient allowlists, blocklists, and trust rules
Policy rule reference: every rule type, including identity, category, geographic, contract, budget, x402, and MPP rules
Policy testing: build a policy that approves, holds, and denies test payments
Version history: view, compare, and restore earlier versions of a policy

Creating policies

Via dashboard

Open the form

Go to Policies > Create Policy.

Configure the policy

Field	Description
Policy Name	A label for the policy
Priority	0 to 100. Higher runs first. Priority never overrides a failing rule
Applies to	Entire organization or Only assigned agents, wallets, or cards
Policy Type	Chooses which rule fields the form shows
Description	Optional. What this policy does

Add rules

Set the rule values for the chosen type.

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",
    "rules": [{ "ruleType": "DAILY_LIMIT", "operator": "LTE", "value": "1000", "action": "ALLOW" }],
    "policyType": "SPEND_LIMIT",
    "scope": "organization",
    "priority": 50,
    "isActive": true
  }'

In an anonymous sandbox, use the sandbox setup key as the bearer token for these policy routes and for agent-wallet spend limits. It works only on that sandbox, only until a human claims it, and never lets the agent’s SDK key change a policy.

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. When omitted, it is `organization` unless `agentIds` is set
`agentIds`	array	Agents to assign the policy to when it is created. Only valid with `assigned` scope
`priority`	number	Evaluation order (0-100), not override precedence
`isActive`	boolean	Whether policy is enforced
`rules`	array	Specific rules for this policy

Assigning policies

Assign a policy to specific agents, wallets, or 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"
  }'

Recommended setup

Keep the starter guardrails (

25 per payment,

100 per day, review above $10) until the agent has a track record. Then raise limits by giving each agent its own policies, in this order. Create each policy with "scope": "assigned" and the agent’s ID, or assign it on the agent’s Permissions tab. The starter policies still apply until you edit or unassign them, because every applicable policy must pass. The numbers below are an example for a payments agent and a separate API agent.

Cap spend. MAX_AMOUNT 50 and DAILY_LIMIT 200 deny any payment over $50 and any payment that would take the day's spend over$ 200. See Spend limits.
Send the middle band to review. REQUIRE_APPROVAL_ABOVE 25 holds payments from $25 to$ 50 on the Approvals tab of Alerts & Approvals for a person to review. The agent gets REQUIRES_APPROVAL and can poll or use webhooks to check status. Keep the threshold below MAX_AMOUNT: smaller payments go through, the middle band waits for review, and larger payments are denied. See Approval workflows.
Limit recipients. ALLOWED_COUNTERPARTIES pays only the addresses you list. To allow every recipient except known bad ones, use BLOCKED_COUNTERPARTIES instead. To also deny payees whose network score drops below 0.5, add TRUST_SCORE GTE 0.5. It still allows new payees. See Counterparty policies.
Limit hours. TIME_WINDOW 09:00 to 18:00 and DAY_OF_WEEK Mon to Fri deny overnight and weekend payments. Set a timezone on each rule over the API, or it runs in UTC. Add BLACKOUT_PERIOD for holidays and maintenance windows. See Time windows.
Give x402 spend its own agent. If the agent pays for APIs with x402, assign x402 rules only to a separate API agent, because they apply to every payment of the agents they cover. X402_MAX_PER_REQUEST 0.10 and X402_MAX_PER_SERVICE {"maxAmount": 20} cap each call at $0.10 and each service at$ 20 over a rolling 24 hours. X402_ALLOWED_SERVICES pays only the domains you list. See x402 protocol rules.
Email owners about serious alerts. Conto raises alerts on Alerts & Approvals automatically, including policy violations and x402 anomalies. On Alerts & Approvals, select Configure alerts, turn on Email owners about high-severity alerts, and set Severity to email to High and critical or Critical only. Lower severities stay in the dashboard.
Verify before you go live. Call GET /api/sdk/setup with the agent’s SDK key and check that the payment-control summary reflects the policies you assigned. Then test allow, review, and deny.

Denial explanations

When a payment is denied, the response includes a plain-language reason that can be shown to an operator or end user:

{
  "status": "DENIED",
  "reasons": ["This payment exceeds a configured spending limit."]
}

Reasons come from a fixed set, such as No usable wallet is linked to this agent. or This payee needs review before payments to it can proceed automatically. They never include rule values or policy names. See payment reasons. An authorized operator can review the configured controls in the dashboard’s policy and wallet views. Dashboard alerts for a denied payment show the full evaluation reason.

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. It creates no policy, runs no approval, and moves no money. Use it to see 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.

Get started

Integrate

Payments

Conto Commerce

Spending controls

Operate

Conto Pay

What is a policy?

Starter guardrails for new organizations

Policy types

Creating policies

Via dashboard

Via API

Policy properties

Assigning policies

Assign to agent

Recommended setup

Denial explanations

Test a policy before you enable it

​What is a policy?

​Starter guardrails for new organizations

​Policy types

​Creating policies

​Via dashboard

​Via API

​Policy properties

​Assigning policies

​Assign to agent

​Recommended setup

​Denial explanations

​Test a policy before you enable it

What is a policy?

Starter guardrails for new organizations

Policy types

Creating policies

Via dashboard

Via API

Policy properties

Assigning policies

Assign to agent

Recommended setup

Denial explanations

Test a policy before you enable it