Solutions
Meetings Venues Events OnboardingPrograms
Education NonprofitDevelopers
AI Agent Authorization Developer overviewAI Agent Authorization · OAP v1.0
Powered by the Overturo Authorization Protocol (OAP) — wire-level authorization for AI agents.
OAP is a wire-level authorization protocol for AI agents. It captures which actions an agent is allowed to take, under which bounds, on whose behalf, and how every decision is recorded — with a signed receipt your counterparties can verify offline.
Already have an account? Sign in
Agents act beyond their intended scope, beyond their intended value bounds, or beyond the trajectory the principal expected — and there is no wire-level protocol that says here is exactly what this agent may do, and how every decision is recorded for the regulator who shows up afterwards. Without that wire, every agent failure becomes a compliance event, a write-off, and a brand event at the same time.
An AI buyer agent ran a procurement loop overnight and committed the company to recurring spend the principal never signed off on. The agent acted within its declared scope — nothing bounded how much it could commit.
OAP prevents this with value bounds: per-transaction cap, daily cumulative cap, and a hard ceiling.
An AI tax-prep agent filed an extension for the wrong year because it took two consecutive actions that, taken alone, were each within its bounds — but in sequence produced a state the principal never intended. The receipt was technically valid; the trajectory was not.
OAP prevents this with sequence bounds and action bounds: prohibited action pairs and required predecessors stop the trajectory before the filing.
An AI scheduling agent booked the CEO at a competitor's conference because the request matched the agent's standing book-if-calendar-is-free rule. The agent had no signal that this specific commitment needed a human review.
OAP prevents this with action bounds and escalation bounds: classes of action that always escalate, regardless of free-form input.
Request an authorization grant, attach a DPoP-bound key, and call authorize() per action. The platform runs a 15-step evaluation cascade and returns a signed receipt.
Keep your existing decision authority (Open Policy Agent, AWS Cedar, in-house rules). Submit attestations of each decision; the platform witnesses, signs, and surfaces escalations through a branded approval surface.
An agent presented you a receipt and you want to verify it before honoring the action. Pull the JWKS, call verifyReceipt(), branch on iss_role for trust weight.
Per-agent-class promotion between modes is a configuration change, not a re-integration.
The platform decides. Agents call POST /api/v1/grants; the platform runs the cascade and issues a receipt with iss_role: "authorizer" — the strongest trust weight a counterparty can act on.
Use when: you’re building net-new agent surfaces and want the cascade (rate limits, scope checks, value bounds, time windows, escalation routing) handled for you.
Your policy engine decides. You submit attestations to POST /api/v1/oap/attestations; the platform witnesses, signs (iss_role: "witness"), anchors to the audit chain, and surfaces escalations.
Use when: you already have a policy engine you trust and need a tamper-proof audit substrate, regulator-grade evidence packages, and sub-30-second global revocation.
Two integrations, one wire format. Switch between modes to see what changes on the wire and what stays the same — same receipt JWS, same audit chain, same evidence package; only who runs the decision differs.
Your application server posts the agent intent. The 15-step cascade runs rate, scope, value, time, and escalation checks, then issues a receipt with iss role authorizer — the strongest trust weight a counterparty can act on.
Your existing policy engine (OPA, Cedar, in-house rules) runs the decision. You post the decision as an attestation. The platform co-signs with iss role witness, anchors the audit chain, and surfaces escalations. Bring your own decision logic; get tamper-proof evidence.
Built for the EU AI Act, US state AI laws, GDPR, and CCPA
Every Oversight decision arrives carrying a declared legal basis. The platform stitches them into an evidence package keyed to the EU AI Act and GDPR — deterministically serialised, hashed, and signed end to end. Compliance officers receive a single artefact they can hand to an auditor without an engineer in the room.
AI agents that affect access to services, employment, or financial obligations typically fall under the EU AI Act’s high-risk AI system classification (Annex III) — and under parallel US frameworks: Colorado AI Act consequential decisions (effective February 2026), NYC Local Law 144 automated employment decision tools, California ADMT regulations under CPRA, and the NIST AI Risk Management Framework’s high-risk decision categories. OAP delivers the underlying obligations — record-keeping, human oversight, and quality-management logging — as platform behaviour rather than custom engineering, regardless of which framework you’re evaluated under.
One bundle per reporting window. Four sections, each keyed to a specific regulatory citation so a reviewer can navigate directly to the article they’re evaluating. The bundle is canonicalised, SHA-256 hashed, and Ed25519-signed by the platform — verifiable independently against the published JWKS.
GDPR Article 30 — Records of Processing
The complete log of categories of processing, legal bases invoked, recipients, and retention periods that GDPR Article 30 obliges a controller to maintain.
EU AI Act Article 14 — Human oversight
Evidence that human-in-the-loop review was offered and exercised. Each escalation, approval, denial, and counter-proposal is captured with the principal’s identity and decision.
EU AI Act Article 17 — Logging
The full timeline of decisions made by your AI system, with cryptographic integrity guarantees so the regulator can trust the log itself.
GDPR Article 22 — Automated decisions
Per-decision marker for solely-automated processing plus a principal-side pathway to invoke human review under Article 22(3).
Every attestation carries one of the six GDPR Article 6 lawful bases. The set is closed at the API boundary — an attestation missing a valid legal_basis is rejected before it’s ever recorded. There’s no untagged decision to explain away later.
consentArt. 6(1)(a)
contractArt. 6(1)(b)
legal_obligationArt. 6(1)(c)
vital_interestsArt. 6(1)(d)
public_taskArt. 6(1)(e)
legitimate_interestsArt. 6(1)(f)
The Oversight operator dashboard rolls a 30-day histogram of legal-basis usage per agent class. When legitimate_interests exceeds 95% of decisions, a Legitimate Interests Assessment prompt surfaces automatically — we treat over-reliance as a compliance signal worth flagging.
The principal’s own grant view at /oap/grants/:id carries the legal basis, signed receipt, and audit-chain anchor for every action, with CSV and JSON export.
Data Subject Access Requests run through a dedicated pipeline with the statutory 30-day deadline tracked from receipt. Reminder jobs fire at 14 days and 7 days remaining so the deadline doesn’t slip. Records of Processing Activities are generated on demand and exported in a regulator-ready format.
GDPR
EU / EEA / UK
CCPA
California
Healthcare
Sector starter
SOC 2
Controls starter
DIATF
UK digital identity
For US deployments, the platform ships CCPA, BIPA (Illinois biometric data), and COPPA building blocks today; the SOC 2 starter provides controls scaffolding. Additional legal-basis configurations cover LGPD (Brazil), POPIA (South Africa), and PDPA (Singapore). Implementation guides for the NIST AI Risk Management Framework and ISO/IEC 42001 are in the developer documentation.
In development: sectoral packs for HIPAA, PCI-DSS, FINRA, FedRAMP, NIS2, and DORA. Talk to us about your specific regulatory footprint.
Configurable retention. Evidence packages and chain records are kept for a per-application window between 1 and 3650 days. The default is 365. Your compliance team sets the value once; the platform enforces it.
Tamper-evident by construction
The audit log is hash-chained, anchored every 15 minutes, and co-signed by external witnesses. An auditor doesn’t have to trust either the operator or the platform — the integrity proof is independent of both.
Every record carries the previous record’s hash
Authorization decisions, attestations, escalations, and revocations are stitched into a SHA-256 hash chain. Editing any past record breaks every subsequent link.
Anchored every 15 minutes
The chain root is computed and persisted as an anchor record with a sequence range. This is the unit external witnesses sign.
External witnesses co-sign each anchor
Anchors are submitted to independent witnesses whose signed receipts are persisted alongside the chain. Forging history would require collusion across all of them.
Your auditor verifies in one click
The Comply surface ships a Verify chain button that re-derives the chain hashes and validates every anchor signature in place. CSV and JSON export keep the chain offline-portable for external audit firms.
Three industries we have designed bound types around. Each block describes the workflow, the bounds in play, the counterparty, and the regulation — so you can see whether this is the shape of the problem on your roadmap.
Patient-booking assistants that must respect clinician hours, medication windows, and on-call rules.
An AI scheduling assistant takes patient requests across a provider's portal and books appointments across a panel of clinicians. The assistant reads availability from the EHR, proposes a time, and writes the appointment back through the booking API. Three constraints sit between the assistant and the EHR: time bounds prevent booking outside a clinician's published working hours and prevent overlap with medication-administration windows already on the calendar; action bounds prevent the assistant from rescheduling appointments tagged as procedure visits without a coordinator in the loop; escalation bounds force a request involving a clinician currently on emergency on-call to a human scheduler before any commit. The policy engine inside the EHR vendor's stack evaluates each decision and ships an attestation to Overturo, which witnesses it and returns a signed receipt the EHR keeps alongside the appointment record. Every booking the assistant performs is later verifiable end-to-end against Overturo's published signing keys, so the provider's compliance team can replay any decision a regulator asks about.
| Mode | Oversight |
|---|---|
| Bounds used | time, action, escalation |
| Counterparty | Electronic Health Record (EHR) system |
| Governing regulation | HIPAA |
If this is your situation — Healthcare — Scheduling agents
Nightly-batch reconciliation between fintechs and bank partners under hard value plus clearing-window bounds.
An AI reconciliation agent runs each night between a fintech and its bank partner. The agent pulls the day's settlement journal, matches each line against the bank's ledger, and initiates corrective transfers for the unmatched residue. Three guardrails apply at the wire level. Value bounds cap any individual corrective transfer and a cumulative daily ceiling stops the run before aggregate exposure crosses a controller-set threshold. Time bounds restrict the agent to the bank's published clearing window so an off-window settle never flows. Escalation bounds route any unmatched item over a configured size to a human controller before the agent may submit. The cascade is the Overturo Conductor itself — the agent presents its action to Conductor, Conductor evaluates the bounds plus the bank's policy stack, and issues a signed receipt the bank verifies offline against Overturo's published keys. Every transfer therefore carries a wire-level audit artefact the bank's reconciliation team can present to its own auditors without re-running the underlying logic.
| Mode | Conductor |
|---|---|
| Bounds used | value, time, escalation |
| Counterparty | Bank reconciliation API |
| Governing regulation | NACHA Operating Rules + Reg E |
If this is your situation — Fintech — Reconciliation agents
Consumer-side AI buyers that negotiate checkout under per-order ceilings and merchant-trust constraints.
A consumer-side AI buying assistant negotiates checkout on behalf of a shopper across multiple merchant sites. The shopper sets a per-order ceiling, a list of categories the assistant may purchase without confirmation, and a minimum merchant trust tier. The assistant browses, fills a cart, applies any discount the merchant exposes, and presents the cart for payment. Three wire-level bounds gate the payment step. Value bounds prevent the assistant from authorising a cart that exceeds the per-order ceiling or that adds an item priced above its category soft cap. Action bounds prevent automatic purchase of any item the merchant flags as requiring human review (regulated goods, age-restricted items, custom-builds). Reputation bounds restrict the assistant to merchants whose payment processor counterparty currently holds active PCI Level 1 attestation. The Overturo Conductor evaluates the assistant's action; the merchant's payment processor verifies the resulting receipt before authorising the charge.
| Mode | Conductor |
|---|---|
| Bounds used | value, action, reputation |
| Counterparty | Merchant payment processor |
| Governing regulation | PCI-DSS + state consumer protection |
If this is your situation — E-commerce — Checkout agents
OAP is identity-agnostic. You bring whichever proof of agent identity your runtime already produces; OAP handles the authorization, the bounds, the escalation, and the audit.
agent_credential can be an SD-JWT, a W3C Verifiable Credential, or an OIDC-A 1.0 ID Token. Pick whichever your stack emits; the platform validates the format you bring.@overturo/mcp-authorize is drop-in middleware that verifies them in-process.Self-serve free with documented limits.
Mid-tier with seat-count direction.
Custom, volume-based, sovereign-deployable.
Exact pricing depends on volume, region, and sovereign deployment requirements. Talk to sales for a quote.
Standalone receipt verification — the smallest possible dependency for a counterparty.
npm install @overturo/verifyimport { verifyReceipt } from "@overturo/verify"
const verified = await verifyReceipt(jwt, {
jwksUrl: "https://overturo.com/.well-known/jwks.json",
})
// verified.iss_role: "authorizer" | "witness" | "approval_url_signer"Submit attestations from your Python policy engine.
pip install overturofrom overturo_oversight import OverturoOversight
client = await OverturoOversight.create(
base_url="https://overturo.com",
token=os.environ["OVERTURO_ATTESTER_TOKEN"],
application_id=os.environ["OVERTURO_APPLICATION_ID"],
)
await client.attest(decision="allow", ...)
Full SDK directory — @overturo/sdk, @overturo/mcp-authorize, @overturo/sdk, overturo, plus a Go sidecar for Open Policy Agent — with install commands, hello-world snippets, request shapes, and error references is in the developer portal once you sign up.
A receipt arrives with the agent request -- a signed JWS your runtime can verify offline against the platform's published JWKS. The iss_role claim tells you how much weight to give the decision: stronger for receipts from the Conductor cascade, medium for witness attestations from your policy engine.
Install
npm install @overturo/verifyVerify and branch on trust weight
import { verifyReceipt } from "@overturo/verify"
const decision = await verifyReceipt(jws, { jwksUrl })
if (decision.iss_role === "authorizer") proceed()
else if (decision.iss_role === "witness") proceedWithReview()
else reject()
The OAP wire format follows semver. The current wire version is 1.0.
No breaking changes within the 1.x series. A new major version requires explicit opt-in via the version header.
Deprecated capabilities remain supported for 12 months from announcement.
After key rotation, the previous signing keys are honored for 90 days so existing receipts continue to verify.
SDK semver tracks the wire format so an SDK major version implies a wire format major version.
An Ed25519-signed JWS. Counterparties verify the signature against the platform JWKS and branch on iss_role to pick the right trust weight. Decoded payload of an authorizer (Conductor) receipt:
{
"iss": "https://overturo.com",
"iss_role": "authorizer",
"aud": "did:web:vendor.example",
"jti": "<nonce-from-authorize>",
"oap_ver": "1.0",
"grant_id": "ath_us_xxxxxxxx",
"action": "payment.send",
"scope": "payments:write",
"value": "75.00",
"currency": "USD",
"single_use": true,
"iat": 1749003262,
"exp": 1749003562
}Create an Overturo account to get an API token and ship your first grant in under fifteen minutes.
Already have an account? Sign in