Seguridad de IA con Monofor: Gateways, salvaguardas y credenciales de máquina
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 8 → 9
ActualizaciónCuatro lecciones nuevas cierran la brecha con el examen MCASP: aprobadores y credenciales perdidas en la práctica, operar los Gateways (límites de tiempo, streaming, audiencia del token), AI flows en operación y elegir y delimitar una identidad de máquina. Cada cuestionario de módulo tiene dos preguntas nuevas. Se añadieron diagramas a las lecciones nuevas.
4 lecciones actualizadasduración
Actualización de contenido. Se notificó a los estudiantes inscritos.
La duración cambió de 66 a 67 minutos.
Una política de aprobación parece sencilla sobre el papel. En el trabajo diario, tres preguntas deciden si aguanta: a quién se pregunta de verdad, cómo se entera y qué hace usted cuando el secreto de una credencial se ha perdido. Esta lección recorre cada una con un agente de ejemplo.
### Ejemplo: un agente que inicia reembolsos
El agente `refund-bot` puede iniciar reembolsos. La responsable de seguridad quiere que dos responsables financieros con nombre y apellido aprueben juntos y expliquen cada decisión. Abra el agente y su pestaña `Approvers`:
| Ajuste | Valor | Por qué |
| --- | --- | --- |
| Modo | `Choose for this agent` en lugar de `Use the default` | El valor por defecto del inquilino pregunta a los gestores y luego a los propietarios de gobierno. Aquí es demasiado amplio |
| Casilla del paso | `These people`, con ambos responsables | Personas concretas, no quien gestione el agente en ese momento |
| `How many must approve` | `Everybody asked` | Con `Any one` un solo responsable podría decidir |
| `Approvers must write why` | Activado | No se acepta una decisión sin motivo |
| `Also tell them by` | `Push to the authenticator app` | Es el valor por defecto. También se puede marcar `E-mail with approve and deny links` |
La campana de la consola en Management se usa siempre, marque lo que marque en `Also tell them by`. Así, un paso con sus valores por defecto llega a los aprobadores por dos vías: la campana y un push a la aplicación Authenticator. El correo es el canal que usted añade a propósito.
Después de cada cambio lea el panel `Right now a request would go to`. Enumera las personas que la política encuentra en ese momento.
### Quién cuenta como aprobador
Solo cuentan las personas **habilitadas**, y la persona en cuyo nombre actúa el agente se retira de la lista. Por eso un agente puede tener propietario sobre el papel y aun así nadie a quien preguntar.
Ejemplo: un agente se promovió desde `Detected` y recibió un único propietario de gobierno. Nunca se añadió un Direct Manager. El propietario deja la empresa y su cuenta se deshabilita. La siguiente solicitud de ese agente no se queda esperando. Se rechaza al instante, porque una solicitud que nadie puede responder solo caducaría más tarde con el mismo resultado, después de que el llamante haya perdido minutos.
Dos hábitos lo evitan: añada un segundo paso con `Add a fallback: who to ask when nobody above is found` y revise el panel cuando las personas cambien de puesto.
### Cuánto espera una solicitud
`A request waits for` en el paso vale 10 minutos por defecto. Un llamante de la API que crea una solicitud puede enviar su propio `ExpirationSeconds`. Un valor positivo prevalece sobre la política y tiene un tope de 86400 segundos, es decir, un día. Sin él decide la política.
### El secreto perdido de una credencial
El secreto de una credencial de agente se muestra una vez, al crearla. No se puede volver a mostrar, ni siquiera a un administrador. Si un desarrollador no lo guardó:
1. Abra la pestaña `Credentials` del agente y revoque la credencial con `Revoke`.
2. Use `Create Credential` y entregue el nuevo secreto de forma segura.
Revoque primero, porque nadie sabe dónde puede haber una copia del secreto antiguo. Recuerde que revocar una credencial no termina los tokens ya emitidos. Si sospecha un uso indebido, use `Kill Switch`.
::diagram ais-lost-credential
### Un presupuesto de tokens, no de llamadas
`Token issuances / hour` en `Budget & Quotas` limita con qué frecuencia el agente puede obtener un token. Los límites de solicitudes limitan las llamadas. Un agente al que se le niega un token escribe `AGENT_TOKEN_DENIED` con el motivo en su pestaña `Audits`. Lea ese motivo antes de subir un límite.
Cuando el tráfico ya pasa por los Gateways, las preguntas cambian. Ya no se pregunta "¿está permitido?", sino "¿por qué se comporta así?". Cinco comportamientos explican la mayoría de esas preguntas.
| Lo que se nota | Causa | Dónde se ve |
| --- | --- | --- |
| Las tareas largas fallan tras unos cinco minutos y las cortas funcionan | `Timeout (seconds)` del proveedor | Resultado HTTP 504 en la llamada |
| Una respuesta llega de una vez y no palabra a palabra | El Gateway tuvo que leer antes la respuesta completa | `translated` o `cache` en la llamada, o un AI flow sobre la respuesta |
| HTTP 401 con un token bearer, las claves de agente funcionan | El token no se emitió para esta ruta | Resultado `DENIED (audience)` |
| Se rechaza una llamada delegada aunque la delegación está activa | La cadena es demasiado larga o nombra a un agente dos veces | Se rechaza la solicitud de token |
| Responde un modelo más pequeño que el solicitado | `Cheaper model close to a limit` | Cabecera `X-Monosign-Downgraded-From` |
### El límite de tiempo de un proveedor
Cada proveedor tiene un `Timeout (seconds)`. Vale 300 por defecto y admite de 5 a 3600. Cubre la espera del primer byte y la espera de cada línea transmitida.
Ejemplo: un modelo de razonamiento piensa seis minutos antes de enviar nada. Con el valor por defecto, el Gateway abandona a los 300 segundos y responde HTTP 504 `The AI provider did not answer within {n} seconds.` Los prompts cortos en el mismo proveedor funcionan, lo que hace que el problema parezca aleatorio. La solución está en el proveedor: suba `Timeout (seconds)`. Reintentar la misma llamada solo repite la espera.
### Por qué una respuesta en streaming puede llegar de una vez
Normalmente el Gateway reenvía una respuesta en streaming según llega. En tres casos debe tener antes la respuesta completa:
- la respuesta se traduce entre formatos de proveedor (`Let clients of the other format in`),
- la respuesta sale de la caché de respuestas,
- un AI flow en la etapa `Response` la inspecciona.
Entonces el Gateway obtiene la respuesta entera y la reproduce al cliente como un flujo. Es el comportamiento esperado, no un fallo. Un flow no puede ocultar un número de tarjeta en un texto que ya ha salido, así que inspeccionar una respuesta significa leerla antes hasta el final. Avise a los usuarios antes de activar un flow así.
### Los tokens deben emitirse para la ruta
Una ruta acepta por defecto `Only tokens issued for this route`. Por eso un cliente OAuth nombra la ruta cuando pide un token a Monosign: envía el parámetro `resource` con la ruta registrada del Gateway (RFC 8707).
- Sin `resource`: HTTP 401 `The token names no resource. Request it with the resource parameter set to this gateway route.`
- Un token para otra cosa: `The token was issued for another resource.`
Corrija al llamante, no la comprobación. Relajar `Which tokens are accepted` permitiría usar en un servicio un token creado para otro. Las claves de agente no están sujetas a esta comprobación, y la ruta debe registrarse con `Register` antes de que se puedan emitir tokens para ella.
::diagram ais-route-token-resource
### Un techo para las cadenas de delegación
`Agent to agent delegation depth` decide hasta dónde puede pasarse la tarea de una persona. Por encima de ese ajuste hay un techo fijo: una cadena de más de 8 agentes, o una que nombra al mismo agente dos veces, se rechaza siempre. Eso impideUn agente que dos agentes se pasen unaya forma parte de la cadena no puede recibir la tarea de uno a otro sin finnuevo.
### Cuando responde un modelo más barato
Cuando `Cheaper model close to a limit` mueve una llamada a un modelo más barato, la respuesta lleva la cabecera `X-Monosign-Downgraded-From` con el modelo solicitado, y el registro de la llamada guarda el mismo dato. Los desarrolladores pueden leer la cabecera y mostrar a los usuarios por qué la respuesta se ve distinta.
Crear un flow lleva minutos. Operarlo bien depende de detalles que se pasan por alto con facilidad: cómo probarlo sin riesgo, qué debe hacer el remitente tras una aprobación, qué hallazgos se pueden ocultar y qué tráfico no toca nunca un flow.
### Tres formas de probar un flow
| | `Test this flow` | `Watching` | `Enforcing` |
| --- | --- | --- | --- |
| Entrada | Texto de ejemplo que escribe en el diseñador | Tráfico real | Tráfico real |
| Servicios de protección, webhooks, el modelo juez | No se llaman | Se llaman | Se llaman |
| Se pregunta a una persona | Nunca | Nunca | Sí |
| Se inicia un flujo de trabajo | Nunca | Nunca | Sí |
| El mensaje se cambia o se detiene | No | No | Sí |
`Test this flow` se ejecuta con servicios en seco: muestra cómo reaccionan sus pasos y patrones ante un texto, pero no llama a nadieningún servicio de protección, webhook, modelo juez ni aprobador. Un flow en observación ve tráfico real y escribe en `Runs` lo que habría hecho, con notas como `would block`, `would ask for approval` y `would start a workflow`. Lea esas notas antes de elegir `Start enforcing`.
### Después de `Ask a person`: envíelo de nuevo
Monosign no mantiene abierto un mensaje mientras una persona decide. Al remitente se le dice `This message needs approval before it can go on. Send it again once it is approved.`
¿Cómo sabe Monosign que el segundo mensaje es el aprobado? Compara una huella formada por el flow, el paso, la superficie, el destino, la herramienta, la persona, el agente y el texto.
Ejemplo: a las 10:00 un agente envía el resumen de un contrato y el flow lo retiene. A las 10:10 el aprobador aprueba. A las 10:11 el agente envía el mensaje idéntico y pasa. De ahí salen tres reglas:
- El mismo mensaje dentro de 30 minutos reutiliza la solicitud existente. No crea una segunda.
- Una solicitud aprobada deja pasar el mensaje una vez.
- Un texto cambiado es un mensaje nuevo y necesita una aprobación nueva. Una solicitud rechazada bloquea.
Los desarrolladores de agentes deben incorporarlo: conservar el mensaje, esperar y reenviarlo sin cambios.
::diagram ais-flow-approval-resend
### Qué hallazgos se pueden ocultar
`Hide what was found` necesita saber **dónde** está un hallazgo en el texto. Solo dos fuentes dan posiciones:
| Fuente del hallazgo | Puede bloquear | Puede alimentar `Hide what was found` |
| --- | --- | --- |
| `Find patterns` integrado | Sí | Sí |
| `Ask a guard service` con `Microsoft Presidio` | Sí | Sí |
| Los demás servicios de protección | Sí | No |
Así, un cliente que ya usa Presidio coloca un paso `Ask a guard service` y debajo un paso `Hide what was found`. Un servicio de protección que solo dice "este mensaje es dañino" puede detener el mensaje, pero no enmascararlo.
### Alcance: la excepción de `automation`
Un flow sin límites en `Where does it apply?` se aplica en todas partes, con una excepción: los prompts de la función `automation` del propio Monosign. Solo los toca un flow que nombra `automation` en `Only in these Monosign features`. Si la auditoría pregunta por qué nunca se inspeccionaron los prompts de automation, este es el primer lugar donde mirar.
### Flows creados mediante la API
| | Diseñador | API sin el campo |
| --- | --- | --- |
| Modo | Empieza en observación | `Enforce` |
| Qué conserva del texto una ejecución registrada | Un extracto corto con los hallazgos tachados | Nada |
Por eso un flow creado mediante la API sin `Mode` actúa sobre tráfico real en cuanto su estado pasa a `Active`. Los equipos que despliegan flows desde una canalización deberían enviar siempre `Mode` y `RetentionMode` de forma explícita.
### Personas que chocan una y otra vez con la política
Los bloqueos de los flows en aplicación cuentan para la detección `AI Policy Violations`, por defecto 5 mensajes bloqueados en 60 minutos. La detección establece `user.hasActiveThreat` para esa persona. Como las condiciones de un flow pueden leer `user.hasActiveThreat`, otro flow puede ser más estricto justo con esas personas, por ejemplo preguntando a una persona donde otros pasan.
La lección anterior presentó las identidades de máquina. Esta le ayuda a elegir entre las opciones, porque cada elección mueve un riesgo de un lugar a otro.
### Qué método de autenticación
| Método | Secreto guardado en la carga de trabajo | Necesita | Adecuado para |
| --- | --- | --- | --- |
| Universal Auth | Sí, un client secret | Nada más | Cualquier sitio, cuando no hay nada mejor |
| OIDC | No | Un emisor descubrible públicamente | Canalizaciones de CI como GitHub Actions y GitLab, clústeres gestionados con emisor OIDC |
| Kubernetes | No | Monopam debe alcanzar el servidor de API del clúster | Cualquier clúster alcanzable, incluidos los autogestionados |
El inicio de sesión OIDC no funciona en un clúster autogestionado cuyo emisor solo se conoce dentro del clúster. Use allí una identidad de Kubernetes.
::diagram ais-machine-auth-choice
### OIDC para una canalización: el claim vinculado
Un agente de programación con IA se ejecuta en un trabajo de CI. La plataforma de CI ya da a cada trabajo un token firmado, así que no hace falta guardar ningún secreto de Monopam en la canalización. La identidad tiene tres campos:
- `Issuer`: el emisor de tokens de la plataforma de CI, por ejemplo `https://token.actions.githubusercontent.com`.
- `Audience`: se comprueba cuando está definida.
- `Bound claim (sub)`: qué carga de trabajo puede iniciar sesión. Se admite un comodín al final, como en `repo:my-org/*`.
Rellene el claim vinculado. El inicio de sesión comprueba el token con las claves del emisor, con la audiencia cuando está definida y con el claim vinculado es lo más importante. Una plataforma de CI pública emitefirma los tokens parade todos sus clientes, de modo que confiar solo en con el mismo emisor sería confiar en demasiadas canalizaciones. El claim, y `Bound claim (sub)` reducees el campo que ata la confianzaidentidad a sus propios repositorios.
### Kubernetes: quién revisa el token
Monopam no verifica por sí mismo un token de service account. Envía el token al clúster para un TokenReview. Esa revisión necesita una credencial, y usted elige cuál:
| | `Reviewer Token` definido | `Reviewer Token` vacío (autorrevisión) |
| --- | --- | --- |
| Quién queda vinculado a `system:auth-delegator` | Una service account revisora | Cada service account de carga de trabajo vinculada |
| Derechos adicionales para las cargas de trabajo | Ninguno | Un permiso de todo el clúster cada una |
| Guardado en Monopam | Un token del clúster, cifrado | Nada |
Si la prioridad es que las cargas de trabajo de los agentes no reciban derechos adicionales en el clúster, elija un Reviewer Token. Si la prioridad es que Monopam no guarde ningún token del clúster, elija la autorrevisión y acepte la vinculación más amplia.
### Grants: proyecto, entorno, ruta, escritura
Un grant tiene `Project`, `Environment`, `Path` y el interruptor `Write`.
- `Environment` es `All environments` salvo que elija uno. Eso cubre también los entornos creados más tarde.
- `Path` es un prefijo: `/db` cubre `/db` y todo lo que hay debajo.
- `Write` está desactivado salvo que lo active.
Ejemplo: un agente de informes necesita la configuración de base de datos del proyecto `billing` en `staging`, solo lectura. El grant es proyecto `billing`, entorno `staging`, ruta `/db`, `Write` desactivado. Dejar el entorno vacío le daría también producción.
### Dónde está la ventana de auditoría de lecturas
`Machine read audit window (minutes)` está en `System → Secrets API`, en la tarjeta `Audit`. Se aplica a las lecturas por la API de máquina, la herramienta MCP `get_secret` y la API compatible con Vault. Con 0 cada lectura tiene su propia entrada.
### Sesiones a través del servidor MCP
Para trabajar en un servidor, un agente con un token de usuario usa estas herramientas en lugar de una contraseña:
| Herramienta | Propósito |
| --- | --- |
| `open_session` | Abre una sesión intermediada. Responde `approval_pending` cuando la cuenta necesita aprobación |
| `session_exec` | Ejecuta una línea de comandos en una sesión SSH |
| `session_query` | Ejecuta una consulta en una sesión de base de datos |
| `close_session` | Cierra la sesión |
La credencial se queda en Monopam, así que el modelo nunca la ve. Una sesión SSH se graba, aparece en Live Sessions, donde un operador puede tomar el control o terminarla, y cada línea de comandos pasa la comprobación de comandos privilegiados.