Para el visto bueno

Tus agentes proponen. Tu política autoriza.
Lo demás no se ejecuta.

El despliegue no arranca sin tu firma: el agente no guarda credenciales y toda acción autorizada deja comprobante.

Para el visto bueno

Tus agentes proponen. Tu política autoriza. Lo demás no se ejecuta.

El despliegue no arranca sin tu firma: el agente no guarda credenciales y toda acción autorizada deja comprobante.

El despliegue llega a tu mesa igualmente. Quien ya lleva agentes controla este riesgo.

8,5 %de las inyecciones indirectas siguen colándose en 15 intentos, y eso contra el modelo más resistente que se ha medido
97 %de las organizaciones vulneradas que además sufrieron un incidente de IA no tenían controles de acceso a la IA en condiciones

8,5 %: OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1810 ataques en 15 intentos. 97 %: IBM, Cost of a Data Breach 2025, n = 600 organizaciones, sobre el 13 % que declaró una brecha con IA de por medio. Gráfico: encuesta global de McKinsey, «The state of AI in 2026: On the road to ROI», n = 1719, mayo-junio de 2026 (Exhibit 15).

Encuestados que trabajan en mitigar cada riesgo de IA, en %

De alto rendimiento en IAEl resto
Encuestados que trabajan en mitigar cada riesgo de IA: las de alto rendimiento en IA frente al resto
RiesgoDe alto rendimiento en IAEl resto
Acción de agente no autorizada o no intencionada45%33%
Explotación de vulnerabilidades impulsada por IA56%46%
Inexactitud53%52%
Privacidad personal33%36%
La distancia solo se abre en los riesgos de autoridad del agente. En los genéricos, ninguna.

El despliegue llega a tu mesa igualmente. Quien ya lleva agentes controla este riesgo.

8,5 %de las inyecciones indirectas siguen colándose en 15 intentos, y eso contra el modelo más resistente que se ha medido
97 %de las organizaciones vulneradas que además sufrieron un incidente de IA no tenían controles de acceso a la IA en condiciones

Encuestados que trabajan en mitigar cada riesgo de IA, en %

De alto rendimiento en IAEl resto
La distancia solo se abre en los riesgos de autoridad del agente. En los genéricos, ninguna.

8,5 %: OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1810 ataques en 15 intentos. 97 %: IBM, Cost of a Data Breach 2025, n = 600 organizaciones, sobre el 13 % que declaró una brecha con IA de por medio. Gráfico: encuesta global de McKinsey, «The state of AI in 2026: On the road to ROI», n = 1719, mayo-junio de 2026 (Exhibit 15).

Un sistema probabilístico no tiene ceros.

Tus agentes leen correos, tickets y documentos ajenos. Basta con colar una frase ahí para darles órdenes.

Da por hecho que la inyección funciona. Caer el 2 % de las veces o caer siempre da en la misma autorización.

al resumir un correoEn el mensaje va una orden invisible: reenvía lo que alcances. Los datos salen de casa. Rechazada: ninguna regla autoriza ese envío.
al leer un ticketTicket envenenado, escritura destructiva en producción. Pasa porque la credencial la lleva el agente. Retenida: quórum 2 de 2, sin reunir.
al descargar un documentoUna página descargada desvía un pago a otro beneficiario. No consta quién lo autorizó. Nadie. Retenida para dos personas con nombre.

Quien pone texto delante de un agente actúa con sus credenciales: un correo, un ticket, un PDF, una web. El canal que más crece es la descripción de herramienta. OWASP LLM01:2025: no se conoce prevención infalible de la inyección de prompts. UK NCSC, 2025-12-10: puede que no se cierre nunca como se cerró la inyección SQL.

Un sistema probabilístico no tiene ceros.

Tus agentes leen correos, tickets y documentos ajenos. Basta con colar una frase ahí para darles órdenes.

Da por hecho que la inyección funciona. Caer el 2 % de las veces o caer siempre da en la misma autorización.

al resumir un correoEn el mensaje va una orden invisible: reenvía lo que alcances. Los datos salen de casa. Rechazada: ninguna regla autoriza ese envío.
al leer un ticketTicket envenenado, escritura destructiva en producción. Pasa porque la credencial la lleva el agente. Retenida: quórum 2 de 2, sin reunir.
al descargar un documentoUna página descargada desvía un pago a otro beneficiario. No consta quién lo autorizó. Nadie. Retenida para dos personas con nombre.

Quien pone texto delante de un agente actúa con sus credenciales: un correo, un ticket, un PDF, una web. El canal que más crece es la descripción de herramienta. OWASP LLM01:2025: no se conoce prevención infalible de la inyección de prompts. UK NCSC, 2025-12-10: puede que no se cierre nunca como se cerró la inyección SQL.

La plataforma

Autorización de agentes: entre ellos y todo lo que tocan.

Nosotros no filtramos prompts. Por mucho que manipulen al agente de principio a fin, no cambiará nada: no tiene nada con lo que cambiarlo.

01 · El lado del agente

Toda acción entra como propuesta. El agente tiene una sola clave de ZIFFER y esa clave solo sirve para pedir: una propuesta con formato, contra un catálogo que defines tú.

  • Con MCP, las herramientas del agente son tu catálogo. Lo que no está en él no se puede ni formular.
  • O una llamada al SDK. O HTTPS a secas. Ni el agente, ni el modelo, ni los prompts cambian.
  • Mínimo privilegio demostrado por ausencia: en el agente no hay ninguna credencial que revisar

02 · El producto

Quien decide es una política firmada. Autorizar es la norma; retener, la excepción. Lo rutinario a velocidad de máquina; lo irreversible, en manos de dos personas con nombre.

  • Se autoriza en milisegundos si la regla dice LOW
  • Se retiene para un quórum si dice HIGH: doble autorización, y cada aprobador firma los bytes exactos que se van a ejecutar. Callar no es consentir.
  • Se rechaza por defecto si no hay regla que lo cubra. Lo desconocido nunca es LOW.

03 · El punto de ejecución

Solo se ejecuta lo que se ha autorizado. ZIFFER reemite la intención con su propia credencial, y la autorización no se puede rodear.

  • Tus sistemas solo aceptan a la identidad de ZIFFER: una credencial de alcance limitado por sistema y una pila de CloudFormation para dejarlo montado.
  • Un control que tu auditor puede probar él mismo: que lance la misma llamada saltándose ZIFFER y vea cómo falla
  • Lo autorizado y lo ejecutado son lo mismo: se recalcula en el momento de ejecutar, no se cree lo que venga en el mensaje.

04 · Evidencia

De todo lo ejecutado queda comprobante firmado. Un registro de solo adición que se ancla externamente antes de soltar una acción irreversible.

  • Firmas híbridas poscuánticas (Ed25519 + ML-DSA-65)
  • El historial no lo reescribe nadie: ni nosotros ni tu administrador
  • No repudio que tu auditor comprueba con una CLI pública, sin pisar producción

05 · La cadena de suministro de la política

Las reglas se firman fuera de línea. Publicar termina en una ceremonia de firma, no en un botón de Guardar. Ni un ZIFFER comprometido de arriba abajo podría reescribirlas.

  • Ningún componente en ejecución guarda una clave capaz de firmar una política válida: en esa ruta no hay nada que robar.
  • El motor de políticas, el KMS y el ejecutor verifican el paquete por separado y en cada lectura: quien recibe la política de otro servicio solo está confiando en ese servicio.
  • Control de cambios firmado: las épocas solo suben, de modo que volver a las reglas laxas de ayer queda rechazado

La plataforma

Autorización de agentes: entre ellos y todo lo que tocan.

No filtramos prompts. Por mucho que manipulen al agente, no cambia nada: no tiene nada.

01 · El lado del agente

Toda acción entra como propuesta. El agente tiene una sola clave de ZIFFER y solo sirve para pedir, no para actuar.

  • Con MCP, las herramientas del agente son tu catálogo. Lo que no está en él no se puede ni formular.
  • O una llamada al SDK. O HTTPS a secas. Ni el agente, ni el modelo, ni los prompts cambian.
  • Mínimo privilegio demostrado por ausencia: en el agente no hay ninguna credencial que revisar

02 · El producto

Quien decide es una política firmada. Autorizar es la norma; retener, la excepción. Lo rutinario a velocidad de máquina; lo irreversible, en manos de dos personas con nombre.

  • Se autoriza en milisegundos si la regla dice LOW
  • Se retiene para un quórum si dice HIGH: doble autorización, y cada aprobador firma los bytes exactos que se van a ejecutar. Callar no es consentir.
  • Se rechaza por defecto si no hay regla que lo cubra. Lo desconocido nunca es LOW.

03 · El punto de ejecución

Solo se ejecuta lo que se ha autorizado. ZIFFER reemite la intención con su propia credencial, y la autorización no se puede rodear.

  • Tus sistemas solo aceptan a la identidad de ZIFFER: una credencial de alcance limitado por sistema y una pila de CloudFormation para dejarlo montado.
  • Un control que tu auditor puede probar él mismo: que lance la misma llamada saltándose ZIFFER y vea cómo falla
  • Lo autorizado y lo ejecutado son lo mismo: se recalcula en el momento de ejecutar, no se cree lo que venga en el mensaje.

04 · Evidencia

De todo lo ejecutado queda comprobante firmado. Un registro de solo adición, anclado externamente.

  • Firmas híbridas poscuánticas (Ed25519 + ML-DSA-65)
  • El historial no lo reescribe nadie: ni nosotros ni tu administrador
  • No repudio que tu auditor comprueba con una CLI pública, sin pisar producción

05 · La cadena de la política

Las reglas se firman fuera de línea. Publicar termina en una ceremonia de firma, no en un botón de Guardar.

  • Ningún componente en ejecución guarda una clave capaz de firmar una política válida: en esa ruta no hay nada que robar.
  • El motor de políticas, el KMS y el ejecutor verifican el paquete por separado y en cada lectura: quien recibe la política de otro servicio solo está confiando en ese servicio.
  • Control de cambios firmado: las épocas solo suben, de modo que volver a las reglas laxas de ayer queda rechazado

Lo que le entregas al auditor

Una línea por acción. La reproducibilidad da procedencia de los resultados. Esto da procedencia de las acciones.

Lo que le entregas al auditor

Una línea por acción. La reproducibilidad da procedencia de los resultados. Esto da procedencia de las acciones.

La lista para el visto bueno

Seis propiedades. Cuatro las respalda una cláusula publicada; las otras dos, el propio diseño.

Sin credenciales en el agente

Ni en bóveda, ni intermediadas, ni de vida corta: el agente no llega a tocar un secreto. No hay nada que se pueda filtrar a una ventana de contexto.

Se impide, no se detecta

Tus sistemas solo aceptan a la identidad de ZIFFER. Quien intente rodearlo se da contra un muro, no contra un aviso en un panel.

Rechazo por defecto8.4-3 · P-4

Una acción sin regla se rechaza; no se le pone nota. Lo que no se conoce nunca es LOW.

Consentimiento explícito y atadoAC-3(2)

Doble autorización: el quórum son dos personas con nombre, y cada una firma los bytes exactos que se van a ejecutar. Quien propone no aprueba lo suyo.

Comprobantes, no registrosAU-10 · AU-3

Cada acción sale con un comprobante firmado en el KMS que ata tres cosas: la acción, las reglas que la clasificaron y las personas que la firmaron.

Un historial que nadie reescribeAU-9(3)

Registro de solo adición, anclado externamente antes de que salga una acción irreversible.

Los identificadores de cláusula existen de verdad. ZIFFER implementa una especificación abierta y cada afirmación se reproduce en tu máquina: ./tools/verify.sh --suites

La lista para el visto bueno

Seis propiedades. Cuatro las respalda una cláusula publicada; las otras dos, el propio diseño.

Sin credenciales en el agente

Ni en bóveda, ni intermediadas, ni de vida corta: el agente no llega a tocar un secreto. No hay nada que se pueda filtrar a una ventana de contexto.

Se impide, no se detecta

Tus sistemas solo aceptan a la identidad de ZIFFER. Quien intente rodearlo se da contra un muro, no contra un aviso en un panel.

Rechazo por defecto8.4-3 · P-4

Una acción sin regla se rechaza; no se le pone nota. Lo que no se conoce nunca es LOW.

Consentimiento explícito y atadoAC-3(2)

Doble autorización: el quórum son dos personas con nombre, y cada una firma los bytes exactos que se van a ejecutar. Quien propone no aprueba lo suyo.

Comprobantes, no registrosAU-10 · AU-3

Cada acción sale con un comprobante firmado en el KMS que ata tres cosas: la acción, las reglas que la clasificaron y las personas que la firmaron.

Un historial que nadie reescribeAU-9(3)

Registro de solo adición, anclado externamente antes de que salga una acción irreversible.

Los identificadores de cláusula existen de verdad. ZIFFER implementa una especificación abierta y cada afirmación se reproduce en tu máquina: ./tools/verify.sh --suites

Precios

Tres modalidades. Una pregunta: ¿y a ti quién te verifica?

En desarrollo

Standard

«¿Te verificas tú solo?»

  • ZIFFER alojado, con consolas de administración y de aprobación
  • Comprobantes firmados con una clave de firma solo tuya
  • Anclaje externo alojado y CLI para el auditor
  • Integración por MCP, SDK o HTTPS
  • La puesta en marcha arranca en 48 horas
Reservar 30 min de revisión de aprobación
En desarrollo

Assured

«¿Te verifica alguien de fuera?»

  • Dominio de verificación separado
  • Las claves de los comprobantes, en tu cuenta de la nube: ni podemos falsificarlos ni impedir que nos revoques
  • Toda firma acaba en tu registro de auditoría
Reservar 30 min de revisión de aprobación
En desarrollo

Regulated

«¿Te dice un regulador cómo custodiar las claves?»

  • Acuerdos de custodia impuestos
  • Claves en HSM bajo mandato externo
  • Para despliegues donde el mecanismo de claves ya viene dictado
Reservar 30 min de revisión de aprobación

Precios

Tres modalidades. Una pregunta: ¿y a ti quién te verifica?

En desarrollo

Standard

«¿Te verificas tú solo?»

  • ZIFFER alojado, con consolas de administración y de aprobación
  • Comprobantes firmados con una clave de firma solo tuya
  • Anclaje externo alojado y CLI para el auditor
  • Integración por MCP, SDK o HTTPS
  • La puesta en marcha arranca en 48 horas
Reservar 30 min de revisión de aprobación
En desarrollo

Assured

«¿Te verifica alguien de fuera?»

  • Dominio de verificación separado
  • Las claves de los comprobantes, en tu cuenta de la nube: ni podemos falsificarlos ni impedir que nos revoques
  • Toda firma acaba en tu registro de auditoría
Reservar 30 min de revisión de aprobación
En desarrollo

Regulated

«¿Te dice un regulador cómo custodiar las claves?»

  • Acuerdos de custodia impuestos
  • Claves en HSM bajo mandato externo
  • Para despliegues donde el mecanismo de claves ya viene dictado
Reservar 30 min de revisión de aprobación

Objeciones, contestadas

Lo que se pregunta de verdad en la reunión de aprobación.

¿No frena la aprobación humana a los agentes?

La mayor parte del día no pasa por nadie. Tus reglas autorizan lo rutinario en milisegundos y solo se retiene lo que no tiene marcha atrás. Una puerta que salta con todo se acaba aprobando por reflejo, y OWASP tiene ese reflejo por amenaza. Por eso las retenciones son pocas y llegan con la procedencia que la máquina ya tiene: quién lo propuso, sobre qué contexto y con qué consecuencia. Aquí no es todo o nada: la autoridad se gradúa, y una autorización se revoca sin tocar al agente.

¿Y esto no lo monta nuestro propio IAM?

Una credencial no es una autorización. Tu IAM dice si una identidad puede llegar a un sistema; no dice si esa acción tenía derecho a ocurrir. El bucle de decisión te lo montas en un fin de semana. Lo que no: invariantes verificadas por máquina, comprobantes con firma híbrida poscuántica, un registro anclado externamente que ni tu propio administrador reescribe y una suite pública de conformidad que lo demuestre. Si lo construyes, constrúyelo contra la especificación abierta: las suites te dirán qué le falta a tu versión.

¿Cuánto lleva integrarlo y qué le cambia al equipo de agentes?

Minutos en el lado del agente: con MCP, ZIFFER publica tu catálogo de acciones como herramientas del agente; o una llamada al SDK; o directamente HTTPS. Una sola vez por sistema protegido, una credencial de alcance limitado que solo ZIFFER usa. La puesta en marcha arranca en 48 horas. Nada cambia en tu agente, ni en el modelo, ni en el framework, ni en los prompts.

¿Y a vosotros quién os verifica?

Todavía nadie de fuera ha intentado romperlo, y preferimos escribirlo aquí a que lo descubras tú. Lo que sí puedes comprobar hoy sin contar con nosotros: la especificación abierta, la implementación de referencia bajo Apache 2.0, las suites de ataque que se reproducen en tu portátil borrando los controles de uno en uno y el archivo de riesgos residuales, que publicamos antes que las afirmaciones. Con Assured las claves de los comprobantes viven en tu cuenta de la nube: ni podemos falsificarlos ni hace falta que nos pidas permiso para revocarnos.

¿Qué me llevo de la revisión de aprobación?

Media hora. Y en vez de una presentación te llevas una nota de aprobación: las propiedades de tu despliegue puestas frente a los controles que ya tienes, la lista de acciones que retendríamos para dos personas con nombre y una muestra de la evidencia que le llegaría al auditor. Si la respuesta honesta es que no nos necesitas, eso es lo que pone en la nota.

Objeciones, contestadas

Lo que se pregunta de verdad en la reunión de aprobación.

¿No frena la aprobación humana a los agentes?

La mayor parte del día no pasa por nadie. Tus reglas autorizan lo rutinario en milisegundos y solo se retiene lo que no tiene marcha atrás. Una puerta que salta con todo se acaba aprobando por reflejo, y OWASP tiene ese reflejo por amenaza. Por eso las retenciones son pocas y llegan con la procedencia que la máquina ya tiene: quién lo propuso, sobre qué contexto y con qué consecuencia. Aquí no es todo o nada: la autoridad se gradúa, y una autorización se revoca sin tocar al agente.

¿Y esto no lo monta nuestro propio IAM?

Una credencial no es una autorización. Tu IAM dice si una identidad puede llegar a un sistema; no dice si esa acción tenía derecho a ocurrir. El bucle de decisión te lo montas en un fin de semana. Lo que no: invariantes verificadas por máquina, comprobantes con firma híbrida poscuántica, un registro anclado externamente que ni tu propio administrador reescribe y una suite pública de conformidad que lo demuestre. Si lo construyes, constrúyelo contra la especificación abierta: las suites te dirán qué le falta a tu versión.

¿Cuánto lleva integrarlo y qué le cambia al equipo de agentes?

Minutos en el lado del agente: con MCP, ZIFFER publica tu catálogo de acciones como herramientas del agente; o una llamada al SDK; o directamente HTTPS. Una sola vez por sistema protegido, una credencial de alcance limitado que solo ZIFFER usa. La puesta en marcha arranca en 48 horas. Nada cambia en tu agente, ni en el modelo, ni en el framework, ni en los prompts.

¿Y a vosotros quién os verifica?

Todavía nadie de fuera ha intentado romperlo, y preferimos escribirlo aquí a que lo descubras tú. Lo que sí puedes comprobar hoy sin contar con nosotros: la especificación abierta, la implementación de referencia bajo Apache 2.0, las suites de ataque que se reproducen en tu portátil borrando los controles de uno en uno y el archivo de riesgos residuales, que publicamos antes que las afirmaciones. Con Assured las claves de los comprobantes viven en tu cuenta de la nube: ni podemos falsificarlos ni hace falta que nos pidas permiso para revocarnos.

¿Qué me llevo de la revisión de aprobación?

Media hora. Y en vez de una presentación te llevas una nota de aprobación: las propiedades de tu despliegue puestas frente a los controles que ya tienes, la lista de acciones que retendríamos para dos personas con nombre y una muestra de la evidencia que le llegaría al auditor. Si la respuesta honesta es que no nos necesitas, eso es lo que pone en la nota.

Déjale la inteligencia. Quítale la autoridad.

La firma te la están pidiendo a ti. En media hora tienes la nota delante y decides si la firmas.

Puesta en marcha en 48 horas · especificación abierta · comprueba antes de pagar

Déjale la inteligencia. Quítale la autoridad.

La firma te la están pidiendo a ti. En media hora tienes la nota delante y decides si la firmas.

Puesta en marcha en 48 horas · especificación abierta · comprueba antes de pagar