Seguridad
Cómo se protege Mnemom.
AEGIS revisa las llamadas al modelo de sus agentes mientras se ejecutan. Debajo están los controles que protegen la propia plataforma. Los cuestionarios de seguridad y la evidencia de controles están disponibles bajo NDA.
Revisión en tiempo de ejecución AEGIS
Cada llamada al modelo se revisa en cuatro puntos.
Las llamadas al modelo que pasan por el gateway de Mnemom se revisan a la entrada, en el uso de herramientas, en el razonamiento del agente y a la salida. Para cada agente usted elige si una revisión solo registra, advierte o interviene.
- 1
front door
El mensaje más reciente del usuario y los resultados de herramientas, antes de que lleguen al modelo.
- 2
inside.autonomy
Las herramientas ofrecidas al modelo y las llamadas a herramientas que realiza.
- 3
inside.integrity
El razonamiento del agente, revisado por nuestro control de integridad (AIP).
- 4
back door
La respuesta, antes de devolverla a su aplicación.
Qué revisamos
| Amenaza | Se revisa en | Cómo |
|---|---|---|
| Inyección de promptsfront door | Reglas de patrones y después un juez basado en un modelo. El texto se normaliza primero, para que los caracteres parecidos u ocultos no pasen. | |
| Instrucciones ocultas en resultados de herramientasfront door | Las mismas revisiones en los resultados de herramientas, como una página o un documento obtenido. En modo enforce, un resultado marcado se reemplaza antes de que el modelo lo vea. | |
| Herramientas prohibidas y operaciones protegidasinside.autonomy | Las herramientas se comparan con la Alignment Card del agente. Las llamadas a herramientas se comparan con los activos y operaciones que su organización marca como protegidos, como eliminar una tabla. | |
| Datos sensibles en las respuestasback door | Números de tarjeta, números de seguro social de EE. UU., claves de API, claves privadas, tokens de acceso, cadenas de conexión, correos, teléfonos y direcciones IP. Se ocultan en respuestas sin streaming y se registran en las respuestas en streaming. | |
| Fraude de pagos y suplantaciónfront door | Marca un cambio de beneficiario o de cuenta bancaria combinado con urgencia, secreto o presión para saltarse una aprobación. | |
| Falsas afirmaciones de autoridadfront door | Marca los mensajes que dicen venir de un sistema, de un administrador o de Mnemom. | |
| Razonamiento inseguroinside.integrity | Un modelo revisa el razonamiento del agente en busca de inyección de prompts, desalineación de valores, violaciones de autonomía, razonamiento engañoso e intenciones no declaradas. |
Tres ajustes por agente
- Safe House cubre la front door, las llamadas a herramientas y la back door. Cada una se puede activar o desactivar.
- Autonomía cubre el uso de herramientas frente a la Alignment Card.
- Integridad cubre el razonamiento del agente.
Los ajustes se aplican a nivel de plataforma, organización, equipo y agente, y gana el más estricto. Un nivel inferior puede añadir protección, pero no puede quitar ni debilitar una fijada más arriba. Los administradores de la organización fijan los niveles de organización, equipo y agente.
Cuatro modos por ajuste
| Modo | Qué ocurre |
|---|---|
| off | La revisión no se ejecuta. |
| observe | La revisión se ejecuta y el resultado se registra. La solicitud y la respuesta no cambian. |
| nudge | La solicitud pasa con una advertencia que el modelo y su aplicación pueden ver. Los datos sensibles de las respuestas salientes se ocultan. |
| enforce | El contenido marcado no pasa. Un mensaje inseguro se reemplaza por un aviso de cuarentena, un turno de herramienta prohibido o un control de integridad fallido se reemplaza por un rechazo, y los datos sensibles se ocultan. |
El resultado va en cada respuesta
Cada respuesta del gateway incluye el resultado de cada punto de control en un encabezado. Cada checkpoint de integridad también se firma y se encadena, como se describe abajo en Registro firmado.
x-mnemom-verdict: front=pass; autonomy=pass; integrity=pass; back=passCómo se mantienen al día las reglas
- Las reglas de detección llegan a cada gateway como un conjunto de reglas firmado con Ed25519. Cada gateway comprueba la firma antes de usar las reglas y recoge los cambios en pocos minutos.
- Probamos el control de forma continua con un atacante automatizado y adaptativo que actúa contra agentes de prueba en un entorno aislado, nunca contra agentes de clientes.
- Las reglas nuevas se revisan antes de llegar a producción.
OWASP Top 10 para aplicaciones agénticas
Dónde cubrimos los riesgos agénticos y dónde no.
| Riesgo | Cobertura | Qué hace Mnemom |
|---|---|---|
| ASI01 Agent goal hijackParcial | Los mensajes entrantes y los resultados de herramientas se revisan en busca de inyección directa e indirecta, y el riesgo se sigue a lo largo de los turnos de una sesión. | |
| ASI02 Tool misuseParcial | Las herramientas que la card prohíbe se pueden rechazar, y las llamadas a activos u operaciones protegidos se pueden retener. No se detectan todas las llamadas inseguras. | |
| ASI03 Identity and privilege abuseParcial | Los permisos de herramientas vienen de la card del agente, y se marcan las afirmaciones entrantes de autoridad de sistema o de administrador. | |
| ASI04 Supply chainNo cubierto | Registramos el proveedor, el modelo y la versión del SDK detrás de cada solicitud revisada, más un hash de lockfile opcional. No detectamos dependencias comprometidas. | |
| ASI05 Unexpected code executionNo cubierto | Ejecute el código generado en un sandbox dentro de su aplicación. | |
| ASI06 Memory and context poisoningLimitado | Se revisa el contenido envenenado que vuelve como resultado de una herramienta. No nos integramos con almacenes de memoria. | |
| ASI07 Insecure inter-agent communicationParcial | Los mensajes de otros agentes se revisan como cualquier otra entrada, y se marcan las falsas afirmaciones de autoridad. Los mensajes entre agentes no se autentican. | |
| ASI08 Cascading failuresNo cubierto | Resuélvalo en la arquitectura de su aplicación. | |
| ASI09 Human-agent trust exploitationCubierto | Se marca la presión por urgencia, autoridad, secreto o cambio de pago en los mensajes entrantes. | |
| ASI10 Rogue agentsParcial | El comportamiento se compara con la Alignment Card del agente. Los administradores pueden pausar o detener un agente, y se puede activar la pausa automática ante violaciones repetidas. |
Fuente: OWASP GenAI Security Project, genai.owasp.org.
NIST AI Risk Management Framework
Controles y registros para cada función.
El AI RMF es un marco voluntario que aplica su organización. No es una certificación. Mnemom aporta controles en tiempo de ejecución y registros que cada función puede usar.
| Función | Qué aporta Mnemom |
|---|---|
| Govern | Una política legible por máquina para cada agente (la Alignment Card), ajustes a nivel de organización, equipo y agente, y un registro de quién cambió qué. |
| Map | El propósito declarado y los límites de cada agente, y la correspondencia con OWASP de arriba. |
| Measure | Un resultado en cada punto de control en cada turno, y checkpoints de integridad firmados que puede verificar. |
| Manage | Los modos observe, nudge y enforce, y controles de pausa y parada para cada agente. |
Plataforma
Cómo protegemos la plataforma.
Registro firmado
- Cada checkpoint de integridad se firma con Ed25519 y se enlaza en una cadena de hash SHA-256 dentro de su sesión de agente, de modo que un checkpoint eliminado o reordenado es detectable.
- Cada certificado de checkpoint incluye una prueba de inclusión Merkle. Cualquiera puede comprobar un certificado con nuestro endpoint público de verificación, o comprobar su firma con cualquier biblioteca Ed25519 estándar.
- Nuestra clave pública de firma está publicada en api.mnemom.ai/v1/keys.
- Las atestaciones de agent cards se registran en un log público de solo anexado, inspirado en Certificate Transparency (RFC 6962). Su raíz firmada y sus pruebas de consistencia son públicas.
- Los webhooks se firman con HMAC-SHA256 sobre una marca de tiempo y el cuerpo.
- Las claves de firma se guardan en Azure Key Vault y se cargan en nuestros servicios mediante identidad administrada.
Infraestructura
- Cada entorno funciona como una celda autónoma con su propia red, base de datos, caché, key vault, almacenamiento y servicio de identidad. Las celdas no comparten redes.
- Las bases de datos, la caché, el key vault y el almacenamiento no tienen acceso público a internet y solo se alcanzan mediante endpoints privados.
- Todo el tráfico público nos llega a través de Cloudflare. Los orígenes de producción solo aceptan conexiones desde Cloudflare.
- Los servicios internos no tienen endpoint público.
- La base de datos de producción mantiene una réplica en espera en una segunda zona de disponibilidad. Las copias de seguridad se conservan 30 días y se copian a una segunda región.
Cifrado
- Los endpoints públicos solo aceptan TLS 1.2 y TLS 1.3. Las bases de datos, la caché y el almacenamiento solo aceptan conexiones cifradas.
- Todos los datos de clientes se cifran en reposo.
- Nuestra aplicación cifra además con AES-256-GCM los secretos de firma de webhooks y las claves de proveedores de modelos almacenadas.
Acceso
- Las organizaciones tienen cinco roles: owner, admin, member, viewer y auditor. La API comprueba la pertenencia y el rol de quien llama en cada solicitud de la organización.
- Los cambios hechos a través de la API se registran con su autor. Owners, admins y auditores pueden leer el registro de su organización.
Inicio de sesión
- Siempre inicia sesión en una página de Mnemom. El servicio de identidad funciona dentro de cada celda, y sus propias páginas de inicio de sesión y administración no son accesibles desde internet.
- Passkeys (solo guardamos la clave pública) y MFA con app de autenticación. Desactivar la MFA, eliminar una passkey o cerrar otras sesiones requiere una nueva verificación del segundo factor.
- Las sesiones del navegador usan una cookie cifrada, HttpOnly y Secure que caduca tras 7 días de inactividad y como máximo a los 30 días. Le avisamos por correo cuando su cuenta inicia sesión en un dispositivo nuevo.
- Las claves de API se muestran una vez y solo se guardan como hash SHA-256. Tienen ámbitos y puede revocarlas o rotarlas en cualquier momento.
- El inicio de sesión de la CLI y de los agentes usa OAuth con PKCE o el flujo de código de dispositivo.
Cómo desplegamos
- Los cambios de producción pasan por un único pipeline de despliegue. Una versión llega a producción solo después de que la apruebe un ingeniero identificado o, para cambios clasificados como de bajo riesgo, después de superar un canary automatizado.
- Las ramas principales exigen comprobaciones automatizadas, incluido el escaneo de secretos.
- Nuestra organización de GitHub exige autenticación de dos factores. El acceso a los recursos cloud de producción se limita a unas pocas personas identificadas y a identidades de automatización con permisos acotados. Las herramientas internas están detrás de Cloudflare Access.
Cumplimiento
Preparados para el cumplimiento de SOC 2 Tipo II, RGPD e HIPAA. Auditoría independiente en curso. Los cuestionarios de seguridad y la evidencia de controles están disponibles bajo NDA.
EU AI Act: artículos 10 y 12 y anexo IV mapeados al registro firmado. Un mapeo técnico, no una certificación.
Ver la página TrustReportar una vulnerabilidad
Escriba a [email protected]. Nuestra política de divulgación está en nuestro security.txt y en la página Trust.
[email protected]Muévete rápido. Mantente en pie.
Sepa qué están haciendo realmente sus agentes, antes de que lo pregunte el board.
Dos comandos para instalar. Un registro firmado desde la primera decisión.
