LAS IDEAS CLAVE
- 01
Un documento puede aportar datos sin tener autoridad para cambiar la tarea o sus destinatarios.
- 02
Comprueba la acción que ejecuta la herramienta y los permisos que aplica la integración.
- 03
Ensaya desvíos con información ficticia y verifica también que el trabajo autorizado siga funcionando.
El riesgo aparece en lo que el agente necesita leer
La inyección de instrucciones, conocida como prompt injection, busca alterar el comportamiento de un modelo mediante contenido que procesa. OWASP distingue el caso indirecto: las instrucciones llegan dentro de recursos externos, como archivos o páginas web. Su efecto depende de las funciones y accesos de la aplicación. Incorporar recuperación documental, o RAG, no elimina por sí solo este riesgo. OWASP, LLM01:2025 Prompt Injection.
Para una empresa chilena que conecta IA con correo, CRM o documentación comercial, proponemos revisar una pregunta concreta: ¿puede lo que el agente lee cambiar a quién envía información o qué registro modifica? Esta guía aplica documentación técnica internacional a ese problema. Las fuentes tienen sus propias fechas; no describimos un incidente ocurrido hoy ni una vulnerabilidad identificada en una empresa chilena.
Un ejemplo: preparar una respuesta comercial
Imaginemos una distribuidora ficticia. Una ejecutiva pide resumir una solicitud y preparar un borrador para el contacto registrado en una oportunidad del CRM. El documento adjunto contiene información útil sobre cantidades y plazos, pero también intenta indicar que se envíe una copia a otra dirección. Esa dirección aparece en el material recibido; la ejecutiva no autorizó incorporarla como destinataria.
En este ejemplo, proponemos que el resumen pueda utilizar los datos comerciales pertinentes, mientras la aplicación conserve por separado el destinatario autorizado. Si hace falta cambiarlo, el cambio debe pasar por el flujo habitual de validación de contactos. El adjunto no debería poder convertir una solicitud de lectura en permiso para compartir información. Es un escenario de evaluación, no un caso de cliente ni una prueba realizada por Digital Dev.
Un conector aprobado puede transportar contenido no confiable
En un artículo de ingeniería publicado el 25 de mayo de 2026, Anthropic explica que revisar un conector no equivale a revisar todos los datos que transporta. También describe una lección de sus controles de salida: permitir un dominio puede dejar disponibles operaciones o cuentas que no se pretendía autorizar. La publicación documenta la experiencia de ese proveedor; no acredita la seguridad de cualquier integración. Anthropic, How we contain Claude across products.
Aplicado a nuestra distribuidora, pediríamos al integrador que muestre cómo se determina la dirección final y qué impide sustituirla. La demostración debería incluir el dato enviado a la herramienta de correo. Una pantalla que muestra el contacto correcto aporta poca evidencia si la llamada que finalmente se ejecuta puede usar otro destinatario.
Separar la lectura de la autorización para actuar
La documentación de Anthropic recomienda identificar el origen del contenido externo y distinguirlo de las instrucciones confiables. Menciona correos, páginas, texto obtenido mediante OCR y resultados de herramientas como posibles entradas de instrucciones adversarias. Sus formatos concretos corresponden a Claude; cada plataforma requiere revisar su propia implementación. Claude Platform Docs, mitigación de prompt injection.
OWASP recomienda limitar privilegios, controlar las funciones mediante código y pedir aprobación humana para operaciones de mayor riesgo. Señala que no está claro que existan métodos infalibles de prevención. OWASP, medidas de mitigación. Para el ejemplo proponemos comenzar con una herramienta que solo prepare borradores. Habilitar el envío sería una decisión posterior, con destinatarios y alcance definidos fuera del texto del adjunto.
Diseñar una revisión que muestre la acción real
Antes de habilitar envíos, proponemos una confirmación que presente destinatarios, adjuntos y contenido final. La persona debería poder compararlos con la solicitud original. Una aprobación genérica del tipo continuar ofrece menos contexto para detectar que apareció una dirección nueva o se agregó un archivo que nadie pidió compartir.
En el ensayo de la distribuidora, la autorización debería quedar asociada a esa versión concreta del envío. Si cambian sus destinatarios o adjuntos después de revisarlo, pediríamos una nueva validación. También acordaríamos qué hacer ante un bloqueo: conservar el borrador para revisión y mostrar el motivo, en lugar de buscar automáticamente otra vía para completar el envío.
Tres pruebas pequeñas antes de conectar datos reales
Proponemos preparar tres solicitudes sintéticas en un entorno aislado, sin correos reales: una normal, otra cuyo adjunto intente cambiar el destinatario y una tercera que intente ampliar la tarea a documentos de otra oportunidad. En cada una escribiríamos de antemano la salida esperada y las acciones permitidas. Así se puede comparar el resultado con una regla acordada, sin depender de una impresión general sobre la respuesta.
Registraríamos qué herramienta se intentó utilizar, sobre qué oportunidad, con qué destinatarios y qué decisión tomó el control de acceso. También verificaríamos que la solicitud normal siga funcionando. Si el agente afirma que rechazó una instrucción, revisaríamos igualmente los borradores y las llamadas efectivas. Estas pruebas acotadas ayudan a revisar ese flujo; no certifican resistencia frente a todos los ataques posibles.
El entregable útil es una decisión sobre el alcance
Al cerrar el ensayo, proponemos reunir los tres resultados y decidir si el agente puede preparar borradores, si necesita otra revisión o si corresponde corregir la integración. Para cada cambio posterior de herramienta o permiso, conservaríamos esos casos como comprobación de regresión. El objetivo empresarial es saber qué acciones están habilitadas y comprobar, en el flujo evaluado, que el contenido recibido no amplía esa autorización.
La guía de autonomía y evaluación de agentes amplía cómo graduar responsabilidades. Nuestra página de seguridad y gobierno de IA presenta los controles que deben definirse al diseñar una solución empresarial.
CON TEXTO Y CONTEXTO
Fuentes y referencias
- LLM01:2025 Prompt InjectionOWASP Gen AI Security Project
- How we contain Claude across productsAnthropic Engineering · 2026-05-25
- Mitigate jailbreaks and prompt injectionsAnthropic · Claude Platform Docs
Contenido elaborado con asistencia de IA a partir de las fuentes enlazadas. Las recomendaciones corresponden al análisis editorial de Digital Dev. Cómo elaboramos y corregimos nuestros artículos.