You set the rules.
We enforce them.
Caps, allowlists, blocked categories, approval thresholds. Six controls checked on every payment in under 10 ms. The agent never moves outside the lines you set.
Six controls. Stacked.
Each control covers one risk. Combine them to draw a tight spending envelope around every agent in the fleet.
Per-transaction cap
The absolute ceiling on a single payment. Any transaction above this cap is blocked at the evaluation step. Useful for keeping a procurement agent away from large invoices it should not be authorized to handle.
Daily and monthly limits
Cumulative spending caps with rolling-window enforcement. The counter resets at the policy's configured timezone boundary. Limits are evaluated atomically against the in-flight transaction.
Counterparty whitelist
An allowlist of destination addresses or domains. Any transaction to a counterparty outside the whitelist is blocked. Useful for tightly-scoped agents that should only pay a known set of vendors.
Category restrictions
Restrict an agent to specific merchant categories. A data-acquisition agent can be limited to API-consumption categories, blocking attempts to pay a non-categorized counterparty.
Escalation thresholds
Above the escalation threshold, the transaction is routed for human or supervisor approval. Below the threshold, the transaction settles automatically. Two paths, one policy.
Time-of-day windows
Restrict transactions to defined business hours. Off-hours transactions are blocked or escalated based on the policy configuration. Useful for treasury operations that should not move outside compliance review windows.
Under 10 ms.
Active policies live in cache. Counters update atomically. Every payment runs the full check well under the latency budget.
The cache is invalidated atomically on every policy update. The next transaction evaluation sees the new policy. There is no propagation delay between dashboard edit and live enforcement.
Counters are protected by Redis Lua scripts so the read, the check, and the increment land as a single atomic operation. There is no race condition between concurrent transactions even at high agent fleet density.
A policy in seven lines.
Create policies through the SDK or REST. The engine starts enforcing the moment you save.
Updates take effect on the next transaction. There is no deploy step, no compile pass, no migration window. Edit the policy, the engine sees it, the next agent payment is bound by the new rules.
oris.policies.create( agent_id="agent-procurement-bot", max_per_tx=50.00, max_daily=500.00, max_monthly=5000.00, allowed_categories=["cloud_compute", "api_consumption"], counterparty_whitelist=["0xA1b2...", "0xC3d4..."], escalation_threshold=200.00, )
Update live. No deploy.
From dashboard click to enforced rule in three steps. No deploy. No propagation window.
Edit through API or dashboard
Operator updates a limit, adds a counterparty, or tightens a category. The change is staged and signed by the operator's identity.
Cache invalidation
The Redis cache for the affected agent is invalidated. Any in-flight policy evaluation completes against the old policy. New evaluations pick up the new rules.
Immediate enforcement
The next agent transaction is evaluated under the new policy. The activity log records the policy version that authorized the payment.
Keep your agents inside the lines.
Create your first policy in minutes. Every payment after that runs through the rules you set.