Seguridad de agentes en Copilot Studio: checklist de inyección de prompts

📋 En resumen

Para quién: responsables de seguridad y arquitectos que despliegan agentes de Copilot Studio expuestos a entrada de usuario no confiable
Tiempo de lectura: ~7 minutos
Qué vas a sacar: cómo defender un agente de Copilot Studio de la inyección de prompts — scoping, autenticación forzada, Prompt Shields, spotlighting y Microsoft Purview, en una checklist práctica

Un agente de Copilot Studio no necesita que nadie lo "hackee" para filtrar datos: le basta con leer un documento que otra persona ha manipulado. Eso es la inyección de prompts. En una organización con datos regulados en España, deja de ser solo un problema técnico en el momento en que Legal o Seguridad tienen que explicar qué pasó. La protección "segura por defecto" de Copilot Studio es real y funciona bien — también es el suelo, no el techo, y ahí es donde se equivocan la mayoría de despliegues que veo.

¿Qué es la inyección de prompts y por qué un agente de Copilot Studio puede filtrar datos sin que nadie lo "hackee"?

La inyección de prompts consiste en esconder instrucciones dentro del texto que el agente procesa, de forma que el modelo abandona su tarea real y sigue la instrucción del atacante. Microsoft distingue dos variantes: UPIA, cuando alguien escribe algo hostil directamente en el chat, y XPIA, cuando la instrucción hostil viaja escondida dentro de un archivo, un correo o una web que el agente lee. XPIA es la que de verdad preocupa, porque la persona que interactúa con el agente no ha hecho nada malo — el problema entró por un documento que el agente tenía permiso para leer.

Un agente de Copilot Studio es vulnerable por la razón exacta que lo hace útil: busca en tu SharePoint, llama a un conector, responde en Teams. Eso es, por diseño, un camino directo desde un input sin verificar hasta una acción con privilegios. La documentación de seguridad y gobernanza de Copilot Studio es el punto de partida antes de configurar nada.

¿Basta con la protección "segura por defecto" que trae Copilot Studio?

En parte, y es mejor de lo que la mayoría asume. Los agentes con orquestación generativa incluyen protección en tiempo de ejecución contra UPIA y XPIA: clasificadores de contenido, respuestas ancladas en datos con permisos y barreras sobre acciones fuera de alcance, activado desde el primer día.

Pero "bloquear" aquí significa "detectar y frenar la mayoría de patrones conocidos", no "hacerlo matemáticamente imposible". Los clasificadores fallan con frases nuevas, y las técnicas de codificación siguen siendo una vía de evasión conocida. Microsoft lo dice sin rodeos en su guía para defenderse de la inyección indirecta de mensajes: ningún control por sí solo es suficiente. Se combinan defensas probabilísticas con controles deterministas — política, identidad, red — para que cuando una capa falle, otra lo pare.

Lo que veo repetirse: un agente sale rápido para resolver una necesidad real, con más acceso del que necesita porque abrirlo del todo fue más rápido que acotarlo. La autenticación está bien, pero el spotlighting sigue apagado y Purview es "fase dos". Nada falla durante meses — hasta que alguien apunta el agente a una biblioteca donde un atacante puede dejar contenido. Lo más barato de arreglar esto: un agente más pequeño. Uno que solo lee tres bibliotecas verificadas y llama a un conector es mucho más fácil de defender que uno conectado a "todos los datos de la empresa". Cada capacidad que le quitas es una vía de ataque menos.

¿Cómo se obliga la autenticación y las políticas de datos, sin fiarse de que cada maker lo configure bien?

Abre Configuración → Seguridad → Autenticación en el agente y confirma que no está en "Sin autenticación". El valor por defecto para agentes nuevos es "Autenticar con Microsoft" (Entra ID): la documentación de autenticación de usuario final advierte que "sin autenticación" significa que cualquiera con el enlace puede hablar con el agente — y uno sin autenticar que toca datos internos es un pasivo, no una comodidad.

No des por hecho que cada maker lo va a configurar bien. Fuérzalo a nivel de plataforma: en el Centro de administración de Power Platform se configura una directiva de datos que bloquea el conector "Chat sin autenticación de Microsoft Entra ID", de forma que un maker no puede publicar un agente anónimo. La misma superficie permite bloquear orígenes de conocimiento, peticiones HTTP directas y conectores concretos — cada una cierra una vía de fuga distinta.

¿Qué aportan Prompt Shields y el "spotlighting" en agentes construidos sobre Azure AI?

Si la lógica del agente corre sobre modelos de Azure AI Foundry, activa Escudos de avisos. Analiza tanto los ataques directos como los indirectos escondidos en documentos, y clasifica los intentos de cambiar las reglas del sistema o disfrazar instrucciones dentro de un rol.

Después activa el "spotlighting", descrito en la documentación de los filtros de contenido con escudos de instrucciones. Etiqueta los documentos ingeridos para que el modelo los trate como una fuente de menor confianza que las instrucciones del sistema o del usuario directo. Viene apagado por defecto y cuesta algunos tokens de más — y es uno de los interruptores con más impacto que casi nadie activa, porque le dice al modelo "esto es un dato, no una instrucción".

¿Por qué Microsoft Purview es la barrera que no depende de que el modelo acierte?

Este es el respaldo determinista, y merece la pena entender cómo gobierna Purview las cargas de trabajo de IA de principio a fin antes de acotar la política. Microsoft Purview para Copilot Studio aplica etiquetas de confidencialidad y DLP sobre las interacciones del agente: una política acotada a la ubicación de Microsoft 365 Copilot puede impedir que procese contenido con una etiqueta concreta, incluso cuando alguien ha conseguido engañarlo para que la pida.

La secuencia importa. La inyección vence el criterio del modelo; Purview no depende de ese criterio. Cuando el clasificador falla, un bloqueo basado en etiquetas todavía puede impedir que salgan datos regulados — y conservas el rastro de auditoría en Purview y, si lo conectas, en Sentinel.

¿Merece la pena la detección de amenazas externas para agentes de alto riesgo?

Para agentes que tocan sistemas sensibles, Copilot Studio permite conectar detección de amenazas externa: cada vez que el orquestador plantea invocar una herramienta, llama a un endpoint externo que responde permitir o bloquear — Microsoft Defender, un proveedor externo o tu propio servicio.

Un detalle que muerde: en "Configurar comportamiento en caso de error", el valor por defecto es "Permitir que el agente responda" si el servicio no contesta en un segundo. Para un agente de riesgo alto, cámbialo a "Bloquear la consulta". Falla cerrado, no abierto. Se configura por entorno, sin interruptor a nivel de tenant — cada entorno nuevo arranca sin esta protección hasta que la activas tú.

¿Cómo se detecta un intento de inyección ya en producción?

Da por hecho que algún ataque va a colarse e instrumenta para eso. La protección contra amenazas de IA de Microsoft Defender para la nube trabaja junto a Escudos de avisos para levantar alertas en tiempo real ante jailbreak y fuga de datos, y las envía a Defender XDR — junto al resto de incidentes, no a un panel aparte que nadie mira.

La checklist que sostengo en cualquier revisión

Por dónde empezar en un tenant que ya tiene agentes en producción: inventario de qué agentes existen y qué pueden leer, autenticación forzada por directiva de datos (no por confianza en el maker), spotlighting donde aplique, y una política de DLP de Purview sobre las etiquetas que de verdad importan. Esos cuatro movimientos quitan la mayor parte del riesgo con el menor esfuerzo, y ninguno obliga a reconstruir el agente.

Y aquí va la parte que no suelo dulcificar: la inyección de prompts no es un fallo que se parchea una vez, es una consecuencia de dar a un modelo de lenguaje acceso a texto que no controlas. O la defiendes en capas, o no la has defendido. La protección de fábrica es real y hay que usarla — es la primera capa de seis, no la pared entera. Cuando el clasificador falla, quieres que la instrucción maliciosa se choque contra un control que no dependía de que el modelo estuviera de buen humor ese día.

Preguntas frecuentes

¿Microsoft 365 Copilot tiene el mismo riesgo que un agente personalizado de Copilot Studio?

Copilot hereda protecciones fuertes de tenant y está más acotado, porque no conectas conectores ni orígenes de conocimiento arbitrarios. Un agente a medida carga más riesgo porque quien lo construye puede ampliar su alcance sin límite natural.

¿Activar spotlighting o la detección de amenazas externa rompe el agente?

En uso normal, no. El spotlighting añade tokens y reclasifica documentos como de menor confianza; el matiz es que documentos muy grandes pueden acercarse al límite de entrada. La detección externa añade una comprobación de menos de un segundo antes de cada llamada a herramienta. Pruébalo fuera de producción primero, sobre todo el comportamiento en caso de error.

¿Un system prompt bien escrito basta para parar la inyección?

No. Sube el listón y merece la pena escribirlo bien, pero sigue siendo un control probabilístico dentro del mismo modelo que el atacante manipula. Complétalo siempre con controles deterministas: DLP, autenticación forzada, acceso acotado.

Si ya tenemos agentes en producción, ¿por dónde empezamos?

Por un inventario: qué agentes existen, qué pueden leer, qué conectores tienen colgados. Después, autenticación forzada por directiva de datos, spotlighting donde el agente corra sobre Azure AI, y DLP de Purview sobre tus etiquetas más sensibles. Ninguno de los cuatro pasos requiere reconstruir nada. La lista de verificación de gobernanza de agentes de Microsoft 365 es una buena estructura para esa primera pasada.