Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getovra.com/llms.txt

Use this file to discover all available pages before exploring further.

Control is the rules layer. Two engines — Policy and Risk — co-evaluate every intent, grant, issue, redeem, and checkout. Decisions are server-side; agents cannot bypass their own rules.

​
The two engines

Policy Engine

Pure function evaluatePolicy(policy, input) → { allowed, requiresApproval, reason }. Deterministic, declarative, plan-tier-agnostic.

Risk Engine

Stateful. 5 signals (velocity, amount-anomaly, geo, session, time-anomaly). Score 0–100 with tunable thresholds for review/deny/freeze.

​
Policy: what can be expressed

Policies are JSON-serializable objects attached to an agent (one policy per agent at a time). The full schema lives in /concepts/policies — here’s the surface:
GroupFields
LimitsmaxTransactionEuros, dailyLimitEuros, weeklyLimitEuros, monthlyLimitEuros
ApprovalautoApproveLimitEuros, enforcementLevel (enforce / approve / warn)
MerchantmerchantAllowlist, merchantBlocklist, allowedMccs, blockedMccs, lockToFirstMerchant
GeoallowedCountries, blockedCountries (ISO 3166-1 alpha-2)
TimeactiveHoursStart, activeHoursEnd, timezone, allowedDays, cooldownMinutes
LifecycleexpiresAfterMinutes, expirationAction (freeze / close / notify), maxUsageCount
Required behaviorrequireIntent (sacred — never silently dropped), requireAttestation

​
Risk: signals and thresholds

SignalWhat it checksDefault weight
velocityN transactions in M minutes vs baselineHigh
amount-anomalyZ-score against historical spend mean/stddevHigh
geoNew country vs policy + history; “impossible travel”Medium
sessionUser-Agent / IP cluster anomaliesMedium
time-anomalyOutside business hours or stated active windowsLow
Score is a weighted aggregate. Thresholds are tunable per policy (5min cache):
ThresholdDefaultAction
thresholdReview70Hold for human approval
thresholdDeny85Reject the intent
thresholdFreeze95Freeze the agent (opt-in, default off)
Auto-freeze is opt-in. It will halt legitimate flows if your tolerance isn’t calibrated — recommend turning it on only after observing risk scores in production.

​
Where Control runs

intent → grant → issue → redeem → checkout
   ↑       ↑       ↑       ↑          ↑
  policy + risk evaluated at each checkpoint
Each evaluation writes a row to decision_logs with the full signal payload, the score, the reason, and the action taken. Queryable via /audit and /risk/violations.

​
Card-controls sync

When you change a policy, the system translates the relevant fields into card-issuer-native controls (MCC rules, country rules, per-tx limits) and pushes them to the underlying card. Policy is the source of truth; the card mirror is best-effort and is reconciled on every update.

​
Approval workflow

When enforcementLevel: "approve" or risk action is review, the intent enters pending_approval. Approve via: 
curl -X POST https://api.getovra.com/intents/int_.../approve \
  -H "Authorization: Bearer $OVRA_API_KEY"
Or POST /intents/:id/deny with an optional reason.

​
Quick example — read an agent’s policy

curl https://api.getovra.com/policies?agentId=ag_... \
  -H "Authorization: Bearer $OVRA_API_KEY"
Or via MCP — agents can read their policy but never modify it: 
ovra_policy { action: "get", agentId: "ag_..." }

​
Pre-built presets

policy-presets.ts ships templates for common patterns: travel-only, subscriptions, dev-tools, etc. Use them as starting points in the dashboard create flow.

​
Surfaces

SurfaceCapability
RESTGET/POST/PATCH /policies, GET /risk/violations, PATCH /risk/config
SDKpolicies.*
MCPovra_policy (read-only by design)
Dashboard/dashboard/policies, /dashboard/risk, /dashboard/agents/:id

​
Next

Policies

Full field reference with examples for each rule.

Intents

The approval-bearing primitive Control gates.

Intelligence

What Control writes — decision logs, audit, anomaly detection.

Disputes

What happens when something Control allowed turns out to be wrong.