◆ Para responsables de IAM, seguridad de identidades y soporte
Tu agente de identidad leerá algún día un ticket envenenado.
Con ZIFFER, no puede autorizar acceso admin sobre él.
El agente lee el ticket. No autoriza el grupo. Cada alta en un grupo privilegiado, cada restablecimiento de MFA y cada cuenta nueva pasa por la regla que firmaste, o por dos aprobadores designados.
◆ Para responsables de IAM, seguridad de identidades y soporte
Tu agente de identidad leerá algún día un ticket envenenado. Con ZIFFER, no puede autorizar acceso admin sobre él.
El agente lee el ticket. No autoriza el grupo. Cada alta en un grupo privilegiado, cada restablecimiento de MFA y cada cuenta nueva pasa por la regla que firmaste, o por dos aprobadores designados.
Dónde se detuvo IAM
IAM dejó que el agente respondiera al ticket. Nunca le dejó tocar un grupo privilegiado.
El agente lee, responde, deriva y añade personas a grupos ordinarios. El alta en un grupo privilegiado, el restablecimiento de MFA de un administrador y la cuenta nueva siguen esperando a una persona designada, y IAM tiene razón: ahí es donde se pierde el dominio.
El miedo tiene nombre.
- El ticket que lee el agente lo escribe, en parte, el atacante. A finales de 2025 un equipo de investigación en seguridad escribió instrucciones en el campo de descripción de un ticket. El agente de IA de una plataforma ITSM, iniciado por un administrador, podía seguirlas con los privilegios del administrador y asignar roles a la cuenta del atacante. Investigación sobre una configuración por defecto, 2025-11; no se perdió nada.
- La versión humana ya funciona. Los atacantes «se hicieron pasar por empleados para convencer al personal de TI o del servicio de soporte de que … restableciera la contraseña del empleado y transfiriera su MFA a un dispositivo bajo su control», y «abusan de las relaciones de confianza de los servicios de soporte de TI subcontratados». Aviso conjunto AA23-320A, CISA, FBI, NCSC-UK y socios, actualizado el 2025-07-29.
- El paso de confirmación en la plataforma de agentes no es una segunda persona. En una prueba de concepto, la herramienta que creó el usuario y asignó el rol de administrador funcionaba en modo supervisado, y el atacante podía «reutilizar la misma carga de confirmación por segunda vez para autorizar la asignación del rol». La CVE se corrigió el 2025-10-30.
El miedo tiene un precio.
- «Las debilidades de identidad tuvieron un papel determinante en casi el 90 % de nuestras investigaciones.» Unit 42 Global Incident Response Report 2026, más de 750 intervenciones.
- El phishing de voz es el segundo vector inicial con un 11 %, y el primero en compromisos de la nube con un 23 %. Mandiant M-Trends 2026.
- El 68 % no distingue las acciones de los agentes de las de las personas; el 74 % dice que los agentes obtienen a menudo más acceso del que necesitan. CSA, n = 228, 2026-03.
| Qué se preguntó | Respuesta | Fuente, muestra, fecha |
|---|---|---|
| ¿Ya usas agentes de IA? | 82 % sí | SailPoint (Dimensional Research), n = 353, 2025-05 |
| ¿Tus agentes han realizado acciones no previstas? | 80 % sí | ídem |
| ¿Han engañado a tus agentes para que revelen credenciales de acceso? | 23 % sí | ídem |
| ¿Los agentes obtienen a menudo más acceso del que necesitan? | 74 % sí | CSA, encargada por Aembit, n = 228, 2026-03 |
| ¿Distingues las acciones de los agentes de las de las personas? | 68 % no | ídem |
| ¿Algún agente ha excedido los permisos previstos? | 53 % sí | CSA, encargada por Zenity, n = 445, 2026-04 |
| ¿Confías plenamente en que tu IAM puede gestionar identidades de agentes? | 18 % sí | CSA, encargada por Strata Identity, n = 285, 2026-02 |
| ¿Puedes rastrear en todas partes las acciones de los agentes hasta una persona o un sistema? | 28 % puede | ídem |
Ocho respuestas de cuatro encuestas. La encuesta de SailPoint la realiza el proveedor; cada encuesta de la CSA nombra al proveedor que la encargó.
Ocho respuestas, cuatro encuestas, un mismo patrón. El agente ya tiene el acceso, y pocos saben decir qué hizo con él.
IAM tenía razón al mantener a una persona en el alta en un grupo privilegiado. Se equivocaba al pensar que el ticket era fiable porque el agente lo había leído.
Dónde se detuvo IAM
IAM dejó que el agente respondiera al ticket. Nunca le dejó tocar un grupo privilegiado.
El agente lee, responde, deriva y añade personas a grupos ordinarios. El alta en un grupo privilegiado, el restablecimiento de MFA de un administrador y la cuenta nueva siguen esperando a una persona designada, y IAM tiene razón: ahí es donde se pierde el dominio.
El miedo tiene nombre.
- El ticket que lee el agente lo escribe, en parte, el atacante. A finales de 2025 un equipo de investigación en seguridad escribió instrucciones en el campo de descripción de un ticket. El agente de IA de una plataforma ITSM, iniciado por un administrador, podía seguirlas con los privilegios del administrador y asignar roles a la cuenta del atacante. Investigación sobre una configuración por defecto, 2025-11; no se perdió nada.
- La versión humana ya funciona. Los atacantes «se hicieron pasar por empleados para convencer al personal de TI o del servicio de soporte de que … restableciera la contraseña del empleado y transfiriera su MFA a un dispositivo bajo su control», y «abusan de las relaciones de confianza de los servicios de soporte de TI subcontratados». Aviso conjunto AA23-320A, CISA, FBI, NCSC-UK y socios, actualizado el 2025-07-29.
- El paso de confirmación en la plataforma de agentes no es una segunda persona. En una prueba de concepto, la herramienta que creó el usuario y asignó el rol de administrador funcionaba en modo supervisado, y el atacante podía «reutilizar la misma carga de confirmación por segunda vez para autorizar la asignación del rol». La CVE se corrigió el 2025-10-30.
El miedo tiene un precio.
- «Las debilidades de identidad tuvieron un papel determinante en casi el 90 % de nuestras investigaciones.» Unit 42 Global Incident Response Report 2026, más de 750 intervenciones.
- El phishing de voz es el segundo vector inicial con un 11 %, y el primero en compromisos de la nube con un 23 %. Mandiant M-Trends 2026.
- El 68 % no distingue las acciones de los agentes de las de las personas; el 74 % dice que los agentes obtienen a menudo más acceso del que necesitan. CSA, n = 228, 2026-03.
- ¿Ya usas agentes de IA?82 % síSailPoint (Dimensional Research), n = 353, 2025-05
- ¿Tus agentes han realizado acciones no previstas?80 % síídem
- ¿Han engañado a tus agentes para que revelen credenciales de acceso?23 % síídem
- ¿Los agentes obtienen a menudo más acceso del que necesitan?74 % síCSA, encargada por Aembit, n = 228, 2026-03
- ¿Distingues las acciones de los agentes de las de las personas?68 % noídem
- ¿Algún agente ha excedido los permisos previstos?53 % síCSA, encargada por Zenity, n = 445, 2026-04
- ¿Confías plenamente en que tu IAM puede gestionar identidades de agentes?18 % síCSA, encargada por Strata Identity, n = 285, 2026-02
- ¿Puedes rastrear en todas partes las acciones de los agentes hasta una persona o un sistema?28 % puedeídem
Ocho respuestas de cuatro encuestas. La encuesta de SailPoint la realiza el proveedor; cada encuesta de la CSA nombra al proveedor que la encargó.
Ocho respuestas, cuatro encuestas, un mismo patrón. El agente ya tiene el acceso, y pocos saben decir qué hizo con él.
IAM tenía razón al mantener a una persona en el alta en un grupo privilegiado. Se equivocaba al pensar que el ticket era fiable porque el agente lo había leído.
La pieza que falta
Quita la autorización de las manos del agente. Déjale el ticket.
El agente lee, responde, deriva y propone. Ahí termina su función. Quién entra en qué grupo lo decide una regla que firmaste antes del turno, y dos aprobadores designados para cualquier grupo privilegiado, cualquier restablecimiento de MFA de una cuenta privilegiada, cualquier cuenta de emergencia.
El ticket se queda con el agente. La autoridad vive en tu conector, sobre un comprobante. ZIFFER no tiene ninguna credencial del IdP, del directorio ni del PAM.
- regla
- Clase del grupo, clase de la cuenta, caducidad, días desde la creación de la cuenta, quién puede firmar. Un grupo que la regla no nombra está en el nivel más alto. Una acción que la regla no nombra se rechaza.
- quórum
- Dos aprobadores designados, passkeys y un resumen generado a partir de los bytes firmados de la propuesta: cuenta, grupo, caducidad, ticket de cambio presente o no. Quien propone nunca cuenta.
- comprobante
- Firmado, verificado sin conexión por tu conector antes de la llamada al IdP. ZIFFER no tiene ninguna credencial del IdP, del directorio ni del PAM.
El agente lee el ticket. No autoriza el grupo.
La pieza que falta
Quita la autorización de las manos del agente. Déjale el ticket.
El agente lee, responde, deriva y propone. Ahí termina su función. Quién entra en qué grupo lo decide una regla que firmaste antes del turno, y dos aprobadores designados para cualquier grupo privilegiado, cualquier restablecimiento de MFA de una cuenta privilegiada, cualquier cuenta de emergencia.
El ticket se queda con el agente. La autoridad vive en tu conector, sobre un comprobante. ZIFFER no tiene ninguna credencial del IdP, del directorio ni del PAM.
- regla
- Clase del grupo, clase de la cuenta, caducidad, días desde la creación de la cuenta, quién puede firmar. Un grupo que la regla no nombra está en el nivel más alto. Una acción que la regla no nombra se rechaza.
- quórum
- Dos aprobadores designados, passkeys y un resumen generado a partir de los bytes firmados de la propuesta: cuenta, grupo, caducidad, ticket de cambio presente o no. Quien propone nunca cuenta.
- comprobante
- Firmado, verificado sin conexión por tu conector antes de la llamada al IdP. ZIFFER no tiene ninguna credencial del IdP, del directorio ni del PAM.
El agente lee el ticket. No autoriza el grupo.
Lo que las normas ya dicen
La regla no es nueva. Solo el agente lo es.
| Escribieron | Quién, cuándo | Mecanismo de ZIFFER |
|---|---|---|
| «Multi-party approval. An administrator’s credential is only released if a different, authorised individual(s) approve it.» | UK NCSC, Secure system administration | quórum 2 de 2 en cada alta en un grupo privilegiado |
| «Rule based auto approval. When a specific criteria is met, the credential is automatically approved without human intervention.» | UK NCSC, Secure system administration | los grupos estándar se autorizan de inmediato por la regla, con comprobante |
| «Enforce dual authorization for … privileged commands and/or other actions.» | NIST SP 800-53 rev 5, AC-3(2) | dos firmantes designados; quien propone nunca cuenta |
| «Require approvals by … personnel or roles for requests to create accounts» | NIST SP 800-53 rev 5, AC-2(e) | create_account necesita una regla; sin regla, se rechaza |
| «Required privileges are approved by authorized personnel.» | PCI DSS v4.0.1, 7.2.3 | el comprobante nombra a los aprobadores |
| «Implemented with only the privileges specified on the documented approval.» | PCI DSS v4.0.1, 8.2.4 | otro grupo es una propuesta nueva y una firma nueva |
| «User identity is verified before modifying any authentication factor.» | PCI DSS v4.0.1, 8.3.3 | un restablecimiento de MFA en una cuenta privilegiada espera al quórum |
| «In all cases, account recovery SHALL cause a notification to be sent to the subscriber» | NIST SP 800-63B-4, 4.2.3, 2025-07 | aviso al titular de la cuenta en cada restablecimiento privilegiado |
| «giving consideration to the concepts of least privilege and segregation of duties» | SOC 2, CC6.3 | el agente propone, las personas firman, tu código tiene la credencial del IdP |
| «Utilise human-in-the-loop control to require a human to approve high-impact actions … in a downstream system» | OWASP LLM06:2025, 2024-11 | el control está fuera del agente, antes de la llamada al IdP |
Todos los controles exigían a otra persona antes de que el grupo cambiara. ZIFFER es el primer lugar donde el agente no puede ser esa persona.
Lo que las normas ya dicen
La regla no es nueva. Solo el agente lo es.
- «Multi-party approval. An administrator’s credential is only released if a different, authorised individual(s) approve it.»UK NCSC, Secure system administrationMecanismo de ZIFFERquórum 2 de 2 en cada alta en un grupo privilegiado
- «Rule based auto approval. When a specific criteria is met, the credential is automatically approved without human intervention.»UK NCSC, Secure system administrationMecanismo de ZIFFERlos grupos estándar se autorizan de inmediato por la regla, con comprobante
- «Enforce dual authorization for … privileged commands and/or other actions.»NIST SP 800-53 rev 5, AC-3(2)Mecanismo de ZIFFERdos firmantes designados; quien propone nunca cuenta
- «Require approvals by … personnel or roles for requests to create accounts»NIST SP 800-53 rev 5, AC-2(e)Mecanismo de ZIFFERcreate_account necesita una regla; sin regla, se rechaza
- «Required privileges are approved by authorized personnel.»PCI DSS v4.0.1, 7.2.3Mecanismo de ZIFFERel comprobante nombra a los aprobadores
- «Implemented with only the privileges specified on the documented approval.»PCI DSS v4.0.1, 8.2.4Mecanismo de ZIFFERotro grupo es una propuesta nueva y una firma nueva
- «User identity is verified before modifying any authentication factor.»PCI DSS v4.0.1, 8.3.3Mecanismo de ZIFFERun restablecimiento de MFA en una cuenta privilegiada espera al quórum
- «In all cases, account recovery SHALL cause a notification to be sent to the subscriber»NIST SP 800-63B-4, 4.2.3, 2025-07Mecanismo de ZIFFERaviso al titular de la cuenta en cada restablecimiento privilegiado
- «giving consideration to the concepts of least privilege and segregation of duties»SOC 2, CC6.3Mecanismo de ZIFFERel agente propone, las personas firman, tu código tiene la credencial del IdP
- «Utilise human-in-the-loop control to require a human to approve high-impact actions … in a downstream system»OWASP LLM06:2025, 2024-11Mecanismo de ZIFFERel control está fuera del agente, antes de la llamada al IdP
Todos los controles exigían a otra persona antes de que el grupo cambiara. ZIFFER es el primer lugar donde el agente no puede ser esa persona.
Un turno, cuatro escenas
La regla que firmaste a las 09:00 respondió al ticket a las 10:41.
Reloj de la demo. Quórum 2 de 2 para cada acción clasificada como HIGH, y después una retención de 60 segundos antes de la liberación. Ventana de atestación de 15 minutos.
09:10
La elevación de guardia.
Un ticket de cambio para la migración de base de datos de esta noche está aprobado. El agente propone add_group_member: el DBA de guardia en prod-db-admins, caducidad 8 horas. Nivel T3, HIGH. El responsable de IAM y el propietario de la base de datos leen «añadir r.okafor a prod-db-admins, caduca a las 17:10», generado a partir de la propuesta firmada, y firman con sus passkeys. Retenida 60 segundos; nadie la detiene; liberada. El alta llega al IdP solo después del comprobante.
registro: ALLOW · comprobante · 2 atestaciones
09:45
El restablecimiento de la administradora.
Una administradora de finanzas perdió el teléfono y acudió en persona al servicio de soporte. El agente propone reset_mfa en su cuenta. Cuenta privilegiada, HIGH, irreversible. Dos firmantes aprueban. La titular de la cuenta recibe el aviso en su dirección registrada. El responsable de soporte, que no hizo la propuesta, confirma la liberación.
registro: ALLOW · comprobante · 2 atestaciones · aviso enviado · confirmada
10:05
La nueva incorporación.
Un ticket de RR. HH. para un nuevo analista. El agente propone add_group_member a crm-users. Grupo estándar, T1, LOW. Autorizada de inmediato. El conector verifica el comprobante y llama al IdP.
registro: ALLOW · comprobante
10:41
El ticket.
Un ticket de soporte, urgente, «aprobado por la oficina de seguridad»: un contratista que empieza hoy necesita tier0-admins para una migración. La descripción del ticket contiene una línea dirigida al agente. Nada filtra el ticket. El agente se lo cree y propone add_group_member: la cuenta del contratista en tier0-admins. Nivel T3, HIGH, quórum 2 de 2. Los dos firmantes leen «añadir la cuenta de contratista ext-jlaine a tier0-admins, sin ticket de cambio». Ninguno firma. A las 10:56 se cierra la ventana. Los aprobadores reciben el aviso de que la solicitud expiró sin respuesta.
registro: ATTEST · expirada sin respuesta · 0 atestaciones · ningún comprobante emitido · nunca ejecutada
El agente leyó el ticket a las 10:41. La regla que firmaste a las 09:00, no.
Tres comprobantes y un rechazo, verificables sin conexión con la clave que tú tienes.
Un turno, cuatro escenas
La regla que firmaste a las 09:00 respondió al ticket a las 10:41.
Reloj de la demo. Quórum 2 de 2 para cada acción clasificada como HIGH, y después una retención de 60 segundos antes de la liberación. Ventana de atestación de 15 minutos.
09:10
La elevación de guardia.
Un ticket de cambio para la migración de base de datos de esta noche está aprobado. El agente propone add_group_member: el DBA de guardia en prod-db-admins, caducidad 8 horas. Nivel T3, HIGH. El responsable de IAM y el propietario de la base de datos leen «añadir r.okafor a prod-db-admins, caduca a las 17:10», generado a partir de la propuesta firmada, y firman con sus passkeys. Retenida 60 segundos; nadie la detiene; liberada. El alta llega al IdP solo después del comprobante.
registro: ALLOW · comprobante · 2 atestaciones
09:45
El restablecimiento de la administradora.
Una administradora de finanzas perdió el teléfono y acudió en persona al servicio de soporte. El agente propone reset_mfa en su cuenta. Cuenta privilegiada, HIGH, irreversible. Dos firmantes aprueban. La titular de la cuenta recibe el aviso en su dirección registrada. El responsable de soporte, que no hizo la propuesta, confirma la liberación.
registro: ALLOW · comprobante · 2 atestaciones · aviso enviado · confirmada
10:05
La nueva incorporación.
Un ticket de RR. HH. para un nuevo analista. El agente propone add_group_member a crm-users. Grupo estándar, T1, LOW. Autorizada de inmediato. El conector verifica el comprobante y llama al IdP.
registro: ALLOW · comprobante
10:41
El ticket.
Un ticket de soporte, urgente, «aprobado por la oficina de seguridad»: un contratista que empieza hoy necesita tier0-admins para una migración. La descripción del ticket contiene una línea dirigida al agente. Nada filtra el ticket. El agente se lo cree y propone add_group_member: la cuenta del contratista en tier0-admins. Nivel T3, HIGH, quórum 2 de 2. Los dos firmantes leen «añadir la cuenta de contratista ext-jlaine a tier0-admins, sin ticket de cambio». Ninguno firma. A las 10:56 se cierra la ventana. Los aprobadores reciben el aviso de que la solicitud expiró sin respuesta.
registro: ATTEST · expirada sin respuesta · 0 atestaciones · ningún comprobante emitido · nunca ejecutada
El agente leyó el ticket a las 10:41. La regla que firmaste a las 09:00, no.
Tres comprobantes y un rechazo, verificables sin conexión con la clave que tú tienes.
La regla
Seis filas deciden el turno. El agente no escribió ninguna.
El nivel viene del grupo y de la cuenta. La clasificación viene de la regla. Un grupo que la regla no nombra se trata como del nivel más alto. Una acción que la regla no nombra se rechaza.
| Acción | Objetivo | Nivel | Clasificación | Resultado |
|---|---|---|---|---|
| add_group_member | grupo estándar | T1 | LOW | autorizada de inmediato, comprobante |
| create_account | cuenta de contratista, caducidad a 30 días | T2 | MEDIUM | autorizada de inmediato, comprobante |
| add_group_member | grupo privilegiado | T3 | HIGH | quórum 2 de 2, comprobante, liberada tras la retención |
| reset_mfa | cuenta privilegiada | T3 | HIGH, irreversible | quórum 2 de 2, aviso, comprobante, confirmada por una persona avisada |
| enable_account | cuenta de emergencia | T3 | HIGH, irreversible | quórum 2 de 2, aviso, comprobante, confirmada por una persona avisada |
| add_group_member | cuenta de contratista a un grupo privilegiado | T3 | HIGH | quórum 2 de 2, o no se ejecuta nada |
floors · reversibility · risk_functions · notice_targets
El autor y el revisor de la regla son dos personas distintas.
La regla
Seis filas deciden el turno. El agente no escribió ninguna.
El nivel viene del grupo y de la cuenta. La clasificación viene de la regla. Un grupo que la regla no nombra se trata como del nivel más alto. Una acción que la regla no nombra se rechaza.
- add_group_membergrupo estándarT1 · LOW autorizada de inmediato, comprobante
- create_accountcuenta de contratista, caducidad a 30 díasT2 · MEDIUM autorizada de inmediato, comprobante
- add_group_membergrupo privilegiadoT3 · HIGH quórum 2 de 2, comprobante, liberada tras la retención
- reset_mfacuenta privilegiadaT3 · HIGH, irreversible quórum 2 de 2, aviso, comprobante, confirmada por una persona avisada
- enable_accountcuenta de emergenciaT3 · HIGH, irreversible quórum 2 de 2, aviso, comprobante, confirmada por una persona avisada
- add_group_membercuenta de contratista a un grupo privilegiadoT3 · HIGH quórum 2 de 2, o no se ejecuta nada
floors · reversibility · risk_functions · notice_targets
El autor y el revisor de la regla son dos personas distintas.
Antes de que preguntes
Lo que todo responsable de IAM pregunta primero.
¿Esto ralentizará las incorporaciones?
No. Un grupo estándar se autoriza de inmediato, con comprobante. Solo un grupo privilegiado, un restablecimiento de MFA en una cuenta privilegiada o una cuenta de emergencia esperan, y esperan a dos personas que ya tenían que aprobarlo.
¿Quién aprueba de noche o en fin de semana?
La regla nombra a los aprobadores por adelantado y dos cualesquiera de ellos firman, en sus teléfonos, con sus passkeys. La elevación de guardia de las 09:10 tardó lo que tardan dos personas en leer una línea.
¿Y si nadie firma?
Entonces nada cambia y los aprobadores reciben el aviso de que la solicitud expiró sin respuesta. No existe ningún comprobante, así que tu conector nunca llama al IdP. El ticket espera a una persona, como hoy.
Listamos nuestros límites antes de que los encuentres. Entonces no se autoriza nada, y no existe ningún comprobante sobre el que actuar.
Antes de que preguntes
Lo que todo responsable de IAM pregunta primero.
¿Esto ralentizará las incorporaciones?
No. Un grupo estándar se autoriza de inmediato, con comprobante. Solo un grupo privilegiado, un restablecimiento de MFA en una cuenta privilegiada o una cuenta de emergencia esperan, y esperan a dos personas que ya tenían que aprobarlo.
¿Quién aprueba de noche o en fin de semana?
La regla nombra a los aprobadores por adelantado y dos cualesquiera de ellos firman, en sus teléfonos, con sus passkeys. La elevación de guardia de las 09:10 tardó lo que tardan dos personas en leer una línea.
¿Y si nadie firma?
Entonces nada cambia y los aprobadores reciben el aviso de que la solicitud expiró sin respuesta. No existe ningún comprobante, así que tu conector nunca llama al IdP. El ticket espera a una persona, como hoy.
Listamos nuestros límites antes de que los encuentres. Entonces no se autoriza nada, y no existe ningún comprobante sobre el que actuar.
Nada que sustituir
Conserva tu IdP. Conserva tu IGA y tu PAM. Añade la regla y el comprobante.
- SDK
- Tu conector propone y después verifica el comprobante antes de llamar al IdP. Python y TypeScript.
- Flujo
- Un paso HTTP antes del paso de ejecución en tu flujo de ITSM o IGA, y una bifurcación sobre el comprobante verificado. Tu plataforma conserva sus flujos.
- MCP
- Un agente en un cliente MCP propone a través del servidor ZIFFER. El comprobante sigue yendo a tu código.
- latencia
- p50 244 ms, p99 1,2 s de la propuesta a la decisión. Medido el 2026-08-28, ensayo local.
La aprobación de tu IdP la resuelve el primer aprobador que responde, y su registro se queda en el log del propio IdP. Los aprobadores de ZIFFER firman los bytes exactos de una autorización, y tu propio código verifica el comprobante fuera del IdP.
Nada que sustituir
Conserva tu IdP. Conserva tu IGA y tu PAM. Añade la regla y el comprobante.
- SDK
- Tu conector propone y después verifica el comprobante antes de llamar al IdP. Python y TypeScript.
- Flujo
- Un paso HTTP antes del paso de ejecución en tu flujo de ITSM o IGA, y una bifurcación sobre el comprobante verificado. Tu plataforma conserva sus flujos.
- MCP
- Un agente en un cliente MCP propone a través del servidor ZIFFER. El comprobante sigue yendo a tu código.
- latencia
- p50 244 ms, p99 1,2 s de la propuesta a la decisión. Medido el 2026-08-28, ensayo local.
La aprobación de tu IdP la resuelve el primer aprobador que responde, y su registro se queda en el log del propio IdP. Los aprobadores de ZIFFER firman los bytes exactos de una autorización, y tu propio código verifica el comprobante fuera del IdP.
FAQ
Agentes de identidad de IA y ZIFFER, en ocho preguntas.
¿Puede un agente de IA añadir a alguien a un grupo privilegiado como Domain Admins?
A través de un conector o con los privilegios de quien lo inició, sí. Con ZIFFER el alta es una propuesta que firman dos aprobadores designados, o no ocurre.
Ya usamos las aprobaciones de PIM. ¿Por qué añadir ZIFFER?
La aprobación de PIM la resuelve el primer aprobador que responde, el campo de ticket no se impone y el registro se queda en el IdP. Los aprobadores de ZIFFER firman los bytes exactos, y tu propio código verifica el comprobante fuera del IdP.
¿Qué impide que un ticket de soporte engañe al agente para que autorice acceso admin?
Nada impide que engañen al agente. El alta en un grupo privilegiado la clasifica como HIGH la regla, no el ticket, y espera a dos personas designadas que leen lo que el agente propuso.
¿Esto ralentizará las incorporaciones y las solicitudes de acceso estándar?
No. Un grupo estándar se autoriza de inmediato, con comprobante.
¿Quién aprueba una solicitud de acceso privilegiado de noche o en fin de semana?
Dos cualesquiera de los aprobadores que nombra la regla, en sus teléfonos, con sus passkeys.
¿ZIFFER tiene nuestras credenciales de administración del IdP?
No. Tu conector llama al IdP con tu credencial, después de verificar el comprobante.
¿Qué evidencia obtenemos para las revisiones de acceso de SOC 2 y PCI DSS?
Un comprobante firmado por cada autorización, con los aprobadores y la versión de la regla, verificado con una herramienta abierta en tu máquina. Un registro de decisión por cada rechazo.
¿Qué ve ZIFFER?
La propuesta, la época de la política y las atestaciones. Ni tu directorio ni tus tickets.
FAQ
Agentes de identidad de IA y ZIFFER, en ocho preguntas.
¿Puede un agente de IA añadir a alguien a un grupo privilegiado como Domain Admins?
A través de un conector o con los privilegios de quien lo inició, sí. Con ZIFFER el alta es una propuesta que firman dos aprobadores designados, o no ocurre.
Ya usamos las aprobaciones de PIM. ¿Por qué añadir ZIFFER?
La aprobación de PIM la resuelve el primer aprobador que responde, el campo de ticket no se impone y el registro se queda en el IdP. Los aprobadores de ZIFFER firman los bytes exactos, y tu propio código verifica el comprobante fuera del IdP.
¿Qué impide que un ticket de soporte engañe al agente para que autorice acceso admin?
Nada impide que engañen al agente. El alta en un grupo privilegiado la clasifica como HIGH la regla, no el ticket, y espera a dos personas designadas que leen lo que el agente propuso.
¿Esto ralentizará las incorporaciones y las solicitudes de acceso estándar?
No. Un grupo estándar se autoriza de inmediato, con comprobante.
¿Quién aprueba una solicitud de acceso privilegiado de noche o en fin de semana?
Dos cualesquiera de los aprobadores que nombra la regla, en sus teléfonos, con sus passkeys.
¿ZIFFER tiene nuestras credenciales de administración del IdP?
No. Tu conector llama al IdP con tu credencial, después de verificar el comprobante.
¿Qué evidencia obtenemos para las revisiones de acceso de SOC 2 y PCI DSS?
Un comprobante firmado por cada autorización, con los aprobadores y la versión de la regla, verificado con una herramienta abierta en tu máquina. Un registro de decisión por cada rechazo.
¿Qué ve ZIFFER?
La propuesta, la época de la política y las atestaciones. Ni tu directorio ni tus tickets.
El agente lee el ticket. No autoriza el grupo.
Trae el agente de identidad que ejecutas y el conector al que llama. Sal con la regla firmada.
El agente lee el ticket. No autoriza el grupo.
Trae el agente de identidad que ejecutas y el conector al que llama. Sal con la regla firmada.