Según su conexión, puede haber un sitio de Overturo más adecuado para usted: sus datos se almacenarían en Estados Unidos.
Soluciones
Reuniones Espacios Eventos OnboardingProgramas
Educación Sin ánimo de lucroDesarrolladores
Autorización de agentes de IA Visión general para desarrolladoresAutorización de agentes de IA · OAP v1.0
Impulsado por el Overturo Authorization Protocol (OAP) — autorización a nivel de wire para agentes de IA.
OAP es un protocolo de autorización a nivel de wire para agentes de IA. Captura qué acciones está autorizado a realizar un agente, dentro de qué límites, en nombre de quién y cómo se registra cada decisión — con un recibo firmado que sus contrapartes pueden verificar sin conexión.
¿Ya tiene una cuenta? Iniciar sesión
Los agentes actúan más allá de su alcance previsto, más allá de sus límites de valor previstos, o más allá de la trayectoria que la persona concernida esperaba — y no existe ningún protocolo a nivel de wire que diga: aquí está exactamente lo que este agente puede hacer, y cómo se registra cada decisión para el regulador que se presenta después. Sin ese wire, cada fallo de un agente se convierte a la vez en un evento de cumplimiento, una pérdida económica y un evento para la marca.
Un agente de IA comprador ejecutó un ciclo de aprovisionamiento durante la noche y comprometió a la empresa a gastos recurrentes que la persona concernida nunca aprobó. El agente actuó dentro de su alcance declarado — nada limitaba cuánto podía comprometer.
OAP evita esto con límites de valor: tope por transacción, tope acumulado diario y un máximo estricto.
Un agente de IA de preparación fiscal presentó una prórroga para el año equivocado porque realizó dos acciones consecutivas que, por separado, respetaban cada una sus límites — pero que en secuencia produjeron un estado que la persona concernida nunca pretendió. El recibo era técnicamente válido; la trayectoria no lo era.
OAP evita esto con límites de secuencia y de acción: pares de acciones prohibidas y predecesores requeridos detienen la trayectoria antes de la presentación.
Un agente de IA de planificación reservó al director ejecutivo en la conferencia de un competidor porque la solicitud coincidía con la regla permanente del agente reserva-si-el-calendario-está-libre. El agente no tenía ninguna señal de que este compromiso específico necesitara una revisión humana.
OAP evita esto con límites de acción y de escalado: clases de acción que siempre escalan, independientemente de la entrada en formato libre.
Solicite una autorización, adjunte una clave vinculada a DPoP y llame a authorize() por acción. La plataforma ejecuta una cascada de evaluación de 15 pasos y devuelve un recibo firmado.
Mantenga su autoridad de decisión existente (Open Policy Agent, AWS Cedar, reglas internas). Transmita atestaciones de cada decisión; la plataforma atestigua, firma y expone los escalados a través de una superficie de aprobación con la imagen de su marca.
Un agente le ha presentado un recibo y quiere verificarlo antes de honrar la acción. Obtenga el JWKS, llame a verifyReceipt(), bifurque según iss_role para el peso de confianza.
La promoción entre modos por clase de agente es un cambio de configuración, no una reintegración.
Decide la plataforma. Los agentes llaman a POST /api/v1/grants; la plataforma ejecuta la cascada y emite un recibo con iss_role: "authorizer" — el peso de confianza más fuerte sobre el que una contraparte puede actuar.
Úselo cuando: esté construyendo superficies de agentes completamente nuevas y quiera que la cascada (límites de tasa, comprobaciones de alcance, límites de valor, ventanas temporales, encaminamiento de escalados) se gestione por usted.
Decide su motor de políticas. Usted transmite atestaciones a POST /api/v1/oap/attestations; la plataforma atestigua, firma (iss_role: "witness"), ancla a la cadena de auditoría y expone los escalados.
Úselo cuando: ya tenga un motor de políticas en el que confíe y necesite un sustrato de auditoría a prueba de manipulaciones, paquetes de pruebas de calidad regulatoria y revocación global en menos de 30 segundos.
Dos integraciones, un solo formato wire. Cambie entre los modos para ver qué cambia en el wire y qué permanece igual — el mismo recibo JWS, la misma cadena de auditoría, el mismo paquete de pruebas; solo cambia quién ejecuta la decisión.
El servidor de su aplicación transmite la intención del agente. La cascada de 15 pasos ejecuta las comprobaciones de tasa, alcance, valor, tiempo y escalado, y luego emite un recibo con iss role authorizer — el peso de confianza más fuerte sobre el que una contraparte puede actuar.
Su motor de políticas existente (OPA, Cedar, reglas internas) ejecuta la decisión. Usted transmite la decisión como una atestación. La plataforma refrenda con iss role witness, ancla la cadena de auditoría y expone los escalados. Aporte su propia lógica de decisión; obtenga pruebas a prueba de manipulaciones.
Diseñado para la EU AI Act, las leyes estatales de EE. UU. sobre IA, el RGPD y la CCPA
Cada decisión de Oversight llega con una base jurídica declarada. La plataforma las ensambla en un paquete de pruebas vinculado a la EU AI Act y al RGPD — serializado de forma determinista, con hash y firmado de extremo a extremo. Los responsables de cumplimiento reciben un único artefacto que pueden entregar a un auditor sin que haya un ingeniero en la sala.
Los agentes de IA que afectan al acceso a servicios, al empleo o a obligaciones financieras suelen entrar en la clasificación de sistema de IA de alto riesgo de la EU AI Act (Anexo III) — y en marcos estadounidenses paralelos: decisiones consecuentes de la Colorado AI Act (en vigor desde febrero de 2026), herramientas de decisión automatizada sobre el empleo de la NYC Local Law 144, reglamentos California ADMT conforme a la CPRA, y las categorías de decisión de alto riesgo del NIST AI Risk Management Framework. OAP proporciona las obligaciones subyacentes — mantenimiento de registros, supervisión humana y registro de la gestión de la calidad — como comportamiento de la plataforma en lugar de desarrollo a medida, independientemente del marco según el cual se le evalúe.
Un paquete por período de notificación. Cuatro secciones, cada una vinculada a una cita regulatoria específica para que un revisor pueda navegar directamente al artículo que está evaluando. El paquete se canoniza, se le aplica hash SHA-256 y la plataforma lo firma con Ed25519 — verificable de forma independiente frente al JWKS publicado.
RGPD Artículo 30 — Registro de las actividades de tratamiento
El registro completo de las categorías de tratamiento, las bases jurídicas invocadas, los destinatarios y los plazos de conservación que el artículo 30 del RGPD obliga a mantener a un responsable del tratamiento.
EU AI Act Artículo 14 — Supervisión humana
Prueba de que se ofreció y se ejerció una revisión con la persona en el bucle. Cada escalado, aprobación, denegación y contrapropuesta se captura con la identidad de la persona concernida y la decisión.
EU AI Act Artículo 17 — Registro
La cronología completa de las decisiones tomadas por su sistema de IA, con garantías de integridad criptográfica para que el regulador pueda confiar en el propio registro.
RGPD Artículo 22 — Decisiones automatizadas
Marcador por decisión para el tratamiento exclusivamente automatizado más una vía del lado de la persona concernida para invocar la revisión humana conforme al artículo 22(3).
Cada atestación lleva una de las seis bases jurídicas del artículo 6 del RGPD. El conjunto está cerrado en la frontera de la API — una atestación que carece de una legal_basis válida se rechaza antes incluso de registrarse. No hay ninguna decisión sin etiquetar que justificar después.
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)
El panel del operador de Oversight elabora un histograma de 30 días del uso de la base jurídica por clase de agente. Cuando legitimate_interests supera el 95 % de las decisiones, aparece automáticamente un aviso de Evaluación del interés legítimo — tratamos una dependencia excesiva como una señal de cumplimiento digna de mención.
La propia vista de autorizaciones de la persona concernida, en /oap/grants/:id, incluye la base jurídica, el recibo firmado y el anclaje de la cadena de auditoría para cada acción, con exportación a CSV y JSON.
Las solicitudes de acceso de los interesados pasan por una canalización dedicada con el plazo legal de 30 días rastreado desde la recepción. Las tareas de recordatorio se activan a 14 y 7 días restantes, de modo que el plazo no se desvía. Los registros de las actividades de tratamiento se generan bajo demanda y se exportan en un formato listo para el regulador.
RGPD
UE / EEE / R. U.
CCPA
California
Sanidad
Starter sectorial
SOC 2
Starter de controles
DIATF
Identidad digital R. U.
Para los despliegues en EE. UU., la plataforma entrega hoy los bloques CCPA, BIPA (datos biométricos de Illinois) y COPPA; el starter de SOC 2 proporciona la estructura de los controles. Configuraciones de base jurídica adicionales cubren LGPD (Brasil), POPIA (Sudáfrica) y PDPA (Singapur). Las guías de implementación para el NIST AI Risk Management Framework e ISO/IEC 42001 están en la documentación para desarrolladores.
En desarrollo: paquetes sectoriales para HIPAA, PCI-DSS, FINRA, FedRAMP, NIS2 y DORA. Háblenos de su huella regulatoria específica.
Conservación configurable. Los paquetes de pruebas y los registros de la cadena se conservan durante una ventana por aplicación de entre 1 y 3650 días. El valor predeterminado es 365. Su equipo de cumplimiento fija el valor una vez; la plataforma lo aplica.
A prueba de manipulaciones por construcción
El registro de auditoría está encadenado por hash, anclado cada 15 minutos y refrendado por testigos externos. Un auditor no tiene que confiar ni en el operador ni en la plataforma — la prueba de integridad es independiente de ambos.
Cada registro lleva el hash del registro anterior
Las decisiones de autorización, atestaciones, escalados y revocaciones se ensamblan en una cadena de hash SHA-256. Modificar cualquier registro pasado rompe cada eslabón posterior.
Anclado cada 15 minutos
La raíz de la cadena se calcula y se persiste como un registro de anclaje con un rango de secuencia. Esta es la unidad que firman los testigos externos.
Los testigos externos refrendan cada anclaje
Los anclajes se transmiten a testigos independientes cuyos recibos firmados se persisten junto con la cadena. Falsificar el historial requeriría una colusión entre todos ellos.
Su auditor verifica con un clic
La superficie Comply proporciona un botón Verificar cadena que recalcula los hashes de la cadena y valida cada firma de anclaje sobre la marcha. La exportación a CSV y JSON mantiene la cadena portátil sin conexión para las firmas de auditoría externas.
Tres sectores en torno a los cuales hemos diseñado tipos de restricción. Cada bloque describe el flujo de trabajo, las restricciones en juego, la contraparte y la regulación — para que pueda ver si esta es la forma del problema en su hoja de ruta.
Asistentes de reserva para pacientes que deben respetar los horarios de los médicos, las ventanas de medicación y las reglas de guardia.
Un asistente de IA de planificación recibe las solicitudes de los pacientes a través del portal de un proveedor y reserva citas en un panel de médicos. El asistente lee la disponibilidad desde la historia clínica electrónica, propone un horario y registra la cita a través de la API de reservas. Tres restricciones se interponen entre el asistente y la historia clínica: los límites de tiempo impiden la reserva fuera del horario laboral publicado de un médico e impiden el solapamiento con las ventanas de administración de medicamentos ya en el calendario; los límites de acción impiden que el asistente reprograme citas marcadas como visitas de procedimiento sin un coordinador implicado; los límites de escalado encaminan una solicitud que implica a un médico actualmente de guardia de urgencias a un planificador humano antes de cualquier confirmación. El motor de políticas dentro del stack del proveedor de la historia clínica evalúa cada decisión y envía una atestación a Overturo, que la atestigua y devuelve un recibo firmado que la historia conserva junto con el registro de la cita. Cada reserva que realiza el asistente es posteriormente verificable de extremo a extremo frente a las claves de firma publicadas por Overturo, de modo que el equipo de cumplimiento del proveedor puede reproducir cualquier decisión sobre la que un regulador haga preguntas.
| Modo | Oversight |
|---|---|
| Restricciones utilizadas | tiempo, acción, escalado |
| Contraparte | Sistema de historia clínica electrónica (EHR) |
| Regulación aplicable | HIPAA |
Si esta es su situación — Sanidad — Agentes de planificación
Conciliación por lotes nocturnos entre fintechs y bancos socios bajo estrictos límites de valor y de ventana de compensación.
Un agente de IA de conciliación se ejecuta cada noche entre una fintech y su banco socio. El agente extrae el diario de liquidación del día, concilia cada línea con el libro mayor del banco e inicia transferencias correctivas para el residuo no conciliado. Se aplican tres salvaguardas a nivel de wire. Los límites de valor topan cada transferencia correctiva individual y un tope diario acumulado detiene la ejecución antes de que la exposición agregada cruce un umbral fijado por el responsable. Los límites de tiempo restringen al agente a la ventana de compensación publicada por el banco, de modo que una liquidación fuera de ventana nunca circula. Los límites de escalado encaminan cualquier partida no conciliada que supere un tamaño configurado a un responsable humano antes de que el agente pueda enviar. La cascada es el propio Conductor de Overturo — el agente presenta su acción al Conductor, el Conductor evalúa las restricciones más el stack de políticas del banco y emite un recibo firmado que el banco verifica sin conexión frente a las claves publicadas por Overturo. Cada transferencia lleva, por tanto, un artefacto de auditoría a nivel de wire que el equipo de conciliación del banco puede presentar a sus propios auditores sin reejecutar la lógica subyacente.
| Modo | Conductor |
|---|---|
| Restricciones utilizadas | valor, tiempo, escalado |
| Contraparte | API de conciliación bancaria |
| Regulación aplicable | NACHA Operating Rules + Reg E |
Si esta es su situación — Fintech — Agentes de conciliación
Compradores de IA del lado del consumidor que negocian el pago bajo topes por pedido y restricciones de confianza de los comercios.
Un asistente de compra de IA del lado del consumidor negocia el pago en nombre de un comprador en varios sitios de comercios. El comprador fija un tope por pedido, una lista de categorías que el asistente puede comprar sin confirmación y un nivel mínimo de confianza del comercio. El asistente navega, llena un carrito, aplica cualquier descuento expuesto por el comercio y presenta el carrito para el pago. Tres límites a nivel de wire rigen el paso de pago. Los límites de valor impiden que el asistente autorice un carrito que supere el tope por pedido o que añada un artículo cuyo precio supere el tope flexible de su categoría. Los límites de acción impiden la compra automática de cualquier artículo que el comercio señale como que requiere una revisión humana (bienes regulados, artículos con límite de edad, fabricaciones a medida). Los límites de reputación restringen al asistente a los comercios cuya contraparte procesadora de pagos posee actualmente una atestación PCI Level 1 activa. El Conductor de Overturo evalúa la acción del asistente; el procesador de pagos del comercio verifica el recibo resultante antes de autorizar el cargo.
| Modo | Conductor |
|---|---|
| Restricciones utilizadas | valor, acción, reputación |
| Contraparte | Procesador de pagos del comercio |
| Regulación aplicable | PCI-DSS + protección al consumidor estatal |
Si esta es su situación — Comercio electrónico — Agentes de pago
OAP es agnóstico respecto a la identidad. Usted aporta cualquier prueba de identidad del agente que su runtime ya produzca; OAP gestiona la autorización, los límites, el escalado y la auditoría.
agent_credential de una autorización OAP puede ser un SD-JWT, una W3C Verifiable Credential o un OIDC-A 1.0 ID Token. Elija el que emita su stack; la plataforma valida el formato que aporta.@overturo/mcp-authorize es un middleware listo para usar que los verifica en el proceso.Autoservicio gratuito con límites documentados.
Nivel intermedio con orientación al número de asientos.
Personalizado, basado en el volumen, desplegable con soberanía.
El precio exacto depende del volumen, la región y los requisitos de despliegue soberano. Hable con ventas para obtener un presupuesto.
Verificación autónoma de recibos — la dependencia más pequeña posible para una contraparte.
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"Transmita atestaciones desde su motor de políticas en 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", ...)
El directorio completo de SDK — @overturo/sdk, @overturo/mcp-authorize, @overturo/sdk, overturo, más un sidecar de Go para Open Policy Agent — con los comandos de instalación, los fragmentos hello-world, las formas de solicitud y las referencias de errores, está en el portal para desarrolladores tras registrarse.
Un recibo llega con la solicitud del agente — un JWS firmado que su runtime puede verificar sin conexión frente al JWKS publicado por la plataforma. El claim iss_role le indica cuánto peso dar a la decisión: mayor para los recibos de la cascada Conductor, medio para las atestaciones witness de su motor de políticas.
Instalar
npm install @overturo/verifyVerificar y bifurcar según el peso de confianza
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()
El formato wire de OAP sigue el versionado semántico. La versión wire actual es la 1.0.
Ningún cambio incompatible dentro de la serie 1.x. Una nueva versión mayor requiere una adhesión explícita mediante el encabezado de versión.
Las funciones obsoletas siguen siendo compatibles durante 12 meses a partir del anuncio.
Tras la rotación de claves, las claves de firma anteriores se honran durante 90 días, de modo que los recibos existentes siguen siendo verificables.
El versionado semántico del SDK sigue el formato wire, por lo que una versión mayor del SDK implica una versión mayor del formato wire.
Lea la política de versionado completa en la página de confianza
Un JWS firmado con Ed25519. Las contrapartes verifican la firma frente al JWKS de la plataforma y bifurcan según iss_role para elegir el peso de confianza adecuado. Carga útil decodificada de un recibo 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
}Cree una cuenta de Overturo para obtener un token de API y envíe su primera autorización en menos de quince minutos.
¿Ya tiene una cuenta? Iniciar sesión