D'après votre connexion, un site Overturo pourrait être mieux adapté — vos données seraient stockées en États-Unis.
Solutions
Réunions Lieux Événements OnboardingProgrammes
Éducation AssociationsDéveloppeurs
Autorisation des agents IA Aperçu développeurAutorisation des agents IA · OAP v1.0
Propulsé par l'Overturo Authorization Protocol (OAP) — autorisation au niveau du wire pour les agents IA.
OAP est un protocole d'autorisation au niveau du wire pour les agents IA. Il capture quelles actions un agent est autorisé à effectuer, dans quelles limites, pour le compte de qui et comment chaque décision est enregistrée — avec un reçu signé que vos contreparties peuvent vérifier hors ligne.
Vous avez déjà un compte ? Se connecter
Les agents agissent au-delà de leur portée prévue, au-delà de leurs limites de valeur prévues, ou au-delà de la trajectoire attendue par la personne concernée — et il n'existe aucun protocole au niveau du wire qui dise : voici exactement ce que cet agent peut faire, et comment chaque décision est enregistrée pour le régulateur qui se présente après. Sans ce wire, chaque défaillance d'un agent devient à la fois un événement de conformité, une perte sèche et un événement pour la marque.
Un agent IA acheteur a exécuté une boucle d'approvisionnement pendant la nuit et a engagé l'entreprise dans des dépenses récurrentes que la personne concernée n'avait jamais approuvées. L'agent a agi dans sa portée déclarée — rien ne limitait le montant qu'il pouvait engager.
OAP empêche cela avec des limites de valeur : plafond par transaction, plafond cumulé quotidien et un plafond strict.
Un agent IA de préparation fiscale a déposé une prolongation pour la mauvaise année parce qu'il a effectué deux actions consécutives qui, prises isolément, respectaient chacune ses limites — mais qui, en séquence, ont produit un état que la personne concernée n'avait jamais voulu. Le reçu était techniquement valide ; la trajectoire ne l'était pas.
OAP empêche cela avec des limites de séquence et d'action : des paires d'actions interdites et des prédécesseurs requis arrêtent la trajectoire avant le dépôt.
Un agent IA de planification a réservé le PDG à la conférence d'un concurrent parce que la demande correspondait à la règle permanente de l'agent réserve-si-le-calendrier-est-libre. L'agent n'avait aucun signal que cet engagement spécifique nécessitait une révision humaine.
OAP empêche cela avec des limites d'action et d'escalade : des classes d'action qui escaladent toujours, quelle que soit l'entrée en format libre.
Demandez une autorisation, attachez une clé liée à DPoP et appelez authorize() par action. La plateforme exécute une cascade d'évaluation en 15 étapes et renvoie un reçu signé.
Conservez votre autorité de décision existante (Open Policy Agent, AWS Cedar, règles internes). Transmettez des attestations de chaque décision ; la plateforme atteste, signe et fait remonter les escalades via une surface d'approbation aux couleurs de votre marque.
Un agent vous a présenté un reçu et vous souhaitez le vérifier avant d'honorer l'action. Récupérez le JWKS, appelez verifyReceipt(), bifurquez selon iss_role pour le poids de confiance.
La promotion entre les modes par classe d'agent est un changement de configuration, pas une réintégration.
La plateforme décide. Les agents appellent POST /api/v1/grants ; la plateforme exécute la cascade et émet un reçu avec iss_role: "authorizer" — le poids de confiance le plus fort sur lequel une contrepartie peut agir.
À utiliser quand : vous construisez des surfaces d'agents entièrement nouvelles et souhaitez que la cascade (limites de débit, contrôles de portée, limites de valeur, fenêtres temporelles, acheminement des escalades) soit gérée pour vous.
Votre moteur de règles décide. Vous transmettez des attestations à POST /api/v1/oap/attestations ; la plateforme atteste, signe (iss_role: "witness"), ancre à la chaîne d'audit et fait remonter les escalades.
À utiliser quand : vous avez déjà un moteur de règles auquel vous faites confiance et avez besoin d'un substrat d'audit infalsifiable, de dossiers de preuves de qualité réglementaire et d'une révocation mondiale en moins de 30 secondes.
Deux intégrations, un seul format wire. Passez d'un mode à l'autre pour voir ce qui change sur le wire et ce qui reste identique — même reçu JWS, même chaîne d'audit, même dossier de preuves ; seul change qui exécute la décision.
Le serveur de votre application transmet l'intention de l'agent. La cascade en 15 étapes exécute les contrôles de débit, de portée, de valeur, de temps et d'escalade, puis émet un reçu avec iss role authorizer — le poids de confiance le plus fort sur lequel une contrepartie peut agir.
Votre moteur de règles existant (OPA, Cedar, règles internes) exécute la décision. Vous transmettez la décision sous forme d'attestation. La plateforme contresigne avec iss role witness, ancre la chaîne d'audit et fait remonter les escalades. Apportez votre propre logique de décision ; obtenez des preuves infalsifiables.
Conçu pour l'EU AI Act, les lois étatiques américaines sur l'IA, le RGPD et le CCPA
Chaque décision Oversight arrive avec une base légale déclarée. La plateforme les assemble en un dossier de preuves rattaché à l'EU AI Act et au RGPD — sérialisé de manière déterministe, haché et signé de bout en bout. Les responsables de la conformité reçoivent un seul artefact qu'ils peuvent remettre à un auditeur sans qu'un ingénieur soit dans la pièce.
Les agents IA qui affectent l'accès aux services, à l'emploi ou aux obligations financières relèvent généralement de la classification de système d'IA à haut risque de l'EU AI Act (Annexe III) — et de cadres américains parallèles : décisions conséquentes du Colorado AI Act (en vigueur en février 2026), outils de décision automatisée en matière d'emploi NYC Local Law 144, réglementations California ADMT au titre du CPRA, et les catégories de décisions à haut risque du NIST AI Risk Management Framework. OAP fournit les obligations sous-jacentes — tenue de registres, supervision humaine et journalisation de la gestion de la qualité — en tant que comportement de la plateforme plutôt que développement sur mesure, quel que soit le cadre selon lequel vous êtes évalué.
Un dossier par période de reporting. Quatre sections, chacune rattachée à une citation réglementaire spécifique afin qu'un examinateur puisse naviguer directement vers l'article qu'il évalue. Le dossier est canonisé, haché avec SHA-256 et signé avec Ed25519 par la plateforme — vérifiable de manière indépendante par rapport au JWKS publié.
RGPD Article 30 — Registre des activités de traitement
Le registre complet des catégories de traitement, des bases légales invoquées, des destinataires et des durées de conservation que l'article 30 du RGPD oblige un responsable du traitement à tenir.
EU AI Act Article 14 — Supervision humaine
Preuve qu'une révision avec l'humain dans la boucle a été proposée et exercée. Chaque escalade, approbation, refus et contre-proposition est capturé avec l'identité de la personne concernée et la décision.
EU AI Act Article 17 — Journalisation
La chronologie complète des décisions prises par votre système d'IA, avec des garanties d'intégrité cryptographique afin que le régulateur puisse faire confiance au journal lui-même.
RGPD Article 22 — Décisions automatisées
Marqueur par décision pour le traitement exclusivement automatisé plus une voie côté personne concernée pour invoquer la révision humaine au titre de l'article 22(3).
Chaque attestation porte l'une des six bases légales de l'article 6 du RGPD. L'ensemble est fermé à la frontière de l'API — une attestation dépourvue d'une legal_basis valide est rejetée avant même d'être enregistrée. Il n'y a aucune décision non étiquetée à justifier par la suite.
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)
Le tableau de bord de l'opérateur Oversight établit un histogramme sur 30 jours de l'utilisation de la base légale par classe d'agent. Lorsque legitimate_interests dépasse 95 % des décisions, une invite d'Évaluation de l'intérêt légitime apparaît automatiquement — nous traitons une dépendance excessive comme un signal de conformité digne d'attention.
La propre vue des autorisations de la personne concernée, à /oap/grants/:id, comporte la base légale, le reçu signé et l'ancrage de la chaîne d'audit pour chaque action, avec export en CSV et JSON.
Les demandes d'accès des personnes concernées passent par un pipeline dédié avec le délai légal de 30 jours suivi à compter de la réception. Des tâches de rappel se déclenchent à 14 et 7 jours restants, afin que le délai ne dérape pas. Les registres des activités de traitement sont générés à la demande et exportés dans un format prêt pour le régulateur.
RGPD
UE / EEE / R.-U.
CCPA
Californie
Santé
Starter sectoriel
SOC 2
Starter de contrôles
DIATF
Identité numérique R.-U.
Pour les déploiements américains, la plateforme livre aujourd'hui les blocs CCPA, BIPA (données biométriques de l'Illinois) et COPPA ; le starter SOC 2 fournit l'ossature des contrôles. Des configurations de base légale supplémentaires couvrent LGPD (Brésil), POPIA (Afrique du Sud) et PDPA (Singapour). Les guides d'implémentation pour le NIST AI Risk Management Framework et ISO/IEC 42001 sont dans la documentation développeur.
En développement : des packs sectoriels pour HIPAA, PCI-DSS, FINRA, FedRAMP, NIS2 et DORA. Parlez-nous de votre empreinte réglementaire spécifique.
Conservation configurable. Les dossiers de preuves et les enregistrements de la chaîne sont conservés pour une fenêtre par application comprise entre 1 et 3650 jours. La valeur par défaut est 365. Votre équipe de conformité fixe la valeur une fois ; la plateforme l'applique.
Infalsifiable par construction
Le journal d'audit est chaîné par hachage, ancré toutes les 15 minutes et contresigné par des témoins externes. Un auditeur n'a à faire confiance ni à l'exploitant ni à la plateforme — la preuve d'intégrité est indépendante des deux.
Chaque enregistrement porte le hachage de l'enregistrement précédent
Les décisions d'autorisation, attestations, escalades et révocations sont assemblées en une chaîne de hachage SHA-256. Modifier un enregistrement passé brise chaque maillon suivant.
Ancré toutes les 15 minutes
La racine de la chaîne est calculée et persistée sous forme d'enregistrement d'ancrage avec une plage de séquence. C'est l'unité que les témoins externes signent.
Des témoins externes contresignent chaque ancrage
Les ancrages sont transmis à des témoins indépendants dont les reçus signés sont persistés avec la chaîne. Falsifier l'historique nécessiterait une collusion entre eux tous.
Votre auditeur vérifie en un clic
La surface Comply fournit un bouton Vérifier la chaîne qui recalcule les hachages de la chaîne et valide chaque signature d'ancrage sur place. L'export en CSV et JSON garde la chaîne portable hors ligne pour les cabinets d'audit externes.
Trois secteurs autour desquels nous avons conçu des types de contraintes. Chaque bloc décrit le flux de travail, les contraintes en jeu, la contrepartie et la réglementation — afin que vous puissiez voir si c'est la forme du problème sur votre feuille de route.
Assistants de réservation pour les patients qui doivent respecter les horaires des cliniciens, les fenêtres de médication et les règles de garde.
Un assistant IA de planification reçoit les demandes des patients via le portail d'un prestataire et réserve des rendez-vous sur un panel de cliniciens. L'assistant lit la disponibilité depuis le dossier médical électronique, propose un horaire et enregistre le rendez-vous via l'API de réservation. Trois contraintes s'interposent entre l'assistant et le dossier médical : les limites de temps empêchent la réservation en dehors des heures de travail publiées d'un clinicien et empêchent le chevauchement avec les fenêtres d'administration de médicaments déjà au calendrier ; les limites d'action empêchent l'assistant de reprogrammer des rendez-vous marqués comme visites d'intervention sans un coordinateur impliqué ; les limites d'escalade acheminent une demande impliquant un clinicien actuellement de garde d'urgence vers un planificateur humain avant toute confirmation. Le moteur de règles au sein de la stack du fournisseur du dossier médical évalue chaque décision et envoie une attestation à Overturo, qui l'atteste et renvoie un reçu signé que le dossier conserve avec l'enregistrement du rendez-vous. Chaque réservation effectuée par l'assistant est ensuite vérifiable de bout en bout par rapport aux clés de signature publiées par Overturo, de sorte que l'équipe de conformité du prestataire peut rejouer toute décision sur laquelle un régulateur pose des questions.
| Mode | Oversight |
|---|---|
| Contraintes utilisées | temps, action, escalade |
| Contrepartie | Système de dossier médical électronique (EHR) |
| Réglementation applicable | HIPAA |
Si c'est votre situation — Santé — Agents de planification
Rapprochement par lots nocturnes entre fintechs et banques partenaires sous des limites strictes de valeur et de fenêtre de compensation.
Un agent IA de rapprochement s'exécute chaque nuit entre une fintech et sa banque partenaire. L'agent récupère le journal de règlement de la journée, rapproche chaque ligne avec le grand livre de la banque et initie des transferts correctifs pour le reliquat non rapproché. Trois garde-fous s'appliquent au niveau du wire. Les limites de valeur plafonnent chaque transfert correctif individuel et un plafond quotidien cumulé arrête l'exécution avant que l'exposition agrégée ne franchisse un seuil défini par le responsable. Les limites de temps restreignent l'agent à la fenêtre de compensation publiée par la banque, de sorte qu'un règlement hors fenêtre ne circule jamais. Les limites d'escalade acheminent tout élément non rapproché dépassant une taille configurée vers un responsable humain avant que l'agent ne puisse soumettre. La cascade est le Conductor d'Overturo lui-même — l'agent présente son action au Conductor, le Conductor évalue les contraintes plus la stack de règles de la banque et émet un reçu signé que la banque vérifie hors ligne par rapport aux clés publiées par Overturo. Chaque transfert porte donc un artefact d'audit au niveau du wire que l'équipe de rapprochement de la banque peut présenter à ses propres auditeurs sans réexécuter la logique sous-jacente.
| Mode | Conductor |
|---|---|
| Contraintes utilisées | valeur, temps, escalade |
| Contrepartie | API de rapprochement bancaire |
| Réglementation applicable | NACHA Operating Rules + Reg E |
Si c'est votre situation — Fintech — Agents de rapprochement
Acheteurs IA côté consommateur qui négocient le paiement sous des plafonds par commande et des contraintes de confiance des marchands.
Un assistant d'achat IA côté consommateur négocie le paiement pour le compte d'un acheteur sur plusieurs sites de marchands. L'acheteur fixe un plafond par commande, une liste de catégories que l'assistant peut acheter sans confirmation et un niveau minimal de confiance du marchand. L'assistant navigue, remplit un panier, applique toute remise exposée par le marchand et présente le panier pour le paiement. Trois limites au niveau du wire régissent l'étape de paiement. Les limites de valeur empêchent l'assistant d'autoriser un panier qui dépasse le plafond par commande ou qui ajoute un article dont le prix dépasse le plafond souple de sa catégorie. Les limites d'action empêchent l'achat automatique de tout article que le marchand signale comme nécessitant une révision humaine (biens réglementés, articles soumis à un âge limite, fabrications sur mesure). Les limites de réputation restreignent l'assistant aux marchands dont la contrepartie processeur de paiement détient actuellement une attestation PCI Level 1 active. Le Conductor d'Overturo évalue l'action de l'assistant ; le processeur de paiement du marchand vérifie le reçu résultant avant d'autoriser le débit.
| Mode | Conductor |
|---|---|
| Contraintes utilisées | valeur, action, réputation |
| Contrepartie | Processeur de paiement du marchand |
| Réglementation applicable | PCI-DSS + protection des consommateurs étatique |
Si c'est votre situation — E-commerce — Agents de paiement
OAP est agnostique vis-à-vis de l'identité. Vous apportez la preuve d'identité de l'agent que votre runtime produit déjà ; OAP gère l'autorisation, les limites, l'escalade et l'audit.
agent_credential d'une autorisation OAP peut être un SD-JWT, une W3C Verifiable Credential ou un OIDC-A 1.0 ID Token. Choisissez celui que votre stack émet ; la plateforme valide le format que vous apportez.@overturo/mcp-authorize est un middleware prêt à l'emploi qui les vérifie en cours de processus.Libre-service gratuit avec des limites documentées.
Niveau intermédiaire avec une orientation au nombre de sièges.
Personnalisé, basé sur le volume, déployable en souveraineté.
Le tarif exact dépend du volume, de la région et des exigences de déploiement souverain. Contactez le service commercial pour un devis.
Vérification autonome des reçus — la plus petite dépendance possible pour une contrepartie.
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"Transmettez des attestations depuis votre moteur de règles 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", ...)
Le répertoire complet des SDK — @overturo/sdk, @overturo/mcp-authorize, @overturo/sdk, overturo, plus un sidecar Go pour Open Policy Agent — avec les commandes d'installation, les extraits hello-world, les formes de requête et les références d'erreurs, est dans le portail développeur après inscription.
Un reçu arrive avec la demande de l'agent — un JWS signé que votre runtime peut vérifier hors ligne par rapport au JWKS publié par la plateforme. Le claim iss_role vous indique le poids à accorder à la décision : plus fort pour les reçus issus de la cascade Conductor, moyen pour les attestations witness de votre moteur de règles.
Installer
npm install @overturo/verifyVérifier et bifurquer selon le poids de confiance
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()
Le format wire d'OAP suit le versionnage sémantique. La version wire actuelle est la 1.0.
Aucune modification incompatible au sein de la série 1.x. Une nouvelle version majeure nécessite une adhésion explicite via l'en-tête de version.
Les fonctionnalités dépréciées restent prises en charge pendant 12 mois à compter de l'annonce.
Après la rotation des clés, les clés de signature précédentes sont honorées pendant 90 jours, afin que les reçus existants continuent d'être vérifiables.
Le versionnage sémantique du SDK suit le format wire, donc une version majeure du SDK implique une version majeure du format wire.
Lisez la politique de versionnage complète sur la page de confiance
Un JWS signé avec Ed25519. Les contreparties vérifient la signature par rapport au JWKS de la plateforme et bifurquent selon iss_role pour choisir le bon poids de confiance. Charge utile décodée d'un reçu 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
}Créez un compte Overturo pour obtenir un token API et expédiez votre première autorisation en moins de quinze minutes.
Vous avez déjà un compte ? Se connecter