Prompt injection influye en lo que un modelo quiere hacer. El incidente ocurre cuando el sistema que lo rodea permite que ese modelo influenciado use la autoridad de otra persona para leer datos, llamar tools o cambiar estado.
NIST define prompt injection como un ataque que explota la combinación de input no confiable con un prompt creado por una parte de mayor confianza. Su trabajo sobre secuestro de agentes muestra la consecuencia operacional: instrucciones maliciosas dentro de datos pueden hacer que un agente ejecute acciones no deseadas. Una presentación de seguridad de NIST de 2026 va más allá y describe prompt injection indirecta como generalmente ligada a un problema de confused deputy.
El deputy es el agente. Puede leer la bandeja del usuario, consultar datos internos, llamar una tool MCP o aprobar un workflow porque el sistema le entregó credenciales. El atacante no necesita esas credenciales directamente. Solo necesita influir al deputy que ya las posee.
Clasificadores, prompts estructurados, sanitización de contenido, entrenamiento del modelo y red teaming importan. Google describe una defensa en capas que también incluye confirmación para operaciones riesgosas. Anthropic advierte explícitamente que ningún agente de navegador es inmune a prompt injection. Eso significa que el diseño backend debe asumir que una instrucción maliciosa ocasionalmente alcanzará el loop de planificación.
Autorización es la frontera determinista después de esa falla probabilística. Cada acción propuesta debe verificarse contra el principal original, tarea actual, recursos permitidos, destino, clase de datos, nivel de efecto secundario, presupuesto y vencimiento. El modelo puede sugerir una acción; no puede otorgarse permiso a sí mismo.
Que un usuario apruebe “ayúdame con mi correo” no significa que apruebe cada acción futura que un email instruya al agente a ejecutar. La autorización no puede inferirse por proximidad conversacional. Debe evaluarse nuevamente en la frontera de acción, con credenciales limitadas a esa acción y suficientemente cortas para vencer con la tarea.
El diseño más útil separa lectura de datos de ejecución de acciones. Un componente de bajo privilegio inspecciona documentos no confiables. Un ejecutor privilegiado recibe una propuesta estructurada y verifica política sin heredar las instrucciones del documento. Acciones de alto riesgo requieren un canal independiente de aprobación que muestre objetivo, efecto secundario y datos liberados.
| Capa | Control | Qué previene o contiene |
|---|---|---|
| Frontera de input | Clasificadores, sanitización, etiquetas de procedencia y separación entre instrucción y dato. | Reduce la posibilidad de que contenido hostil influya al modelo. |
| Identidad del agente | Identidad dedicada, principal responsable y credenciales cortas por tarea. | Evita acciones anónimas o permanentemente privilegiadas. |
| Tool gateway | Autorización por acción, validación de argumentos y allowlists de destinos. | Bloquea acciones fuera de la intención incluso tras comprometer el modelo. |
| Frontera de datos | Controles de acceso por fila, tenant, campo y finalidad. | Limita lo que un agente secuestrado puede leer o divulgar. |
| Frontera de aprobación | Confirmación adicional para acciones destructivas, externas o financieras. | Impide uso silencioso de privilegios y hace visibles efectos secundarios. |
| Frontera de evidencias | Registra principal, procedencia del input, decisión, tool call, resultado y política. | Hace detectables y reconstruibles los incidentes de confused deputy. |
Construiría un broker de autorización frente a cada tool de agente. El broker cambiaría la sesión amplia del usuario por un capability token estrecho, ligado a una tarea, una tool, recursos permitidos, destinos aprobados, clase máxima de efecto secundario y vencimiento corto. Cada tool call se verificaría de forma independiente.
El producto visual de seguridad mostraría dos traces para cada acción: el trace de influencia, explicando qué input del usuario, documento recuperado, memoria u output de tool moldeó la propuesta; y el trace de autoridad, explicando qué identidad, scope, política y aprobación permitió o negó la ejecución.
Quizás no sea posible garantizar que un agente nunca crea una instrucción hostil. Sí es posible garantizar que creerla no sea suficiente para obtener autoridad. Prompt injection se vuelve manejable cuando influencia del modelo y permiso backend se tratan como sistemas separados.
Artículo de seguridad de agentes de IA que explica prompt injection como problema de autorización tipo confused deputy, con least privilege, capability tokens, autorización por acción, aprobación humana y traces de influencia y autoridad.