Office Address
Seville, Spain
Seville, Spain
Phone Number
+(34) 624 816 969
Email Address
Available on Google Play
Seville, Spain
Seville, Spain
+(34) 624 816 969
by ForgeNEX Table of contents [Show]
Durante mucho tiempo, la conversación sobre inteligencia artificial en las empresas se quedó en una pregunta bastante cómoda: si el modelo escribe código con suficiente calidad. La pregunta importante ha cambiado. Ahora hay que saber qué puede leer, qué puede modificar, con qué identidad trabaja y quién puede detenerlo cuando toma una decisión equivocada.
En los últimos días han aparecido varias señales que apuntan al mismo problema. Un agente utilizado en una investigación autorizada encontró y explotó una vulnerabilidad en un flujo de GitHub Actions. Otro artículo muestra lo fácil que puede resultar entregar a un agente una capacidad destructiva desde una interfaz conversacional. Y un análisis sobre MCP vuelve a poner sobre la mesa algo menos vistoso, pero más peligroso: los servidores que conectan agentes con herramientas suelen concentrar credenciales, tokens y permisos de producción.
No son tres historias aisladas. Forman una misma fotografía: la IA está dejando de ser una capa que responde y está entrando en el circuito que ejecuta.
Un asistente tradicional recibe una pregunta y devuelve texto. El usuario decide qué hacer después. Un agente trabaja de otra manera: interpreta un objetivo, consulta herramientas, lee datos, encadena pasos y entrega un resultado que puede incluir cambios reales.
Microsoft describe esta transición en su propio blog de Microsoft 365. La compañía presenta agentes que pueden planificar, ejecutar, probar y corregir tareas, además de sistemas que continúan trabajando con una identidad y unos permisos propios cuando la persona ya no está delante de la pantalla. El salto no está en que el modelo escriba una respuesta más convincente. Está en que el sistema tiene un radio de acción.
Ese radio de acción se puede medir. Un agente puede limitarse a leer una carpeta de SharePoint o puede modificar documentos, enviar mensajes, abrir incidencias, consultar el CRM, cambiar una configuración o iniciar una operación en la nube. En ambos casos hablamos de inteligencia artificial, pero el riesgo operativo no tiene nada que ver.
La empresa que evalúa solo el modelo está mirando la parte menos decisiva del problema. La pregunta útil es otra: ¿qué ocurre cuando el modelo se equivoca y la herramienta ejecuta la equivocación?
The Register ha contado un caso concreto relacionado con Snowflake y GitHub Actions. Durante una investigación autorizada dentro de un programa de bug bounty, el equipo de Wiz encontró una vulnerabilidad de inyección de comandos en un flujo de trabajo asociado a snowflake-connector-net.
Según la información publicada, un usuario no autenticado podía provocar la ejecución de comandos en un runner mediante el título de una incidencia especialmente construida. El origen estaba en un cambio de código asistido por IA que sustituyó un patrón de entrada saneada por una expansión directa dentro de un script de shell.
El caso tiene dos lecturas que conviene mantener separadas. La primera es positiva: se trataba de una investigación autorizada, Snowflake corrigió el problema el mismo día y rotó las credenciales afectadas después. La segunda es incómoda: un asistente puede introducir una vulnerabilidad en una parte de la cadena que muchos equipos consideran automatización rutinaria, y otro agente puede descubrirla y explotarla a una velocidad que obliga a revisar los controles tradicionales.
Esto no demuestra que la IA sea incapaz de programar. Demuestra que un flujo de revisión basado únicamente en que otra persona lea el diff ya no ofrece suficiente cobertura cuando el código modifica permisos, runners, secretos o automatizaciones de despliegue.
El control tiene que desplazarse hacia el propio proceso: entradas no confiables separadas, permisos mínimos en runners, secretos fuera del entorno cuando no sean necesarios, validación automática de scripts y una prueba específica para cualquier cambio que toque CI/CD.
El Model Context Protocol facilita que un agente se conecte a herramientas y datos externos. Puede consultar documentación interna, leer un registro, abrir un fichero o llamar a una API. Esa capacidad resulta útil porque evita encerrar al modelo en su conocimiento previo. También crea un punto de concentración que merece más atención.
The Hacker News señala varios riesgos habituales en los servidores MCP: credenciales en texto plano, copias de tokens repartidas entre servidores sin gobierno central y permisos más amplios de lo que exige la tarea. El problema no es que exista un archivo de configuración. El problema aparece cuando nadie sabe cuántas copias existen, quién las puede leer, cuándo se rotaron o qué puede hacer un agente con ellas.
Una clave filtrada en una aplicación tradicional puede abrir un servicio. Una clave entregada a un agente puede formar parte de una cadena de decisiones: leer datos, combinarlos, elegir otra herramienta y ejecutar una acción. El secreto deja de ser solo una contraseña técnica y se convierte en una identidad no humana con capacidad de operar.
Por eso no basta con preguntar si el servidor MCP es confiable. Hay que revisar qué identidad utiliza, qué permisos tiene, si cada llamada queda registrada, si los secretos se entregan bajo demanda y si una acción sensible necesita una aprobación separada.
The New Stack ha descrito otra variante del problema: un agente conectado a herramientas puede llegar a eliminar un agente de voz de producción desde una ventana de conversación. El ejemplo resulta llamativo por el verbo —eliminar—, pero la lección sirve para cualquier sistema conectado a una cuenta real.
Una interfaz conversacional hace que una acción administrativa parezca una orden más. El usuario escribe, el agente interpreta y la herramienta ejecuta. Si no existe una pausa explícita, es fácil que el sistema confunda una intención exploratoria con una autorización definitiva.
El control no consiste en quitar todas las capacidades. Consiste en dividirlas. Leer no es lo mismo que modificar. Preparar un cambio no es lo mismo que aplicarlo. Crear una propuesta no es lo mismo que publicar. El agente debería poder avanzar hasta el punto en que una persona revise el impacto, el alcance y la posibilidad de deshacerlo.
En un entorno empresarial razonable, una acción destructiva necesita al menos cuatro cosas: identidad clara, permiso específico, registro verificable y mecanismo de recuperación. Si falta una de ellas, el sistema puede parecer automatizado, pero no está gobernado.
Microsoft 365 concentra documentos, conversaciones, calendarios, grupos, identidades y conocimiento interno. Azure añade recursos, redes, secretos, automatizaciones y costes. La combinación es potente porque permite construir agentes que entienden el contexto de una organización y actúan sobre él.
También exige diseñar el acceso antes de conectar herramientas. Un agente que resume documentos necesita lectura. Un agente que prepara una propuesta puede necesitar escribir en un borrador. Un agente que publica, modifica permisos o cambia una configuración necesita un control diferente.
La separación por entornos sigue siendo válida para la IA. Desarrollo, pruebas y producción no deben compartir las mismas credenciales ni la misma libertad de acción. Tampoco conviene crear un agente con acceso general y confiar en que el prompt le recuerde cada vez qué no debe hacer.
La política debe estar fuera de la conversación: permisos mínimos, identidades separadas, límites de tiempo, revisión humana, logs, alertas, rotación de secretos y una forma probada de volver atrás.
La carrera por conectar más aplicaciones puede dar una demo espectacular y una operación difícil de controlar. La métrica útil es más sobria:
La IA puede acelerar un equipo, pero la velocidad sin límites solo adelanta los errores. En seguridad, cada permiso que no podemos explicar es una deuda. Cada secreto duplicado es una superficie de ataque. Cada acción irreversible que no exige confirmación es una decisión de diseño, aunque nadie la haya documentado.
Los agentes van a formar parte del trabajo diario. La cuestión no es si una empresa los utiliza, sino si puede demostrar qué hacen, por qué lo hacen y cómo detenerlos. Ahí empieza la diferencia entre añadir IA a una operación y gobernar una operación que ya incluye IA.