An autonomous agent with unrestricted access to a corporate wallet is a liability. Without spending controls, a single misconfigured prompt or a compromised API key can drain thousands of dollars in minutes. Spending policies turn that liability into a controlled instrument. They define exactly what an agent can spend, where it can send funds, and what happens when a transaction falls outside approved parameters.
Oris enforces seven rule types. The policy engine evaluates every transaction against all active rules in under 10 milliseconds. No transaction reaches the blockchain without passing every rule.
The Seven Rule Types
Rule 1: Max Per Transaction
Sets the ceiling for any single payment. An agent with a $500 per-transaction limit cannot execute a $501 transfer regardless of its remaining daily or monthly budget. This rule catches runaway loops where an agent attempts a single large purchase due to a miscalculated amount.
Example: $500 per transaction
Rule 2: Max Daily Spend
Caps the total amount an agent can spend within a rolling 24-hour window. Even if every individual transaction stays under the per-transaction limit, the daily cap prevents an agent from executing hundreds of small transactions that accumulate into a significant sum.
Example: $5,000 per day
Rule 3: Max Monthly Spend
Defines the total budget allocation for a calendar month. This rule aligns agent spending with corporate budget cycles. Finance teams set monthly allocations per agent or per agent group, and the policy engine tracks cumulative spend against the limit.
Example: $50,000 per month
Rule 4: Allowed Chains
Restricts which blockchain networks the agent can transact on. An enterprise that operates exclusively on Base and Polygon can block transactions to all other chains. This prevents agents from routing payments through networks the treasury team has not approved.
Example: Base, Polygon only
Rule 5: Allowed Counterparties
Maintains a whitelist of approved recipient addresses. The agent can only send funds to addresses on this list. New vendors or service providers must be added to the whitelist before the agent can pay them. This rule prevents agents from sending funds to unknown or unauthorized parties.
Example: 12 approved vendor addresses
Rule 6: Blocked Addresses
Maintains a blacklist of addresses the agent must never transact with. This list can include known scam addresses, sanctioned entities, or competitors. The engine checks every recipient against the blocklist before submission. Any match triggers an immediate rejection.
Example: OFAC-flagged addresses
Rule 7: Escalation Threshold
Defines the amount above which a transaction requires human approval. Transactions below the threshold execute automatically. Transactions above it enter a pending state and notify a designated approver. The agent pauses its payment workflow until the approver accepts or rejects the request.
Example: Escalate above $2,000
Evaluation Architecture
Speed matters. An agent operating in a real-time workflow cannot wait 500 milliseconds for policy evaluation. The Oris policy engine stores all active policies in Redis and evaluates incoming transactions against the full rule set in under 10 milliseconds.
| Component | Latency | Description |
|---|---|---|
| Policy cache load | < 1 ms | Active policies loaded from Redis on each request |
| Spending aggregation | < 3 ms | Daily and monthly totals queried from time-series index |
| Rule evaluation (7 rules) | < 2 ms | Sequential check against all active rules |
| Address screening | < 3 ms | Whitelist and blocklist lookup via hash set |
| Total evaluation | < 10 ms | Full policy check before chain submission |
The engine operates in fail-closed mode. If the policy service is unreachable, the transaction is rejected. No policy evaluation means no transaction. An agent will never bypass controls due to a service outage.
What Happens When a Rule Triggers
Each rule violation produces one of three outcomes depending on the rule type and the policy configuration.
Reject. The transaction is blocked. The agent receives a structured error response containing the rule that triggered, the limit value, and the attempted value. The agent can adjust its behavior and retry with a compliant amount.
Escalate. The transaction enters a pending queue. The system sends a notification to the designated approver via webhook. The approver reviews the transaction details and either approves or rejects it through the dashboard. The agent receives the outcome asynchronously.
Log. The transaction proceeds, but the system records an audit entry flagging the near-limit condition. This applies to warning thresholds set below hard limits. For example, a policy can log a warning when daily spend exceeds 80% of the daily cap, giving treasury teams early visibility before the hard limit triggers a rejection.
Policy Configuration
Policies are defined as JSON objects and applied to individual agents or agent groups through the API.
{
"policy_id": "pol_treasury_ops_2026",
"agent_group": "procurement_agents",
"rules": [
{
"type": "max_per_transaction",
"value": 500,
"currency": "USDC",
"action": "reject"
},
{
"type": "max_daily",
"value": 5000,
"currency": "USDC",
"action": "reject",
"warning_threshold": 0.8
},
{
"type": "max_monthly",
"value": 50000,
"currency": "USDC",
"action": "reject"
},
{
"type": "allowed_chains",
"chains": ["base", "polygon"],
"action": "reject"
},
{
"type": "allowed_counterparties",
"addresses": [
"0x1a2b...vendor_a",
"0x3c4d...vendor_b",
"0x5e6f...cloud_provider"
],
"action": "reject"
},
{
"type": "blocked_addresses",
"source": "ofac_consolidated",
"action": "reject"
},
{
"type": "escalation_threshold",
"value": 2000,
"currency": "USDC",
"action": "escalate",
"approver": "treasury@company.com"
}
],
"enforcement": "fail_closed",
"created_at": "2026-02-14T00:00:00Z"
}Policy updates take effect within one second. When a treasury admin modifies a rule through the dashboard or API, the updated policy is written to the database and propagated to the Redis cache. The next transaction evaluation uses the updated rule set.
Operational Scenarios
Consider a procurement agent tasked with purchasing cloud GPU instances across three providers. The enterprise applies the following policy: $500 max per transaction, $5,000 daily limit, allowed chains restricted to Base, and counterparties limited to the three provider wallet addresses.
At 09:00, the agent purchases a $400 GPU reservation from Provider A on Base. The policy engine evaluates the transaction in 7 milliseconds, finds all rules satisfied, and submits to the chain. At 09:15, the agent attempts a $600 purchase from Provider B. The per-transaction rule rejects the request. The agent receives the rejection, splits the purchase into two $300 transactions, and both succeed.
At 16:00, the agent has spent $4,800 across 14 transactions. It attempts a $300 purchase. The daily limit rule rejects the request because $4,800 + $300 exceeds the $5,000 cap. The agent logs the rejection and queues the purchase for the next day.
At no point did a human need to monitor the agent's behavior in real time. The policies enforced the enterprise's financial controls automatically, deterministically, and in under 10 milliseconds per evaluation.
Control Without Bottlenecks
Policies give enterprises full control without requiring manual approval on every transaction. Finance teams define the boundaries. Agents operate freely within those boundaries. Every transaction that falls outside the rules is caught before it reaches the chain. Every compliant transaction proceeds without delay.
The result is a system where autonomous agents can operate at machine speed while the enterprise maintains the same financial controls it applies to human employees. Define your policies, deploy your agents, and let the engine enforce the rules.
Configure spending policies for your agent fleet at useoris.xyz/platform/spending-policies.
Get started with Oris
Two minutes to set up. Full spending controls from day one.