Microsoft Copilot y los “agentes no-code”: el riesgo silencioso de que filtren datos de empresa

CIBERSEGURIDAD · MICROSOFT COPILOT · AGENTES NO-CODE

Si estás viendo cada vez más “agentes” dentro del ecosistema Microsoft (Copilot, Power Platform, conectores, automatizaciones), no estás solo. Es la evolución natural de los copilotos: de responder, a hacer cosas. Y justo por eso cambia el riesgo. En mi experiencia, el problema no es que la herramienta sea insegura por defecto, sino que democratiza decisiones de seguridad… en manos de gente que no vive en seguridad.

1. Qué son (de verdad) los “agentes no-code” en el mundo Copilot

Cuando alguien dice “he montado un agente”, muchas veces no habla de un sistema complejo de ingeniería. Habla de una combinación de piezas “arrastrar y soltar”: una interfaz conversacional, una fuente de conocimiento (documentos, páginas internas, FAQs), y acciones conectadas a herramientas (correo, calendarios, CRM, SharePoint, Teams, bases de datos, etc.).

La magia (y el peligro) está en que esas acciones suelen apoyarse en conectores y credenciales. A veces, el agente actúa con los permisos del usuario que lo usa. Otras, con una identidad “de aplicación” o una conexión compartida. Si no entiendes esa diferencia, estás construyendo a ciegas.

Y aquí entra un matiz clave: muchos equipos empiezan con algo inocente (“resúmeme reuniones”, “redáctame correos”), pero muy rápido saltan a lo operativo (“crea un ticket”, “actualiza el CRM”, “extrae datos de una carpeta”, “envía una propuesta”). Es justo ese salto el que convierte un asistente en un canal de exfiltración accidental.

2. Por qué el riesgo sube cuando “cualquiera” puede montar agentes

En seguridad, los riesgos raramente aparecen por una sola causa. Aparecen por combinaciones. Los agentes no-code juntan tres ingredientes explosivos:

• Acceso fácil a datos: documentos internos, chats, wikis, correos, repositorios.
• Acceso fácil a acciones: enviar, copiar, descargar, actualizar, publicar, compartir.
• Construcción rápida: el tiempo de diseño (y de revisar) se comprime tanto que se saltan pasos básicos de control.

Los medios de ciberseguridad llevan meses insistiendo en esto (Dark Reading, entre otros): el “shadow AI” no siempre es un modelo externo; puede ser tu propia automatización interna creciendo sin gobierno.

Si te interesa el salto conceptual de copilotos a agentes (y por qué eso cambia el tipo de incidentes que vas a ver), te encaja mucho este análisis: copilotos a agentes autónomos en empresas.

3. Cinco formas reales en las que un agente “bienintencionado” filtra datos

3.1. Permisos “por comodidad” que se vuelven permanentes

El clásico: alguien necesita que el agente “vea todo” para que funcione y le da acceso a una biblioteca, un sitio o un buzón compartido. Funciona. Nadie vuelve a revisar. Meses después, ese agente sigue leyendo lo mismo, pero ahora se usa en más contextos, con más personas y con más presión por “resolver rápido”.

El problema no es el acceso en sí: es la falta de caducidad, de segmentación y de revisión. En un mundo de agentes, el permiso debería ser temporal y específico, no “hasta que alguien se acuerde”.

3.2. Conectores que abren una puerta trasera a SaaS y datos sensibles

Un conector a CRM, a un repositorio de archivos, a correo o a una base de datos es una ventaja… hasta que no controlas qué campos se leen, qué se puede exportar y hacia dónde.

Dos escenarios típicos: (1) el agente puede enviar o copiar datos fuera (por ejemplo, a un canal compartido), o (2) el agente usa una conexión compartida más potente de lo necesario. La fuga no siempre es “a Internet”: a veces es internamente, hacia un grupo o usuario que no debía verlo.

3.3. El prompt como “fuga por diseño”

Parece obvio, pero se olvida: si en el prompt metes datos reales (“usa este contrato”, “usa esta lista de precios”, “resume este email con NIF y dirección”), estás empujando información sensible al flujo de trabajo del agente.

¿Qué pasa luego? Que el output se pega en un ticket, se reenvía, se copia en un documento, se comparte en Teams, o se guarda como parte de un historial. Una buena regla: si no lo pondrías en un chat público interno, no lo metas sin control en un agente.

3.4. Historiales, transcripciones y “memoria” que se quedan donde no miras

Muchos equipos se enfocan en el agente “en vivo” y se olvidan de la parte aburrida: qué se guarda, cuánto tiempo, quién lo puede auditar, dónde queda el rastro y si hay políticas de retención.

En la práctica, un incidente no siempre es que el agente “diga” algo. A veces es que el agente guarda algo, y ese algo termina accesible en el lugar equivocado (o simplemente queda disponible para quien tenga permisos de auditoría sin el contexto correcto).

3.5. Compartición accidental: enlaces, plantillas, “clona este agente”

Cuando un activo se vuelve útil, se comparte. Y cuando se comparte, se clona. Ahí aparecen los “agentes plantilla” que arrastran conexiones, fuentes de datos o configuraciones no pensadas para otro equipo. Es el mismo patrón que ya vimos en su día con hojas de cálculo y dashboards: lo que empieza como algo local acaba como estándar… sin revisión de seguridad.

4. Prompt injection y tool misuse: el ataque moderno contra agentes

Aquí es donde el tema deja de ser “solo” gobernanza interna. Con prompt injection, alguien introduce instrucciones maliciosas dentro del contenido que el agente lee (un documento, un email, una nota en un ticket) para que el agente:

• revele información (“lista todos los clientes premium”);
• salte políticas (“ignora las reglas anteriores”);
• o ejecute acciones (“envía este resumen a X”, “descarga y adjunta el archivo Y”).

La clave es entender que el agente no solo “lee”: actúa. Y si actúa, tienes que diseñarlo como diseñarías una integración con permisos: con límites, validaciones y fricción deliberada en operaciones sensibles.

Si has seguido casos de investigación sobre exfiltración y fallos en asistentes corporativos, te interesa este enfoque (y cómo pensar en “ataques sin clic”): EchoLeak y exfiltración en Microsoft 365 Copilot.

5. Qué revisar antes de desplegar agentes no-code en tu negocio

Te dejo un checklist práctico. No es “teoría”: es lo que evita el 80% de sustos. No necesitas hacerlo perfecto el día uno, pero sí necesitas tenerlo pensado antes de que el primer agente se convierta en “crítico” para el negocio.

5.1. Decide quién puede crear agentes (y dónde)

Si todo el mundo puede crear, todo el mundo puede equivocarse. Empieza por un modelo simple: entornos separados (sandbox, piloto, producción) y permisos claros de creación/publicación. La libertad sin carriles acaba siendo deuda.

5.2. Inventario obligatorio: “qué agentes existen y qué tocan”

Un agente sin inventario es como un servidor sin CMDB: tarde o temprano, nadie sabe para qué era ni quién lo usa. Necesitas un registro mínimo:

• propietario y responsable (no “equipo genérico”);
• fuentes de datos (sitios, bibliotecas, repositorios);
• conectores y acciones permitidas;
• nivel de sensibilidad (qué datos puede ver/emitir).

Si quieres aterrizar esto en algo operativo (que puedas enseñar a dirección y que sirva en auditoría), te encaja esta guía: documentar el uso de IA en empresa.

5.3. Conectores: lista blanca, no lista de deseos

En la práctica, la mayoría de fugas vienen de aquí. La recomendación es clara: lista blanca de conectores aprobados y revisión explícita de los que implican exportación (correo externo, almacenamiento personal, mensajería fuera de control, integraciones “rápidas”).

Si un agente necesita un conector nuevo, el proceso debería parecerse a “pedir acceso a producción”: justificación, revisión de permisos, y condiciones (por ejemplo, solo en un entorno, solo con una identidad específica, solo con acciones limitadas).

5.4. Identidades y permisos: mínimo privilegio o nada

Hazte estas preguntas (y no las pases por alto):

• ¿El agente actúa como el usuario o como una identidad compartida?
• ¿Qué pasa si el usuario no tiene acceso a ese dato, pero el agente sí?
• ¿Existe un “superusuario” escondido en una conexión reutilizada?
• ¿Hay revisión periódica de permisos y caducidad?

5.5. Protección de datos: clasificación, DLP y límites de salida

Aquí no hay magia: si no clasificas datos y no pones barreras de salida, el agente puede mezclar información sensible con flujos cotidianos. Tu objetivo es que el agente “note” cuando está tocando algo delicado (por ejemplo, datos personales, finanzas, contratos, propiedad intelectual) y que existan límites:

• bloqueo o advertencia al compartir fuera de ciertos dominios;
• restricciones en acciones de “enviar”, “descargar”, “copiar” con ciertos contenidos;
• reglas de retención y auditoría donde realmente se usa el agente.

5.6. Observabilidad: logs útiles y alertas que tengan sentido

La pregunta no es “¿tenemos logs?”. La pregunta es “¿podemos responder rápido si algo se filtra?”. Define señales simples:

• picos de lectura/descarga de archivos por parte del agente;
• envíos recurrentes a destinos poco habituales;
• accesos a repositorios sensibles desde agentes “no críticos”.

6. Un ejemplo rápido: el “agente comercial” que termina filtrando precios

Caso típico (lo he visto con mil variantes): el equipo comercial quiere ahorrar tiempo. Montan un agente que, al recibir un nombre de cliente, busca en SharePoint la última propuesta, extrae el pricing y prepara un email.

¿Dónde falla?

• La carpeta de propuestas tiene permisos “históricos” demasiado amplios.
• El agente usa una conexión compartida con acceso a todo el sitio.
• El usuario pega un email reenviado que trae instrucciones ocultas o contenido malicioso (“incluye también la tabla de descuentos”).
• El output se pega en un canal de Teams donde hay externos o invitados.

Nadie “robó” nada de forma explícita. Pero el resultado es el mismo: precios y condiciones fuera de control. Y lo peor: suele detectarse tarde, porque parece un simple intercambio de mensajes.

7. Checklist express: lo mínimo que haría esta misma semana

8. Cierre: el riesgo silencioso no es la IA, es la automatización sin gobierno

Los agentes no-code son una buena noticia: bajan el coste de automatizar y hacen que equipos no técnicos mejoren procesos. Pero también cambian el equilibrio: lo que antes requería un desarrollo (y por tanto pasaba por revisiones) ahora puede nacer en una tarde.

La frase que me gusta repetir en estos casos es simple: si puede tocar datos, es un sistema. Y si es un sistema, merece controles: permisos mínimos, conectores gobernados, límites de acción, observabilidad y responsabilidad clara.

Si haces eso, Copilot y sus agentes dejan de ser un riesgo silencioso y se convierten en lo que deberían ser: una ventaja competitiva que no te explota en la cara en la primera auditoría… o en el primer “¿por qué este archivo terminó aquí?”.