◆ El punto de control de autorización para agentes de IA

Los agentes de IA ya actúan sobre tus sistemas.
Nada se ejecuta sin tu regla.

ZIFFER comprueba cada acción con tu política y firma la decisión. Tu código la ejecuta con tu propia credencial. El agente no tiene ninguna, y ZIFFER nunca tiene la tuya.

Analiza tu proyecto, gratis →Hablemos 30 min
npx @ziffer-io/scan --code --report
01Proponer. Toda acción empieza como propuesta. El agente no tiene ninguna credencial.02Autorizar. Tu política autoriza cada acción, la retiene para tus aprobadores o la rechaza.03Ejecutar. Tu código verifica el comprobante y después ejecuta la acción con tu propia credencial.04Demostrar. Cada acción ejecutada tiene un comprobante firmado. Un tercero puede verificar el registro.05Distribuir. Firmas tus reglas con tu propia clave. ZIFFER no puede reescribirlas.

◆ El punto de control de autorización para agentes de IA

Los agentes de IA ya actúan sobre tus sistemas. Nada se ejecuta sin tu regla.

ZIFFER comprueba cada acción con tu política y firma la decisión. Tu código la ejecuta con tu propia credencial. El agente no tiene ninguna, y ZIFFER nunca tiene la tuya.

Analiza tu proyecto, gratis →Hablemos 30 min
npx @ziffer-io/scan --code --report
01Proponer. Toda acción empieza como propuesta. El agente no tiene ninguna credencial.02Autorizar. Tu política autoriza cada acción, la retiene para tus aprobadores o la rechaza.03Ejecutar. Tu código verifica el comprobante y después ejecuta la acción con tu propia credencial.04Demostrar. Cada acción ejecutada tiene un comprobante firmado. Un tercero puede verificar el registro.05Distribuir. Firmas tus reglas con tu propia clave. ZIFFER no puede reescribirlas.

◆ En 67 segundos

Mira cómo tres acciones pasan por una misma política.

Un cambio rutinario recibe un comprobante. Una transferencia inyectada de 48 000 € espera a tus aprobadores. Una acción sin regla se rechaza.

◆ En 67 segundos

Mira cómo tres acciones pasan por una misma política.

Un cambio rutinario recibe un comprobante. Una transferencia inyectada de 48 000 € espera a tus aprobadores. Una acción sin regla se rechaza.

◆ Empieza con un comando

Analiza el repositorio donde se construyen las herramientas de tu agente, o da a tu asistente de IA las herramientas de ZIFFER.

Encuentra las herramientas que tu código da a un modelo de IA, y las que no se pueden deshacer. Escribe un informe. No necesitas cuenta, y no se envía nada a ninguna parte.

npx @ziffer-io/scan --code --report

Lee la documentaciónEl código fuente en GitHub

◆ Empieza con un comando

Analiza el repositorio donde se construyen las herramientas de tu agente, o da a tu asistente de IA las herramientas de ZIFFER.

Analiza tu proyecto

Encuentra las herramientas que tu código da a un modelo de IA, y las que no se pueden deshacer. Escribe un informe. No necesitas cuenta, y no se envía nada a ninguna parte.

npx @ziffer-io/scan --code --report

Claude Code

Añade el plugin de ZIFFER y sus seis skills. Analizan tu código, integran ZIFFER en él, construyen la política, configuran su pipeline y comprueban el resultado. El plugin inicia el servidor MCP por sí mismo.

claude plugin marketplace add ziffer-hq/ziffer-sdk
claude plugin install ziffer@ziffer

Otros asistentes de IA

Pon este comando en la configuración MCP de tu asistente de IA. Da al asistente las herramientas de ZIFFER: analizar tu código, integrar el SDK, comprobar tu política y probar una decisión.

npx -y @ziffer-io/mcp

Lee la documentaciónEl código fuente en GitHub

Da por hecho que la inyección funciona. Estas son tres vías por las que llega a tu agente.

Tus agentes leen correos, tickets y documentos que no controlas. Una frase ahí se convierte en una instrucción.

Decide tu política, crea lo que crea el modelo. Un agente inyectado, uno que se equivoca y uno que se usa de forma indebida topan con la misma regla.

por un correo que resumeUn texto oculto en el mensaje le dice al agente que reenvíe todo lo que alcance. Los datos salen de tu tenant. Rechazada: ninguna regla autoriza esa acción.
por un ticket que leeUn ticket envenenado se convierte en una escritura destructiva en producción, autorizada porque el agente tiene la credencial. Retenida: el quórum 2 de 2 de esta política, no alcanzado.
por un documento que descargaUna página descargada desvía un pago a un beneficiario nuevo. Nada registra quién lo autorizó, porque no lo hizo nadie. Retenida hasta que firmen los aprobadores que nombra esta política.

Cualquiera que pueda poner texto delante de un agente puede actuar con sus credenciales: un correo, un ticket, un PDF, una página web. Las descripciones de herramientas son el canal que más crece. OWASP LLM01:2025: no se conoce ninguna prevención infalible de la inyección de prompts. UK NCSC, 2025-12-10: puede que nunca se cierre como se cerró la inyección SQL.

Da por hecho que la inyección funciona. Estas son tres vías por las que llega a tu agente.

Tus agentes leen correos, tickets y documentos que no controlas. Una frase ahí se convierte en una instrucción.

Decide tu política, crea lo que crea el modelo. Un agente inyectado, uno que se equivoca y uno que se usa de forma indebida topan con la misma regla.

por un correo que resumeUn texto oculto en el mensaje le dice al agente que reenvíe todo lo que alcance. Los datos salen de tu tenant. Rechazada: ninguna regla autoriza esa acción.
por un ticket que leeUn ticket envenenado se convierte en una escritura destructiva en producción, autorizada porque el agente tiene la credencial. Retenida: el quórum 2 de 2 de esta política, no alcanzado.
por un documento que descargaUna página descargada desvía un pago a un beneficiario nuevo. Nada registra quién lo autorizó, porque no lo hizo nadie. Retenida hasta que firmen los aprobadores que nombra esta política.

Cualquiera que pueda poner texto delante de un agente puede actuar con sus credenciales: un correo, un ticket, un PDF, una página web. Las descripciones de herramientas son el canal que más crece. OWASP LLM01:2025: no se conoce ninguna prevención infalible de la inyección de prompts. UK NCSC, 2025-12-10: puede que nunca se cierre como se cerró la inyección SQL.

8,5 %de las inyecciones indirectas siguen funcionando contra el modelo más resistente que se ha medido, en 15 intentos
97 %de las organizaciones vulneradas que sufrieron un incidente relacionado con la IA no tenían controles de acceso a la IA adecuados

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

Proporción que trabaja en mitigar cada riesgo de IA, % de encuestados

Alto rendimiento en IATodos los demás
La distancia solo aparece en los dos riesgos sobre la autoridad del agente. Los otros dos no muestran ninguna.
8,5 %de las inyecciones indirectas siguen funcionando contra el modelo más resistente que se ha medido, en 15 intentos
97 %de las organizaciones vulneradas que sufrieron un incidente relacionado con la IA no tenían controles de acceso a la IA adecuados

Proporción que trabaja en mitigar cada riesgo de IA, % de encuestados

Alto rendimiento en IATodos los demás
La distancia solo aparece en los dos riesgos sobre la autoridad del agente. Los otros dos no muestran ninguna.

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

Cómo funciona

El agente propone, tu política decide, tu código ejecuta y un comprobante firmado lo demuestra.

ZIFFER no filtra prompts. Comprueba acciones. Un agente manipulado no tiene ninguna credencial, así que no puede actuar por su cuenta.

01 · Proponer

Toda acción empieza como propuesta. El agente tiene una sola clave de ZIFFER. Esa clave puede pedir, y no puede actuar.

  • A través de MCP, un agente de código obtiene la integración. El control es la línea de verificación del SDK, en tu propio código.
  • O una llamada al SDK, o HTTPS a secas. Tu agente, tu modelo y tus prompts no cambian.
  • Mínimo privilegio que puedes demostrar: en el agente no hay ninguna credencial que un auditor pueda revisar. Por qué un agente no debe tener ninguna credencial

02 · Autorizar

Decide tu política. Autoriza las acciones rutinarias sin esperar a nadie. Retiene para tus aprobadores las acciones que nadie puede deshacer.

  • Autorizada cuando tus reglas clasifican la acción como LOW
  • Retenida para un quórum cuando tus reglas la clasifican como HIGH. Cada aprobador firma los bytes exactos que se van a ejecutar. El silencio nunca es consentimiento.
  • Rechazada por defecto cuando no existe ninguna regla

03 · Ejecutar

Tu código ejecuta. Solo ejecuta una acción después de verificar el comprobante, y solo con tu propia credencial.

  • La credencial se queda en tu herramienta. Tu código no la usará sin un comprobante que haya verificado él mismo, sin conexión, con la clave pública de ZIFFER.
  • Tu auditor puede probarlo: que llame a tu herramienta sin comprobante, o con un comprobante de otros bytes, y vea cómo tu código lo rechaza.
  • Lo autorizado es exactamente lo que se ejecutó. Tu código calcula el hash de los bytes que tiene y los compara con el comprobante. Nunca se fía del mensaje.

04 · Demostrar

Un comprobante firmado demuestra lo que se ejecutó. El registro guarda lo que leyó el agente. Nadie puede cambiarlo después.

  • Firmas híbridas poscuánticas (Ed25519 + ML-DSA-65)
  • Ni nosotros, ni tu propio administrador: nadie puede cambiar un registro una vez escrito
  • No repudio que tu auditor verifica con una CLI pública, sin acceso a producción

05 · Distribuir

Firmas tus reglas con tu propia clave. ZIFFER nunca ve esa clave. Ni siquiera un ZIFFER vulnerado puede reescribir tus reglas.

  • Ningún componente en ejecución tiene una clave capaz de producir una firma de política válida, así que en la ruta de ejecución no hay nada que valga la pena robar.
  • El motor de políticas, el KMS y el ejecutor verifican el paquete cada uno por su cuenta, en cada lectura: un servicio que recibiera la política de otro solo estaría confiando en ese otro.
  • Control de cambios: cada nueva política debe llevar un número de versión más alto, así que volver a las reglas más laxas de ayer se rechaza

Cómo funciona

El agente propone, tu política decide, tu código ejecuta y un comprobante firmado lo demuestra.

ZIFFER comprueba acciones, no prompts. Un agente manipulado no tiene ninguna credencial, así que no puede actuar por su cuenta.

01 · Proponer

Toda acción empieza como propuesta. El agente tiene una sola clave de ZIFFER. Esa clave puede pedir, y no puede actuar.

  • A través de MCP, un agente de código obtiene la integración. El control es la línea de verificación del SDK, en tu propio código.
  • O una llamada al SDK, o HTTPS a secas. Tu agente, tu modelo y tus prompts no cambian.
  • Mínimo privilegio que puedes demostrar: en el agente no hay ninguna credencial que un auditor pueda revisar. Por qué un agente no debe tener ninguna credencial

02 · Autorizar

Decide tu política. Autoriza las acciones rutinarias sin esperar a nadie. Retiene para tus aprobadores las acciones que nadie puede deshacer.

  • Autorizada cuando tus reglas clasifican la acción como LOW
  • Retenida para un quórum cuando tus reglas la clasifican como HIGH. Cada aprobador firma los bytes exactos que se van a ejecutar. El silencio nunca es consentimiento.
  • Rechazada por defecto cuando no existe ninguna regla

03 · Ejecutar

Tu código ejecuta. Solo ejecuta una acción después de verificar el comprobante, y solo con tu propia credencial.

  • La credencial se queda en tu herramienta. Tu código no la usará sin un comprobante que haya verificado él mismo, sin conexión, con la clave pública de ZIFFER.
  • Tu auditor puede probarlo: que llame a tu herramienta sin comprobante, o con un comprobante de otros bytes, y vea cómo tu código lo rechaza.
  • Lo autorizado es exactamente lo que se ejecutó. Tu código calcula el hash de los bytes que tiene y los compara con el comprobante. Nunca se fía del mensaje.

04 · Demostrar

Un comprobante firmado demuestra lo que se ejecutó. El registro guarda lo que leyó el agente.

  • Firmas híbridas poscuánticas (Ed25519 + ML-DSA-65)
  • Ni nosotros, ni tu propio administrador: nadie puede cambiar un registro una vez escrito
  • No repudio que tu auditor verifica con una CLI pública, sin acceso a producción

05 · Distribuir

Firmas tus reglas con tu propia clave. ZIFFER nunca ve esa clave.

  • Ningún componente en ejecución tiene una clave capaz de producir una firma de política válida, así que en la ruta de ejecución no hay nada que valga la pena robar.
  • El motor de políticas, el KMS y el ejecutor verifican el paquete cada uno por su cuenta, en cada lectura: un servicio que recibiera la política de otro solo estaría confiando en ese otro.
  • Control de cambios: cada nueva política debe llevar un número de versión más alto, así que volver a las reglas más laxas de ayer se rechaza

Quién tiene las claves

ZIFFER nunca tiene tus credenciales. Nunca ejecuta una acción en tus sistemas.

  • Tus credenciales se quedan en tu propio código. Tu código ejecuta una acción autorizada después de verificar el comprobante.
  • Un punto de control que también ejecuta acciones puede autorizar y ejecutar a la vez. Entonces no queda nada que lo controle.
  • Si ZIFFER fuera vulnerado, el atacante no encontraría ninguna credencial tuya.
  • El atacante no podría firmar ni reescribir tus reglas. ZIFFER nunca ve la clave que las firma.
  • Las claves de tus aprobadores nunca salen de sus propios dispositivos.
  • ZIFFER sí contacta con tus aprobadores, por correo, Slack o webhook. Un aviso lleva un enlace, nunca un botón de aprobar.
  • En la modalidad Assured, las claves de tus comprobantes están en tu propia cuenta de la nube, así que no podemos falsificar tus comprobantes.

Quién tiene las claves

ZIFFER nunca tiene tus credenciales. Nunca ejecuta una acción en tus sistemas.

  • Tus credenciales se quedan en tu propio código. Tu código ejecuta una acción autorizada después de verificar el comprobante.
  • Un punto de control que también ejecuta acciones puede autorizar y ejecutar a la vez. Entonces no queda nada que lo controle.
  • Si ZIFFER fuera vulnerado, el atacante no encontraría ninguna credencial tuya.
  • El atacante no podría firmar ni reescribir tus reglas. ZIFFER nunca ve la clave que las firma.
  • Las claves de tus aprobadores nunca salen de sus propios dispositivos.
  • ZIFFER sí contacta con tus aprobadores, por correo, Slack o webhook. Un aviso lleva un enlace, nunca un botón de aprobar.
  • En la modalidad Assured, las claves de tus comprobantes están en tu propia cuenta de la nube, así que no podemos falsificar tus comprobantes.

◆ Lo que le entregas al auditor

Cada acción tiene una línea en el registro. Cada línea muestra qué se propuso, qué decidió tu política y quién firmó.

◆ Lo que le entregas al auditor

Cada acción tiene una línea en el registro. Cada línea muestra qué se propuso, qué decidió tu política y quién firmó.

La lista para la aprobación

Seis propiedades que puedes comprobar antes de dar tu visto bueno. Cuatro de ellas citan una cláusula publicada, que se muestra bajo el título.

Cero credenciales en el agente

El agente no tiene ningún secreto, ni siquiera uno de vida corta o intermediado. Nada puede filtrarse a una ventana de contexto.

Prueba de cada acción

Su plataforma de agentes muestra lo que el agente vio. Cada comprobante ZIFFER prueba lo que tenía permitido hacer: la acción, la versión de la política, quién aprobó y la decisión.

Rechazo por defecto

8.4-3 · P-4

Una acción sin regla se rechaza, nunca se clasifica. Un riesgo desconocido nunca es LOW.

La aprobación es explícita y va ligada a la acción exacta

AC-3(2)

Doble autorización: tu política firmada fija el quórum de personas designadas, y cada una firma los bytes exactos que se van a ejecutar. Quien propone no puede aprobar su propia acción.

Un comprobante firmado por cada acción autorizada

AU-10 · AU-3

Solo una acción autorizada recibe un comprobante firmado con KMS, que ata la acción, sus reglas y las personas que firmaron. Un rechazo o una expiración deja un registro de decisión.

Un historial que nadie puede reescribir

AU-9(3)

Los registros solo se añaden, nunca se modifican. Se publican fuera de ZIFFER antes de que se ejecute una acción irreversible.

Los identificadores de cláusula son reales. ZIFFER implementa una especificación abierta con pruebas verificadas por máquina y una suite pública de conformidad. Cada afirmación se reproduce en tu máquina: ./tools/verify.sh --suites

La lista para la aprobación

Seis propiedades que puedes comprobar antes de dar tu visto bueno. Cuatro de ellas citan una cláusula publicada, que se muestra bajo el título.

Cero credenciales en el agente

El agente no tiene ningún secreto, ni siquiera uno de vida corta o intermediado. Nada puede filtrarse a una ventana de contexto.

Prueba de cada acción

Su plataforma de agentes muestra lo que el agente vio. Cada comprobante ZIFFER prueba lo que tenía permitido hacer: la acción, la versión de la política, quién aprobó y la decisión.

Rechazo por defecto

8.4-3 · P-4

Una acción sin regla se rechaza, nunca se clasifica. Un riesgo desconocido nunca es LOW.

La aprobación es explícita y va ligada a la acción exacta

AC-3(2)

Doble autorización: tu política firmada fija el quórum de personas designadas, y cada una firma los bytes exactos que se van a ejecutar. Quien propone no puede aprobar su propia acción.

Un comprobante firmado por cada acción autorizada

AU-10 · AU-3

Solo una acción autorizada recibe un comprobante firmado con KMS, que ata la acción, sus reglas y las personas que firmaron. Un rechazo o una expiración deja un registro de decisión.

Un historial que nadie puede reescribir

AU-9(3)

Los registros solo se añaden, nunca se modifican. Se publican fuera de ZIFFER antes de que se ejecute una acción irreversible.

Los identificadores de cláusula son reales. ZIFFER implementa una especificación abierta con pruebas verificadas por máquina y una suite pública de conformidad. Cada afirmación se reproduce en tu máquina: ./tools/verify.sh --suites

Precios

Tres modalidades. Se diferencian en quién tiene las claves de tus comprobantes y quién te verifica a ti.

Disponible ahora

Standard

«¿Te verificas tú mismo?»

Para quién es: equipos que ponen en producción sus primeros agentes de IA y que verifican sus propios controles.

  • ZIFFER alojado, consolas de administración y de aprobación
  • Comprobantes firmados, clave de firma por tenant
  • Anclaje externo alojado, CLI para el auditor
  • Integración por MCP, SDK o HTTPS
  • La puesta en marcha empieza en 48 horas
Hablemos 30 min →
Bajo petición

Assured

«¿Te verifica alguien independiente?»

Para quién es: empresas cuyos auditores o clientes corporativos quieren pruebas verificadas por alguien distinto del proveedor, con las claves de firma en su propia nube para que ZIFFER no pueda falsificar un comprobante.

  • La verificación se hace fuera de producción, por una parte sin ninguna credencial de producción
  • Las claves de los comprobantes en tu cuenta de la nube: no podemos falsificar tus comprobantes, y puedes revocarnos
  • Cada firma llega a tu registro de auditoría
Hablemos 30 min
Bajo petición

Regulated

«¿Un regulador dicta cómo se custodian tus claves?»

Para quién es: bancos, empresas de pagos y de salud cuyo regulador dicta cómo se custodian las claves de firma.

  • Acuerdos de custodia impuestos
  • Claves custodiadas en HSM bajo mandato externo
  • Para despliegues donde el mecanismo de claves viene prescrito
Hablemos 30 min

Lee la página de precios completa

Precios

Tres modalidades. Se diferencian en quién tiene las claves de tus comprobantes y quién te verifica a ti.

Disponible ahora

Standard

«¿Te verificas tú mismo?»

Para quién es: equipos que ponen en producción sus primeros agentes de IA y que verifican sus propios controles.

  • ZIFFER alojado, consolas de administración y de aprobación
  • Comprobantes firmados, clave de firma por tenant
  • Anclaje externo alojado, CLI para el auditor
  • Integración por MCP, SDK o HTTPS
  • La puesta en marcha empieza en 48 horas
Hablemos 30 min →
Bajo petición

Assured

«¿Te verifica alguien independiente?»

Para quién es: empresas cuyos auditores o clientes corporativos quieren pruebas verificadas por alguien distinto del proveedor, con las claves de firma en su propia nube para que ZIFFER no pueda falsificar un comprobante.

  • La verificación se hace fuera de producción, por una parte sin ninguna credencial de producción
  • Las claves de los comprobantes en tu cuenta de la nube: no podemos falsificar tus comprobantes, y puedes revocarnos
  • Cada firma llega a tu registro de auditoría
Hablemos 30 min
Bajo petición

Regulated

«¿Un regulador dicta cómo se custodian tus claves?»

Para quién es: bancos, empresas de pagos y de salud cuyo regulador dicta cómo se custodian las claves de firma.

  • Acuerdos de custodia impuestos
  • Claves custodiadas en HSM bajo mandato externo
  • Para despliegues donde el mecanismo de claves viene prescrito
Hablemos 30 min

Lee la página de precios completa

Objeciones, contestadas

Las preguntas que se harán en tu reunión de aprobación.

¿Esperar a dos personas no acaba con la velocidad del agente?

La mayor parte del día pasa sin que nadie intervenga. Solo se retienen las acciones que nadie puede deshacer, así que las retenciones son raras. Una puerta que salta con todo se aprueba por reflejo, y OWASP incluye ese reflejo como una amenaza en sí misma. Cada retención llega al aprobador con los hechos ya registrados: quién propuso la acción, qué había leído el agente y qué haría la acción. Una autorización se puede revocar sin tocar al agente.

¿Por qué no montar esto con nuestro propio IAM?

Tu IAM responde si una identidad puede llegar a un sistema. No responde si esta acción debe ocurrir. El bucle de comprobación lo montas en un fin de semana. El resto lleva más tiempo: pruebas verificadas por máquina, comprobantes firmados con firma híbrida poscuántica, un registro anclado externamente que ni tu propio administrador puede reescribir y una suite pública de conformidad que lo demuestra todo. Si lo construyes, constrúyelo según la especificación abierta. Las suites te dirán qué le falta a tu versión.

¿Cuánto lleva la integración y qué cambia para el equipo de agentes?

Minutos en el lado del agente. El código de tu herramienta añade una llamada al SDK para proponer y una línea para verificar el comprobante, y HTTPS a secas también sirve. A través de MCP, un agente de código obtiene esa integración. La credencial se queda en tu herramienta, y tu código no la usará sin un comprobante que haya verificado él mismo. La puesta en marcha empieza en 48 horas. Tu agente, tu modelo, tu framework y tus prompts no cambian.

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

Treinta minutos, y te vas con una nota de aprobación en lugar de una presentación: las propiedades de tu despliegue mapeadas a los controles que ya tienes, la lista de acciones que retendríamos para un quórum de personas designadas, y una muestra de la evidencia que recibiría un auditor. Si la respuesta honesta es que no nos necesitas, eso es lo que dice la nota.

Objeciones, contestadas

Las preguntas que se harán en tu reunión de aprobación.

¿Esperar a dos personas no acaba con la velocidad del agente?

La mayor parte del día pasa sin que nadie intervenga. Solo se retienen las acciones que nadie puede deshacer, así que las retenciones son raras. Una puerta que salta con todo se aprueba por reflejo, y OWASP incluye ese reflejo como una amenaza en sí misma. Cada retención llega al aprobador con los hechos ya registrados: quién propuso la acción, qué había leído el agente y qué haría la acción. Una autorización se puede revocar sin tocar al agente.

¿Por qué no montar esto con nuestro propio IAM?

Tu IAM responde si una identidad puede llegar a un sistema. No responde si esta acción debe ocurrir. El bucle de comprobación lo montas en un fin de semana. El resto lleva más tiempo: pruebas verificadas por máquina, comprobantes firmados con firma híbrida poscuántica, un registro anclado externamente que ni tu propio administrador puede reescribir y una suite pública de conformidad que lo demuestra todo. Si lo construyes, constrúyelo según la especificación abierta. Las suites te dirán qué le falta a tu versión.

¿Cuánto lleva la integración y qué cambia para el equipo de agentes?

Minutos en el lado del agente. El código de tu herramienta añade una llamada al SDK para proponer y una línea para verificar el comprobante, y HTTPS a secas también sirve. A través de MCP, un agente de código obtiene esa integración. La credencial se queda en tu herramienta, y tu código no la usará sin un comprobante que haya verificado él mismo. La puesta en marcha empieza en 48 horas. Tu agente, tu modelo, tu framework y tus prompts no cambian.

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

Treinta minutos, y te vas con una nota de aprobación en lugar de una presentación: las propiedades de tu despliegue mapeadas a los controles que ya tienes, la lista de acciones que retendríamos para un quórum de personas designadas, y una muestra de la evidencia que recibiría un auditor. Si la respuesta honesta es que no nos necesitas, eso es lo que dice la nota.

Tráenos el despliegue que te piden aprobar.

En media hora, te llevas la nota que firmarías.

Hablemos 30 min →

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

Tráenos el despliegue que te piden aprobar.

En media hora, te llevas la nota que firmarías.

Hablemos 30 min →

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