Un agente de codificación conectado a un servidor MCP o a herramientas externas ya no es solo un asistente que sugiere código. Puede leer repositorios, consultar tickets, buscar documentación interna, llamar a APIs, ejecutar comandos, acceder a bases de datos, abrir pull requests, modificar configuraciones o interactuar con servicios en la nube. La superficie de riesgo cambia: ya no se trata solo del archivo generado, sino de los permisos, los datos y las acciones que el agente puede utilizar mientras trabaja.
El Model Context Protocol (MCP) nace para estandarizar la conexión entre aplicaciones LLM, herramientas y fuentes de datos. Para los equipos que desarrollan software, es útil porque reduce las integraciones ad hoc y facilita proporcionar contexto operativo a los agentes. Sin embargo, esta misma capacidad desplaza el problema hacia una cuestión más delicada: si el agente interpreta mal una tarea, sufre una inyección de prompt o elige la herramienta incorrecta, ¿qué sistemas puede afectar realmente?
Antes de utilizar MCP en un flujo de trabajo de desarrollo, los ingenieros de seguridad, CTOs y desarrolladores avanzados deben mapear las herramientas, identidades, autorizaciones, tokens, registros (logs) y acciones permitidas. Un servidor MCP de solo lectura sobre documentación pública tiene un perfil de riesgo muy distinto al de un servidor con acceso a repositorios, CI/CD, nube, tickets, bases de datos o sistemas corporativos.
De la generación de código al uso de herramientas
En el “vibe coding” tradicional, el riesgo principal es aceptar código no verificado. Con MCP y los agentes que utilizan herramientas, el riesgo se extiende al camino que produce ese código: el agente puede leer datos, seleccionar herramientas, componer parámetros, interpretar resultados, decidir la acción siguiente y proponer o aplicar cambios. Si las herramientas tienen privilegios amplios, un error de contexto puede convertirse en una acción real.
Un agente que lee una incidencia (issue) y luego modifica una ruta puede introducir una vulnerabilidad en el código. Un agente que lee la misma incidencia, consulta la base de datos, actualiza una configuración en la nube y abre una pull request tiene un perímetro mucho más amplio: puede exponer datos, usar credenciales, modificar políticas, ampliar permisos o generar un diff basado en resultados no fiables.
La seguridad de MCP, las vulnerabilidades de los servidores MCP, la seguridad de las herramientas agenticas y el uso indebido de herramientas por parte de agentes deben leerse, por tanto, en conjunto. El problema no es solo si el servidor MCP “funciona”, sino qué capacidades expone, a qué identidad, con qué autorización, con qué aislamiento, con qué registro de eventos y con qué confirmaciones humanas.
Agencia excesiva (Excessive agency): cuando el agente tiene más poder del necesario
OWASP incluye la “agencia excesiva” entre los riesgos principales de las aplicaciones LLM: un modelo con autonomía, funcionalidades o permisos excesivos puede realizar acciones no previstas, especialmente si es manipulado por inyecciones de prompt o datos no fiables. Con MCP, este riesgo se vuelve práctico porque el protocolo conecta al agente con herramientas reales.
La pregunta que debe hacerse sobre cada herramienta es concreta: ¿el agente realmente necesita poder escribir, o le basta con leer? ¿Debe poder usar datos de producción, o es suficiente con un entorno de staging? ¿Debe poder actuar sobre todos los repositorios, o solo en un proyecto específico? ¿Debe poder llamar a cualquier endpoint, o solo a operaciones con un esquema controlado? ¿Debe poder ejecutar comandos de shell, o basta con consultar resultados ya preparados?
Un modelo de privilegios saludable separa la lectura, la escritura y las acciones destructivas. Leer documentación técnica no equivale a leer registros con datos personales. Abrir una incidencia no es lo mismo que cerrarla. Preparar un comando no es lo mismo que ejecutarlo. Generar un parche no es lo mismo que hacer un merge. Cuanto más irreversible, costosa o conectada a datos reales sea la acción, más necesarios son la aprobación humana, los entornos aislados (sandbox) y las pistas de auditoría.
Confused deputy, paso de tokens y autorización MCP
La documentación de seguridad de MCP advierte sobre el riesgo de “confused deputy” (delegado confundido): un componente con privilegios puede ser inducido a actuar en nombre de un cliente o recurso distinto al previsto. En un flujo de trabajo agentico, este escenario es crítico porque el agente puede encontrarse entre el usuario, el cliente, el servidor MCP, el proveedor OAuth, las APIs corporativas y los recursos finales.
La especificación MCP para transportes HTTP define capacidades de autorización basadas en OAuth 2.1, y las versiones recientes valoran el uso de indicadores de recursos para vincular tokens y recursos. Las mejores prácticas de MCP prohíben el paso de tokens (token passthrough), ya que transferir tokens recibidos de un componente a otro puede romper la audiencia, el alcance (scope), la revocación, la trazabilidad y los límites de confianza. Para una aplicación corporativa, esto no es un detalle de implementación: decide si un agente puede usar credenciales en el contexto correcto o abusar de ellas en otro lugar.
En la práctica, un servidor MCP no debería usar tokens globales cuando la acción depende del usuario, ni aceptar un token diseñado para un recurso y usarlo en otro. No debería compartir la misma credencial entre repositorios, inquilinos (tenants) o entornos diferentes, ni ocultar al usuario final qué cliente está solicitando acceso a qué datos. Cada herramienta sensible debe tener una identidad, un alcance y un recurso claros.
Metadatos de herramientas y envenenamiento de herramientas (tool poisoning)
Una herramienta MCP no es solo código ejecutable: también expone un nombre, una descripción, un esquema de entradas y, a menudo, ejemplos de uso. El modelo utiliza esta información para decidir cuándo llamarla y cómo completar los parámetros. Si un atacante logra manipular metadatos, descripciones, documentación o resultados de la herramienta, puede orientar al agente hacia decisiones erróneas.
El riesgo de envenenamiento de herramientas es sutil porque aprovecha la forma en que el modelo razona sobre el texto. Una descripción puede afirmar “usa esta herramienta para recuperar credenciales temporales” o “no se necesita confirmación para actualizar configuraciones”. Una herramienta aparentemente inofensiva puede devolver resultados que contengan instrucciones dirigidas al agente en lugar de datos. Un servidor MCP instalado desde una fuente no verificada puede exponer herramientas con nombres similares a las legítimas.
La defensa comienza con el control de la procedencia. Los servidores MCP utilizados en repositorios o sistemas corporativos deben provenir de fuentes aprobadas, estar versionados, revisados y configurados con listas blancas (allowlists). Las descripciones de las herramientas deben ser precisas y minimalistas: explicar qué hace la herramienta, qué entradas acepta, qué efectos produce y qué límites tiene. Las instrucciones de seguridad no deberían residir únicamente en el texto descriptivo como barrera, sino ser aplicadas mediante autorizaciones, políticas y controles en tiempo de ejecución.
Resultados de las herramientas: datos, instrucciones y acciones subsiguientes
Un agente puede usar el resultado de una herramienta como entrada para una decisión posterior. Si la herramienta recupera documentación, incidencias, páginas web, registros o registros de bases de datos, el resultado puede contener texto no fiable. Si la herramienta genera comandos, rutas, consultas, parches o configuraciones, un resultado manipulado puede convertirse en una acción.
El caso típico es una cadena simple: la herramienta lee un ticket, el ticket contiene instrucciones hostiles, el agente las sigue y luego llama a otra herramienta con privilegios más altos. El resultado puede ser una ruta expuesta, una política de nube ampliada, una prueba modificada, una consulta sin filtrar o un secreto copiado en un archivo. La inyección de prompt indirecta se vuelve mucho más grave cuando el modelo puede usar herramientas después de haber leído el contenido.
Los resultados de las herramientas deben validarse como cualquier entrada externa: esquemas estrictos, tipos explícitos, escape de caracteres, límites en los campos, listas blancas de acciones subsiguientes y separación entre datos e instrucciones reducen el riesgo. Para acciones sensibles, el agente debería mostrar qué ha leído, qué herramienta quiere llamar, qué parámetros usará y qué efecto se prevé, porque una confirmación genérica no da al revisor suficiente contexto.
Inyección de prompt a través de documentos, tickets y sistemas corporativos
MCP facilita la conexión de un agente con sistemas ya llenos de contenido: Jira, GitHub Issues, Slack, correos electrónicos, wikis, CRM, documentación, bases de conocimiento, registros y sistemas de tickets. Estos contenidos no fueron escritos para ser instrucciones seguras hacia un modelo y pueden contener texto malicioso, fragmentos copiados por usuarios, ejemplos obsoletos, comandos no verificados o datos manipulados.
Un ticket de soporte podría incluir una frase diseñada para hacer que el agente ignore las reglas del proyecto. Un comentario en una incidencia podría pedir el uso de un endpoint de administración. Un documento interno podría contener un procedimiento antiguo con credenciales o permisos ya no válidos. Una página web recuperada por la herramienta podría contener instrucciones ocultas. Si el agente trata todo como contexto fiable, las herramientas se convierten en un amplificador del riesgo.
Los flujos de trabajo seguros separan las fuentes aprobadas de los contenidos no fiables. Un ticket puede describir un error, pero no debe cambiar las políticas del agente. Una página externa puede proporcionar información, pero no debe autorizar comandos. Un registro puede ayudar al diagnóstico, pero no debe llevar secretos al contexto. Cuando el agente pasa de la lectura a la acción, se necesita un control explícito.
Herramientas que leen repositorios, sistemas de archivos y secretos
En el contexto del desarrollo de software, muchos servidores MCP y conectores son útiles precisamente porque leen repositorios, sistemas de archivos, configuraciones y documentación técnica. El riesgo es que lean demasiado: un agente que puede explorar libremente el proyecto puede encontrar archivos .env, claves API, tokens de despliegue, archivos de respaldo, volcados (dumps), registros, certificados, configuraciones de la nube o datos personales utilizados en pruebas.
El problema no se resuelve solo confiando en el proveedor o en el modelo. Si se lee un secreto, se copia en un diff, se incluye en un registro, se envía a una herramienta o se inserta en una respuesta, el daño es operativo y la remediación incluye la eliminación del código, la rotación de la credencial, la verificación de los entornos y el control de compilaciones, registros y artefactos.
Por esto, las herramientas de sistema de archivos y repositorios deberían partir de una política de “denegar por defecto”. Las rutas sensibles, archivos .env, volcados, respaldos, exportaciones de gestores de secretos, claves privadas y registros reales deben estar excluidos o ser accesibles solo con autorización específica. Las credenciales utilizadas por los servidores MCP deben estar separadas de las personales y de las de producción: si una herramienta debe leer código, no debe leer automáticamente secretos y datos.
Herramientas que escriben, eliminan o despliegan
El umbral de riesgo cambia cuando la herramienta no solo lee. Escribir en bases de datos, actualizar tickets, enviar correos, abrir PRs, modificar archivos, eliminar recursos, rotar credenciales, lanzar pipelines o realizar despliegues son acciones con impacto real, y hasta una modificación aparentemente pequeña puede tener efectos amplios si ocurre en el contexto equivocado.
Un agente puede decidir resolver un error de compilación abriendo permisos, desactivando un control, ampliando CORS, cambiando variables de entorno o modificando flujos de CI/CD. Puede cerrar un ticket porque interpreta mal el resultado de una herramienta, enviar un mensaje con datos internos, ejecutar una migración en la base de datos incorrecta o realizar una pull request que combina código generado y configuraciones no revisadas.
Las acciones de escritura requieren un modelo más severo: ejecución de prueba (dry-run), staging, aprobación explícita, registros, reversión (rollback) y límites claros. El usuario debe poder ver los parámetros y las consecuencias antes de confirmar. Para la nube, bases de datos, CI/CD, correo electrónico, tickets y sistemas de clientes, conviene separar las herramientas de solo lectura de las de escritura y deshabilitar por defecto las acciones destructivas.
Aislamiento entre usuarios, inquilinos y entornos
Un servidor MCP puede ser utilizado por varias personas, equipos, repositorios o entornos. Si la identidad no se propaga correctamente, el servidor corre el riesgo de actuar con una cuenta técnica demasiado amplia, creando problemas clásicos de autorización: un usuario puede leer datos de otro equipo, un agente puede modificar repositorios fuera de su alcance, un entorno de prueba puede tocar producción, un inquilino puede influir en otro.
La seguridad debe diseñarse por usuario y recurso. Las llamadas a herramientas deben ser atribuibles a una persona o a un servicio autorizado, los tokens deben tener alcances coherentes con el repositorio, proyecto, inquilino y entorno, y las autorizaciones a nivel de objeto no pueden ser sustituidas por una regla genérica de “el agente está autorizado”. Si una herramienta actúa sobre datos multi-inquilino, cada solicitud debe preservar el inquilino correcto hasta el recurso final.
En las pruebas de pre-producción es necesario simular usuarios diferentes: un desarrollador con permisos de administrador no basta para validar el flujo. Es necesario verificar qué sucede con un usuario estándar, un rol de solo lectura, un miembro de otro inquilino, una cuenta caducada, un token con alcance reducido y un entorno de staging separado de la producción.
Cadena de suministro de los servidores MCP
Instalar un servidor MCP significa introducir un componente que a menudo tiene acceso a datos y acciones. Puede ser un paquete npm, un contenedor, un binario, un script local, un servicio remoto o un conector SaaS. Si el servidor está comprometido, poco mantenido, descargado de una fuente no verificada o mal configurado, el riesgo no se limita a su código: afecta a todo lo que puede alcanzar.
La cadena de suministro de los servidores MCP debe gestionarse con los mismos criterios utilizados para componentes de aplicaciones críticas. La procedencia, el mantenedor, la versión, el registro de cambios, las dependencias, la licencia, las vulnerabilidades conocidas, los scripts de instalación, la imagen del contenedor y la configuración de tiempo de ejecución deben ser controlados. Un servidor utilizado para leer documentación pública tiene requisitos diferentes a los de un servidor con acceso a GitHub, bases de datos, nube o tickets internos.
Para entornos corporativos, una lista blanca o un registro privado reduce el riesgo de instalaciones casuales. Los servidores MCP sensibles deberían ejecutarse en entornos aislados o contenedores con red, sistema de archivos y secretos limitados. Las actualizaciones deben revisarse porque una nueva versión puede cambiar las herramientas expuestas, los alcances solicitados, los resultados o el comportamiento.
Registro de eventos (Logging), pistas de auditoría y respuesta a incidentes
Sin registros, MCP se vuelve difícil de gobernar. Si el agente modifica un archivo, abre un ticket, lee datos o llama a una API, el equipo debe poder reconstruir quién inició la sesión, qué herramienta se llamó, con qué parámetros, qué resultado se devolvió, qué acción siguió y qué recurso fue afectado.
El registro debe ser lo suficientemente rico para respaldar la revisión y la respuesta a incidentes, pero no debe convertirse en un nuevo punto de exposición: las entradas y salidas de las herramientas pueden contener datos sensibles, tokens o información de clientes, por lo que se requiere redacción, retención, control de acceso y alertas sobre las herramientas más delicadas.
Los eventos a monitorear incluyen llamadas a herramientas de escritura, acceso a secretos, lectura de datos personales, uso de tokens privilegiados, llamadas entre inquilinos, despliegues, eliminaciones, modificaciones a políticas de nube, actualizaciones de servidores MCP y fallos de autorización. Cuando algo sale mal, el equipo debe poder deshabilitar rápidamente un servidor, revocar tokens, rotar credenciales e identificar las modificaciones producidas.
Human-in-the-loop que funciona realmente
Incluir una confirmación humana no basta si la confirmación no contiene información útil. Un mensaje genérico como “¿el agente quiere usar una herramienta, confirma?” no permite evaluar el riesgo, los datos y el efecto. Para acciones sensibles se necesita una confirmación legible: herramienta, identidad, recurso, parámetros, entorno, tipo de acción, resultado usado como entrada y consecuencia prevista.
El nivel de confirmación debe seguir al impacto. Una consulta de solo lectura sobre documentación pública puede requerir poca fricción, mientras que una llamada que lee datos de clientes, modifica roles, lanza despliegues, actualiza IAM o escribe en la base de datos requiere una revisión explícita. Para operaciones repetitivas se pueden usar políticas y aprobaciones predefinidas, pero solo después de haber limitado el alcance y el entorno.
Un buen “human-in-the-loop” no sirve para descargar la responsabilidad en el desarrollador: sirve para transformar una decisión implícita del agente en una decisión verificable del equipo. Cuando la acción toca la producción, datos reales o sistemas corporativos, la revisión debe ser proporcional al riesgo.
Qué comprobar antes de la puesta en marcha (go-live)
Antes de llevar a producción una aplicación o un flujo de trabajo que utiliza MCP, conviene construir un mapa de las herramientas: qué servidores MCP están instalados, si son locales o remotos, quién los mantiene, qué herramientas exponen, qué datos leen, si pueden escribir, si usan OAuth, tokens estáticos o credenciales de servicio, si están separados por usuario, repositorio, inquilino y entorno, y qué registros producen.
El segundo mapa se refiere a las acciones: qué herramientas pueden modificar código, tickets, bases de datos, nube, CI/CD, correos o sistemas de clientes, cuáles requieren aprobación, cuáles tienen ejecución de prueba, cuáles pueden deshabilitarse en caso de emergencia y cuáles están disponibles incluso después de que el agente haya leído contenidos no fiables.
El tercer mapa se refiere a los límites de confianza. ¿Dónde pasa el límite de confianza entre usuario, cliente, servidor MCP, proveedor OAuth, API corporativa y recurso final? ¿Qué identidad se usa en cada paso? ¿Un token está vinculado al recurso correcto? ¿Una acción es atribuible al usuario correcto? ¿Un inquilino puede influir en otro? ¿Un entorno de staging puede tocar la producción?
Lista de verificación de seguridad MCP para agentes de codificación
- Inventariar servidores MCP, herramientas, clientes, entornos y propietarios.
- Clasificar las herramientas en solo lectura, escritura, destructivas, privilegiadas y sensibles.
- Verificar OAuth, indicadores de recursos, audiencia, alcances y ausencia de paso de tokens.
- Aplicar el principio de menor privilegio por usuario, proyecto, repositorio, inquilino y entorno.
- Separar credenciales personales, técnicas, de staging y de producción.
- Limitar el acceso al sistema de archivos, repositorios, gestores de secretos, registros y datos personales.
- Validar entradas y salidas de las herramientas con esquemas estrictos y listas blancas.
- Probar la inyección de prompt indirecta en tickets, documentos, incidencias, correos, wikis y páginas web.
- Requerir confirmación explícita para escritura, eliminación, despliegue, nube, bases de datos, tickets y correos.
- Usar entornos aislados o contenedores para herramientas que ejecutan código, comandos o acceden al sistema de archivos.
- Registrar llamadas a herramientas, parámetros, resultados, usuario, sesión, recurso, entorno y resultado.
- Preparar reversiones, revocación de tokens, rotación de credenciales y deshabilitación rápida de servidores.
Cuándo involucrar a ISGroup
Una revisión interna puede ser suficiente para experimentos locales, herramientas de solo lectura sobre documentación no sensible o prototipos sin datos reales. El riesgo cambia cuando MCP entra en un flujo de trabajo cercano al producto: repositorios corporativos, ramas compartidas, bases de datos, nube, tickets, CI/CD, sistemas de clientes, usuarios reales o entornos expuestos.
| Si MCP o herramientas externas acceden a… | Riesgo principal | Control recomendado |
|---|---|---|
| Repositorios, código, middleware, políticas, scripts | Modificaciones aplicativas frágiles o bypass lógicos | Revisión de código |
| Herramientas de tiempo de ejecución, prompts, documentos, acciones agenticas | Inyección de prompt, uso indebido de herramientas, resultados no validados | Ciclo de vida de aseguramiento de software |
| Arquitectura agentica, límites de confianza, identidades, tokens | Límites de autorización débiles | Revisión de arquitectura segura |
| Web apps, APIs o paneles expuestos | Abuso desde el exterior tras la puesta en marcha | Pruebas de penetración de aplicaciones web |
| Nube, IAM, gestores de secretos, pipelines, bases de datos | Privilegios excesivos o configuración incorrecta | Evaluación de seguridad en la nube |
Si las herramientas influyen en el código y el middleware, es necesario revisar el diff. Si la aplicación está expuesta, es necesario verificar el comportamiento real mediante pruebas de penetración de aplicaciones web. Si el riesgo principal es la arquitectura agentica, la prioridad es revisar identidades, autorizaciones, límites de confianza, tokens y registros. Si el uso de agentes y MCP se vuelve estable en el ciclo de desarrollo, se necesitan controles repetibles en el tiempo.
Evidencias a preparar para una verificación
Para una verificación eficaz se necesita la lista de servidores MCP, las configuraciones, las herramientas expuestas, los alcances, las credenciales utilizadas, los entornos, el diagrama de flujos y los sistemas conectados. Deben indicarse las herramientas de solo lectura y las de escritura, las acciones sujetas a aprobación, los registros disponibles, los mecanismos de revocación, las políticas de aislamiento y las posibles listas blancas.
En el lado de la aplicación se necesitan repositorios, ramas, PRs generadas o modificadas por agentes, APIs expuestas, roles, inquilinos, datos tratados, pipelines, nube, bases de datos e integraciones. Si el agente lee tickets, documentos, wikis, correos o CRM, hay que aclarar qué fuentes se consideran fiables y cuáles no. Si MCP tiene acceso a producción, es esencial distinguir qué puede hacer en staging y qué puede hacer en sistemas reales.
Estas evidencias permiten evitar controles genéricos. Una verificación sobre MCP debe seguir la cadena completa: usuario, prompt, cliente, servidor MCP, autorización, herramienta, resultado, acción, registro y recurso final. Solo así se entiende si un agente puede transformar una entrada manipulada o una decisión equivocada en un impacto operativo.
Preguntas frecuentes
- ¿Es seguro usar MCP en el desarrollo de software?
- MCP puede usarse de forma segura si los servidores, herramientas, autorizaciones, tokens, entornos aislados y registros están diseñados correctamente. El riesgo depende de lo que el agente pueda hacer: leer documentación pública, modificar repositorios, consultar bases de datos y actuar sobre la nube son escenarios muy distintos.
- ¿Cuál es la diferencia entre MCP y una integración API normal?
- En una integración tradicional, el código de la aplicación decide cuándo llamar a una API y con qué parámetros. En un flujo de trabajo agentico, el modelo puede elegir herramientas y parámetros según el contexto, introduciendo riesgos específicos sobre inyección de prompt, metadatos de herramientas, resultados no validados, autonomía y pistas de auditoría.
- ¿El consentimiento humano elimina el riesgo de uso indebido de herramientas por parte del agente?
- Reduce el riesgo solo si la confirmación muestra información útil: herramienta llamada, identidad, recurso, entorno, parámetros y efecto previsto. Una confirmación genérica no basta para operaciones sobre datos, repositorios, nube, tickets o bases de datos.
- ¿Qué herramientas MCP son más delicadas?
- Aquellas que leen datos sensibles, acceden a secretos, ejecutan comandos, modifican archivos, escriben en bases de datos, interactúan con la nube o IAM, abren o cierran tickets, envían correos, lanzan pipelines o realizan despliegues.
- ¿Cómo se prueba la inyección de prompt en un flujo de trabajo MCP?
- Se preparan contenidos no fiables en tickets, documentos, incidencias, correos o páginas recuperadas por la herramienta y se verifica si el agente los trata como datos o como instrucciones. La prueba debe observar también las llamadas a herramientas subsiguientes, no solo la respuesta textual.
- ¿Cuándo se necesita una Revisión de Arquitectura Segura?
- Cuando MCP conecta agentes a sistemas corporativos, nube, repositorios, datos reales, CI/CD o múltiples inquilinos. La revisión debe verificar identidades, autorizaciones, alcances, límites de confianza, registros, aislamiento y gestión de acciones de alto impacto.
- ¿Cuándo se necesita una Revisión de Código?
- Cuando las herramientas externas influyen en el código, middleware, políticas, APIs, validación, gestión de secretos, scripts o configuraciones. La revisión de código ayuda a entender si el agente ha producido modificaciones vulnerables a partir de resultados, prompts o herramientas no fiables.
[Callforaction-CR-Footer]