Un modelo de lenguaje procesa instrucciones y datos en forma de texto o contenido multimodal. Esta flexibilidad crea una ambigüedad fundamental: un documento consultado puede contener una frase que se parezca a una instrucción. Un agente puede entonces interpretar un dato externo como un comando, intentar acceder a una herramienta o revelar información.
La inyección de prompt no se resuelve con un prompt de sistema más firme. El modelo sigue siendo un componente probabilístico. La seguridad consiste en limitar sus poderes, aislar las fuentes, verificar las acciones e impedir que un error de interpretación produzca un impacto.
Inyección directa e indirecta
Una inyección directa es introducida por el usuario en la conversación para eludir las reglas. Una inyección indirecta está oculta en un correo electrónico, una página web, un documento, una imagen o un resultado de herramienta que el sistema consulta.
La inyección indirecta es particularmente importante para los agentes: el contenido malicioso puede provenir de una fuente que el usuario cree legítima. El modelo no debe otorgarle el mismo nivel de confianza que a las políticas del sistema.
Las consecuencias posibles
Según las herramientas y datos accesibles, una inyección puede provocar:
- divulgación de información del contexto;
- envío a un destino externo;
- acción no autorizada ;
- modificación de datos ;
- memorización de una instrucción persistente ;
- uso abusivo de un recurso;
- respuesta engañosa;
- eludir una validación;
- saturación o gasto excesivo.
Un chatbot sin herramienta tiene un alcance de impacto más reducido que un agente capaz de enviar correos electrónicos o ejecutar código. El riesgo se mide por los poderes, no solo por la probabilidad de una mala respuesta.
Cartografiar las fronteras de la confianza
El esquema debe distinguir:
- instrucciones del sistema y políticas;
- entrada del usuario;
- contenido recuperado;
- memoria ;
- salidas de modelos ;
- herramientas;
- secretos ;
- servicios externos;
- validaciones humanas.
Cada flujo especifica su origen, su nivel de confianza, sus transformaciones y las acciones que puede influenciar. Un contenido no confiable nunca debe modificar una política o una lista de herramientas.
Capas de defensa independientes que limitan las consecuencias de una inyección rápida.
Separar instrucciones y datos
El sistema delimita claramente los contenidos recuperados e indica al modelo que no son instrucciones. Esta técnica reduce algunos riesgos, pero no es una garantía.
La verdadera protección proviene de la arquitectura: incluso si el modelo sigue una instrucción maliciosa, no tiene el acceso o la autorización necesaria para producir el impacto.
Las salidas de un modelo son en sí mismas poco fiables cuando alimentan una herramienta. Deben ser validadas como cualquier entrada externa.
Reducir el contexto
Cuantos más datos recibe el modelo, mayor es la superficie de exposición y el riesgo de fuga. El RAG debe recuperar únicamente los pasajes necesarios y autorizados. Los secretos no se añaden al contexto por conveniencia.
La memoria conserva lo mínimo y tiene una duración. Las conversaciones de varios usuarios o carpetas están aisladas. Los datos antiguos se leen de nuevo desde su fuente antes de una acción.
Diseñar herramientas con privilegios mínimos
Una herramienta debe:
- realizar una acción precisa;
- verificar la identidad;
- validar un esquema estricto;
- limitar el alcance ;
- aplicar las reglas de negocio;
- ser idempotente ;
- registrar en un diario;
- devolver un resultado estructurado.
Las herramientas genéricas de shell, SQL, navegador libre o consulta HTTP arbitraria están prohibidas por defecto. Cuando se debe ejecutar código, se hace en un entorno aislado, efímero y sin acceso innecesario a la red.
Controlar los destinos
Las capacidades de envío, de descarga y de publicación son canales de exfiltración. Los destinatarios, dominios, buckets, URL y tipos de archivos están limitados por una política independiente.
El agente no puede crear él mismo un destino autorizado. Los nuevos destinos requieren una acción administrativa distinta.
Proteger los secretos
Las claves no están presentes en el aviso ni son devueltas por las herramientas. Un servicio del lado del servidor realiza la llamada y limita las operaciones. Los registros ocultan los secretos y los parámetros sensibles.
Las cuentas técnicas tienen permisos mínimos, rotación y supervisión. Una supuesta filtración desencadena una revocación rápida.
Validar las salidas estructuradas
Una llamada de herramienta debe respetar un esquema: tipos, valores, formatos, longitudes y relaciones. Los campos desconocidos son rechazados. Los valores críticos se recalculan o se vuelven a leer desde la fuente.
Un JSON válido no es necesariamente permitido. El motor de políticas verifica usuario, recurso, cantidad, destino y contexto.
Añadir aprobaciones proporcionales
Las acciones reversibles y de bajo riesgo pueden ejecutarse automáticamente. Las acciones sensibles se previsualizan y se confirman. Las acciones de alto impacto requieren una aprobación independiente.
La validación está vinculada a los parámetros exactos y expira. Una instrucción externa no puede producir una aprobación implícita.
Aislar la navegación y el código
Un agente que consulta la web o ejecuta código debe usar una caja de arena con:
- sistema de archivos efímero;
- red limitada;
- duración y recursos limitados;
- ninguna llave general;
- descargas controladas;
- resultado filtrado;
- diario de actividad.
Los documentos activos, scripts y macros no se ejecutan en el contexto principal.
Asegurar la memoria
Una inyección puede pedir registrar una regla para las conversaciones futuras. Las escrituras de memoria están separadas, son limitadas y a veces están sujetas a validación. Cada elemento tiene procedencia, fecha, propietario y alcance.
El sistema puede distinguir preferencias del usuario, hechos verificados y resúmenes generados. Una salida del modelo no se convierte en una verdad duradera sin reglas.
Controlar los conectores y MCP
Un servidor de herramientas remoto es un proveedor de código y datos. Debe ser inventariado, autenticado, evaluado y limitado. Los metadatos de una herramienta no son automáticamente confiables.
Los tokens son específicos del servidor y del usuario. Se supervisan las redirecciones, los consentimientos, los cambios de capacidades y las actualizaciones. Un servidor no puede solicitar secretos destinados a otro.
Detectar sin depender de la detección
Los filtros pueden detectar ciertas formulaciones, ámbitos o comportamientos. Son útiles para la alerta, pero un atacante puede variar la forma. La política debe permanecer segura incluso si la detección falla.
Se supervisan las anomalías de volumen, destino, herramienta, costo y rechazo. Un mecanismo de corte desactiva rápidamente una capacidad.
Probar de manera adversarial
El red teaming cubre:
- contenido no confiable en cada fuente;
- intentos de cambio de rol;
- solicitudes de secreto;
- herramientas en cadena;
- datos codificados ;
- memoria ;
- idiomas y formatos ;
- errores y tiempos de espera;
- aprobaciones ;
- destinos.
Las pruebas deben ser autorizadas, aisladas y orientadas hacia los controles. Los casos detectados se convierten en regresiones automatizadas sin conservar datos sensibles.
Preparar el incidente
El plan prevé corte de las herramientas, revocación de los tokens, conservación de las pruebas, análisis de las acciones, notificación y restauración. El registro vincula identidad, contenido, modelo, herramientas, parámetros y resultado.
Un error de modelo puede desencadenar una acción comercial; por lo tanto, el equipo de seguridad y el equipo de producto deben compartir los procedimientos.
Aceptar el riesgo residual
Ninguna combinación garantiza que un modelo nunca seguirá una instrucción. El objetivo es que este error no permita una acción prohibida o una fuga significativa.
Algunas capacidades siguen siendo demasiado arriesgadas y deben ser excluidas, limitadas a una propuesta o reservadas a un entorno aislado.
La seguridad viene de las fronteras
Un sistema seguro considera el modelo como un intérprete no confiable, útil pero limitado. Las políticas, derechos, validaciones y herramientas siguen siendo deterministas y auditables.
Partitech puede realizar el modelado de amenazas, diseñar los controles, asegurar los conectores y poner en marcha las pruebas de agentes y de RAG. La defensa en profundidad protege el sistema incluso cuando el modelo se equivoca.
Hablemos de su proyecto
Auditar la seguridad de su RAG o de sus agentes con Partitech. Contacte a Partitech.