La decisión
Trate documentos, correos y salida del modelo como entradas no confiables. Un texto puede describir una orden sin estar autorizado a darla. OWASP identifica inyección y autonomía excesiva como riesgos; los límites deben existir fuera del prompt.
Un ejemplo práctico
Un correo ficticio pide ignorar reglas y exportar clientes. Es material para analizar, no autoridad. Aunque el modelo solicite exportar, la aplicación verifica derechos del usuario, destino y acción aprobada.
Alternativas que conviene valorar
Un asistente de lectura tiene menos acciones posibles. Para escribir, exponga una herramienta limitada, parámetros validados y confirmación clara. Un formulario convencional puede servir mejor a decisiones delicadas.
Dónde falla el plan
No ponga credenciales en el prompt ni use “no reveles secretos” como control. Limite herramientas, reduzca datos y separe empresas antes de recuperar información. Pruebe instrucciones hostiles en adjuntos.
Haga que el permiso pertenezca al comando
Defina capacidades acotadas, como consultar pedidos propios o preparar un borrador. Obtenga usuario y organización de la sesión autenticada, no del correo ni de parámetros propuestos por el modelo. Compruebe en servidor la propiedad del registro. Permitir un nombre de herramienta no basta si sus parámetros pueden dirigirla a otro cliente, destino o conjunto de datos.
Muestre una vista previa de acciones importantes. Vincule la aprobación al registro, operación y parámetros concretos, no a un “sí” genérico. Si cambian parámetros o estado, pida otra decisión. La lectura también puede revelar información: controle permisos durante búsqueda y devolución de pasajes, no solo al escribir.
Ensaye el rechazo y una suspensión segura
Prepare un adjunto hostil ficticio que solicite datos de otra cuenta y pruébelo junto a una petición legítima. No use datos reales. Debe impedirse toda lectura, escritura o envío no autorizado aunque el modelo solicite una herramienta inapropiada. Examine si el propio error revela la existencia de registros protegidos.
Permita desactivar una herramienta o fuente manteniendo partes seguras del producto. Defina qué ocurre con trabajos en cola al revocar acceso. Registre referencias, decisiones de permiso y errores seguros con acceso limitado, sin secretos ni documentos innecesarios. Repita la revisión al añadir capacidades. Una prueba superada reduce riesgos conocidos; no demuestra haber eliminado la inyección de instrucciones.
Antes de encargar el trabajo
¿Qué lee, cambia y envía? ¿Qué impone el servidor? ¿Qué evidencia deja un rechazo? Revise al cambiar herramientas o fuentes en la integración de IA.