In base alla tua connessione, potrebbe esserci un sito Overturo più adatto a te — i tuoi dati sarebbero archiviati in Stati Uniti.
Soluzioni
Riunioni Sedi Eventi OnboardingProgrammi
Istruzione No profitSviluppatori
Autorizzazione agenti IA Panoramica per sviluppatoriAutorizzazione agenti IA · OAP v1.0
Basata sull'Overturo Authorization Protocol (OAP) — autorizzazione a livello di wire per gli agenti IA.
OAP è un protocollo di autorizzazione a livello di wire per gli agenti IA. Cattura quali azioni un agente è autorizzato a compiere, entro quali vincoli, per conto di chi e come ogni decisione viene registrata — con una ricevuta firmata che le tue controparti possono verificare offline.
Hai già un account? Accedi
Gli agenti agiscono oltre l'ambito previsto, oltre i limiti di valore previsti o oltre la traiettoria che il titolare si aspettava — e non esiste un protocollo a livello di wire che dica ecco esattamente cosa può fare questo agente, e come ogni decisione viene registrata per l'ente regolatore che si presenta dopo. Senza quel wire, ogni fallimento di un agente diventa allo stesso tempo un evento di conformità, una perdita economica e un evento per il brand.
Un agente IA acquirente ha eseguito un ciclo di approvvigionamento durante la notte e ha impegnato l'azienda in una spesa ricorrente che il titolare non aveva mai approvato. L'agente ha agito entro l'ambito dichiarato — nulla limitava quanto potesse impegnare.
OAP previene questo con i limiti di valore: tetto per transazione, tetto cumulativo giornaliero e un massimale rigido.
Un agente IA per la preparazione fiscale ha presentato una proroga per l'anno sbagliato perché ha compiuto due azioni consecutive che, prese singolarmente, rientravano ciascuna nei suoi limiti — ma in sequenza hanno prodotto uno stato che il titolare non aveva mai inteso. La ricevuta era tecnicamente valida; la traiettoria no.
OAP previene questo con i limiti di sequenza e di azione: coppie di azioni vietate e predecessori richiesti fermano la traiettoria prima della presentazione.
Un agente IA per la pianificazione ha prenotato il CEO alla conferenza di un concorrente perché la richiesta corrispondeva alla regola permanente dell'agente prenota-se-il-calendario-è-libero. L'agente non aveva alcun segnale che questo specifico impegno necessitasse di una revisione umana.
OAP previene questo con i limiti di azione e di escalation: classi di azione che vanno sempre in escalation, indipendentemente dall'input in formato libero.
Richiedi una concessione di autorizzazione, allega una chiave vincolata DPoP e chiama authorize() per ogni azione. La piattaforma esegue un flusso di valutazione a 15 passaggi e restituisce una ricevuta firmata.
Mantieni la tua autorità decisionale esistente (Open Policy Agent, AWS Cedar, regole interne). Invia attestazioni di ogni decisione; la piattaforma testimonia, firma e fa emergere le escalation attraverso una superficie di approvazione personalizzata.
Un agente ti ha presentato una ricevuta e vuoi verificarla prima di onorare l'azione. Recupera il JWKS, chiama verifyReceipt(), ramifica in base a iss_role per il peso di fiducia.
La promozione tra modalità per classe di agente è una modifica di configurazione, non una re-integrazione.
Decide la piattaforma. Gli agenti chiamano POST /api/v1/grants; la piattaforma esegue il flusso ed emette una ricevuta con iss_role: "authorizer" — il peso di fiducia più forte su cui una controparte può agire.
Usala quando: stai costruendo nuove superfici per agenti e vuoi che il flusso (limiti di frequenza, controlli di ambito, limiti di valore, finestre temporali, instradamento delle escalation) sia gestito per te.
Decide il tuo motore di policy. Invii attestazioni a POST /api/v1/oap/attestations; la piattaforma testimonia, firma (iss_role: "witness"), ancora alla catena di audit e fa emergere le escalation.
Usala quando: hai già un motore di policy di cui ti fidi e ti serve un substrato di audit a prova di manomissione, pacchetti di prove di livello regolatorio e revoca globale in meno di 30 secondi.
Due integrazioni, un unico formato wire. Passa da una modalità all'altra per vedere cosa cambia sul wire e cosa rimane uguale — stessa ricevuta JWS, stessa catena di audit, stesso pacchetto di prove; cambia solo chi esegue la decisione.
Il server della tua applicazione invia l'intento dell'agente. Il flusso a 15 passaggi esegue i controlli su frequenza, ambito, valore, tempo ed escalation, quindi emette una ricevuta con iss role authorizer — il peso di fiducia più forte su cui una controparte può agire.
Il tuo motore di policy esistente (OPA, Cedar, regole interne) esegue la decisione. Tu invii la decisione come attestazione. La piattaforma controfirma con iss role witness, ancora la catena di audit e fa emergere le escalation. Porta la tua logica decisionale; ottieni prove a prova di manomissione.
Costruito per l'EU AI Act, le leggi statali USA sull'IA, il GDPR e il CCPA
Ogni decisione Oversight arriva con una base giuridica dichiarata. La piattaforma le cuce insieme in un pacchetto di prove riferito all'EU AI Act e al GDPR — serializzato in modo deterministico, sottoposto ad hashing e firmato da capo a fondo. I responsabili della conformità ricevono un unico artefatto da consegnare a un revisore senza un ingegnere nella stanza.
Gli agenti IA che incidono sull'accesso ai servizi, sull'occupazione o sugli obblighi finanziari rientrano tipicamente nella classificazione di sistema di IA ad alto rischio dell'EU AI Act (Allegato III) — e in quadri normativi statunitensi paralleli: decisioni rilevanti del Colorado AI Act (in vigore da febbraio 2026), strumenti di decisione automatizzata sull'occupazione NYC Local Law 144, regolamenti California ADMT ai sensi del CPRA, e le categorie di decisione ad alto rischio del NIST AI Risk Management Framework. OAP fornisce gli obblighi sottostanti — tenuta dei registri, sorveglianza umana e logging di gestione della qualità — come comportamento della piattaforma anziché ingegneria su misura, indipendentemente dal quadro normativo in base al quale sei valutato.
Un pacchetto per ogni periodo di rendicontazione. Quattro sezioni, ciascuna riferita a una specifica citazione normativa, così un revisore può navigare direttamente all'articolo che sta valutando. Il pacchetto è canonicalizzato, sottoposto a hash SHA-256 e firmato con Ed25519 dalla piattaforma — verificabile in modo indipendente rispetto al JWKS pubblicato.
GDPR Articolo 30 — Registri delle attività di trattamento
Il registro completo delle categorie di trattamento, delle basi giuridiche invocate, dei destinatari e dei periodi di conservazione che l'Articolo 30 del GDPR obbliga un titolare a mantenere.
EU AI Act Articolo 14 — Sorveglianza umana
Prova che la revisione con l'uomo nel ciclo è stata offerta ed esercitata. Ogni escalation, approvazione, rifiuto e controproposta è registrata con l'identità del titolare e la decisione.
EU AI Act Articolo 17 — Logging
La cronologia completa delle decisioni prese dal tuo sistema di IA, con garanzie di integrità crittografica affinché l'ente regolatore possa fidarsi del registro stesso.
GDPR Articolo 22 — Decisioni automatizzate
Marcatore per decisione per il trattamento esclusivamente automatizzato più un percorso lato titolare per invocare la revisione umana ai sensi dell'Articolo 22(3).
Ogni attestazione porta con sé una delle sei basi giuridiche dell'Articolo 6 del GDPR. L'insieme è chiuso al confine dell'API — un'attestazione priva di un legal_basis valido viene rifiutata prima ancora di essere registrata. Non c'è alcuna decisione non etichettata da giustificare in seguito.
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)
La dashboard dell'operatore Oversight calcola un istogramma a 30 giorni dell'uso della base giuridica per classe di agente. Quando legitimate_interests supera il 95% delle decisioni, compare automaticamente un avviso di Valutazione del legittimo interesse — trattiamo l'eccessivo affidamento come un segnale di conformità degno di nota.
La vista delle concessioni del titolare stesso, a /oap/grants/:id, riporta la base giuridica, la ricevuta firmata e l'ancoraggio della catena di audit per ogni azione, con esportazione in CSV e JSON.
Le richieste di accesso dell'interessato passano attraverso una pipeline dedicata con la scadenza legale di 30 giorni monitorata dalla ricezione. I processi di promemoria scattano a 14 e 7 giorni dalla scadenza, così il termine non slitta. I registri delle attività di trattamento vengono generati su richiesta ed esportati in un formato pronto per gli enti regolatori.
GDPR
UE / SEE / Regno Unito
CCPA
California
Sanità
Starter di settore
SOC 2
Starter di controlli
DIATF
Identità digitale UK
Per le distribuzioni statunitensi, la piattaforma fornisce oggi i blocchi CCPA, BIPA (dati biometrici dell'Illinois) e COPPA; lo starter SOC 2 fornisce l'impalcatura dei controlli. Ulteriori configurazioni di base giuridica coprono LGPD (Brasile), POPIA (Sudafrica) e PDPA (Singapore). Le guide all'implementazione per il NIST AI Risk Management Framework e ISO/IEC 42001 sono nella documentazione per sviluppatori.
In sviluppo: pacchetti settoriali per HIPAA, PCI-DSS, FINRA, FedRAMP, NIS2 e DORA. Parlaci della tua specifica impronta normativa.
Conservazione configurabile. I pacchetti di prove e i record della catena sono conservati per una finestra per applicazione compresa tra 1 e 3650 giorni. Il valore predefinito è 365. Il tuo team di conformità imposta il valore una volta; la piattaforma lo applica.
A prova di manomissione per costruzione
Il registro di audit è concatenato tramite hash, ancorato ogni 15 minuti e controfirmato da testimoni esterni. Un revisore non deve fidarsi né dell'operatore né della piattaforma — la prova di integrità è indipendente da entrambi.
Ogni record porta con sé l'hash del record precedente
Decisioni di autorizzazione, attestazioni, escalation e revoche sono cucite in una catena di hash SHA-256. Modificare qualsiasi record passato spezza ogni anello successivo.
Ancorato ogni 15 minuti
La radice della catena viene calcolata e persistita come record di ancoraggio con un intervallo di sequenza. Questa è l'unità che i testimoni esterni firmano.
Testimoni esterni controfirmano ogni ancoraggio
Gli ancoraggi vengono inviati a testimoni indipendenti le cui ricevute firmate sono persistite insieme alla catena. Falsificare la cronologia richiederebbe una collusione tra tutti loro.
Il tuo revisore verifica in un clic
La superficie Comply fornisce un pulsante Verifica catena che ricalcola gli hash della catena e convalida ogni firma di ancoraggio sul posto. L'esportazione in CSV e JSON mantiene la catena portatile offline per le società di revisione esterne.
Tre settori attorno a cui abbiamo progettato i tipi di vincolo. Ogni blocco descrive il flusso di lavoro, i vincoli in gioco, la controparte e la normativa — così puoi capire se questa è la forma del problema sulla tua roadmap.
Assistenti per la prenotazione dei pazienti che devono rispettare gli orari dei medici, le finestre dei farmaci e le regole di reperibilità.
Un assistente IA per la pianificazione raccoglie le richieste dei pazienti tramite il portale di un fornitore e prenota appuntamenti su un pannello di medici. L'assistente legge la disponibilità dalla cartella clinica elettronica, propone un orario e registra l'appuntamento tramite l'API di prenotazione. Tre vincoli si interpongono tra l'assistente e la cartella clinica: i limiti di tempo impediscono la prenotazione al di fuori dell'orario di lavoro pubblicato di un medico e impediscono la sovrapposizione con le finestre di somministrazione dei farmaci già in calendario; i limiti di azione impediscono all'assistente di riprogrammare appuntamenti contrassegnati come visite procedurali senza un coordinatore coinvolto; i limiti di escalation portano una richiesta che coinvolge un medico attualmente in reperibilità d'emergenza a un pianificatore umano prima di qualsiasi conferma. Il motore di policy all'interno dello stack del fornitore della cartella clinica valuta ogni decisione e invia un'attestazione a Overturo, che la testimonia e restituisce una ricevuta firmata che la cartella conserva insieme al record dell'appuntamento. Ogni prenotazione eseguita dall'assistente è successivamente verificabile da capo a fondo rispetto alle chiavi di firma pubblicate da Overturo, così il team di conformità del fornitore può rieseguire qualsiasi decisione su cui un ente regolatore faccia domande.
| Modalità | Oversight |
|---|---|
| Vincoli usati | tempo, azione, escalation |
| Controparte | Sistema di cartella clinica elettronica (EHR) |
| Normativa applicabile | HIPAA |
Se questa è la tua situazione — Sanità — Agenti di pianificazione
Riconciliazione in batch notturno tra fintech e banche partner sotto rigidi limiti di valore e di finestra di compensazione.
Un agente IA di riconciliazione viene eseguito ogni notte tra una fintech e la sua banca partner. L'agente estrae il giornale di regolamento della giornata, confronta ogni riga con il registro della banca e avvia trasferimenti correttivi per il residuo non riconciliato. Si applicano tre protezioni a livello di wire. I limiti di valore limitano ogni singolo trasferimento correttivo e un tetto giornaliero cumulativo ferma l'esecuzione prima che l'esposizione aggregata superi una soglia stabilita dal titolare. I limiti di tempo restringono l'agente alla finestra di compensazione pubblicata dalla banca, così un regolamento fuori finestra non transita mai. I limiti di escalation indirizzano qualsiasi voce non riconciliata oltre una dimensione configurata a un controllore umano prima che l'agente possa inviare. Il flusso è il Conductor di Overturo stesso — l'agente presenta la sua azione a Conductor, Conductor valuta i vincoli più lo stack di policy della banca ed emette una ricevuta firmata che la banca verifica offline rispetto alle chiavi pubblicate da Overturo. Ogni trasferimento porta quindi con sé un artefatto di audit a livello di wire che il team di riconciliazione della banca può presentare ai propri revisori senza rieseguire la logica sottostante.
| Modalità | Conductor |
|---|---|
| Vincoli usati | valore, tempo, escalation |
| Controparte | API di riconciliazione bancaria |
| Normativa applicabile | Regole operative NACHA + Reg E |
Se questa è la tua situazione — Fintech — Agenti di riconciliazione
Acquirenti IA lato consumatore che negoziano il checkout sotto massimali per ordine e vincoli di fiducia sui commercianti.
Un assistente IA di acquisto lato consumatore negozia il checkout per conto di un acquirente su più siti di commercianti. L'acquirente imposta un massimale per ordine, un elenco di categorie che l'assistente può acquistare senza conferma e un livello minimo di fiducia del commerciante. L'assistente naviga, riempie un carrello, applica qualsiasi sconto esposto dal commerciante e presenta il carrello per il pagamento. Tre vincoli a livello di wire regolano il passaggio di pagamento. I limiti di valore impediscono all'assistente di autorizzare un carrello che superi il massimale per ordine o che aggiunga un articolo con un prezzo superiore al tetto morbido della sua categoria. I limiti di azione impediscono l'acquisto automatico di qualsiasi articolo che il commerciante segnali come bisognoso di revisione umana (beni regolamentati, articoli con limiti di età, prodotti su misura). I limiti di reputazione restringono l'assistente ai commercianti il cui processore di pagamento controparte detiene attualmente un'attestazione PCI Level 1 attiva. Il Conductor di Overturo valuta l'azione dell'assistente; il processore di pagamento del commerciante verifica la ricevuta risultante prima di autorizzare l'addebito.
| Modalità | Conductor |
|---|---|
| Vincoli usati | valore, azione, reputazione |
| Controparte | Processore di pagamento del commerciante |
| Normativa applicabile | PCI-DSS + tutela del consumatore statale |
Se questa è la tua situazione — E-commerce — Agenti di checkout
OAP è agnostico rispetto all'identità. Tu porti qualunque prova di identità dell'agente il tuo runtime già produca; OAP gestisce l'autorizzazione, i vincoli, l'escalation e l'audit.
agent_credential di una concessione OAP può essere un SD-JWT, una W3C Verifiable Credential o un OIDC-A 1.0 ID Token. Scegli quello che il tuo stack emette; la piattaforma convalida il formato che porti.@overturo/mcp-authorize è un middleware pronto all'uso che le verifica in-process.Self-service gratuito con limiti documentati.
Fascia intermedia con orientamento sul numero di postazioni.
Personalizzato, basato sul volume, distribuibile in sovranità.
Il prezzo esatto dipende dal volume, dalla regione e dai requisiti di distribuzione sovrana. Parla con il commerciale per un preventivo.
Verifica autonoma delle ricevute — la dipendenza più piccola possibile per una controparte.
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"Invia attestazioni dal tuo motore di policy Python.
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", ...)
La directory completa degli SDK — @overturo/sdk, @overturo/mcp-authorize, @overturo/sdk, overturo, più un sidecar Go per Open Policy Agent — con comandi di installazione, snippet hello-world, forme delle richieste e riferimenti agli errori, è nel portale per sviluppatori dopo la registrazione.
Una ricevuta arriva con la richiesta dell'agente — un JWS firmato che il tuo runtime può verificare offline rispetto al JWKS pubblicato dalla piattaforma. Il claim iss_role ti dice quanto peso dare alla decisione: maggiore per le ricevute provenienti dal flusso Conductor, medio per le attestazioni witness del tuo motore di policy.
Installa
npm install @overturo/verifyVerifica e ramifica in base al peso di fiducia
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()
Il formato wire di OAP segue il semver. La versione wire attuale è la 1.0.
Nessuna modifica incompatibile all'interno della serie 1.x. Una nuova versione maggiore richiede un'adesione esplicita tramite l'header di versione.
Le funzionalità deprecate restano supportate per 12 mesi dall'annuncio.
Dopo la rotazione delle chiavi, le precedenti chiavi di firma sono onorate per 90 giorni, così le ricevute esistenti continuano a essere verificabili.
Il semver dell'SDK segue il formato wire, quindi una versione maggiore dell'SDK implica una versione maggiore del formato wire.
Leggi la policy completa di versioning nella pagina sulla fiducia
Un JWS firmato con Ed25519. Le controparti verificano la firma rispetto al JWKS della piattaforma e ramificano in base a iss_role per scegliere il giusto peso di fiducia. Payload decodificato di una ricevuta authorizer (Conductor):
{
"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
}Crea un account Overturo per ottenere un token API e spedire la tua prima concessione in meno di quindici minuti.
Hai già un account? Accedi