Un coding agent moderno ya no se limita a completar una línea de código. Dependiendo de la configuración, puede leer el repositorio, editar archivos, ejecutar comandos, consultar APIs, abrir issues, acceder a bases de datos, llamar a herramientas externas e instalar dependencias.
Este cambio altera la pregunta de seguridad.
Antes, un equipo de AppSec podía concentrar gran parte del control en artefactos relativamente conocidos: código, dependencias, imágenes, pipelines y repositorios. Con agentes conectados a tools, skills y servidores MCP, parte de las decisiones comienza a ocurrir incluso antes de que el código llegue al commit.
El problema deja de ser solo:
¿El código producido por la IA es seguro?
Y pasa a incluir:
¿Podemos confiar en las herramientas, instrucciones, permisos e integraciones que ayudaron a producir ese código?
Por qué MCP entró en la conversación de AppSec
El Model Context Protocol (MCP) permite que aplicaciones y agentes se conecten a recursos y herramientas externas mediante una interfaz estandarizada.
En la práctica, esto puede acercar al agente a sistemas como:
- Repositorios de código;
- Issue trackers;
- Bases de datos;
- APIs internas;
- Servicios de cloud;
- Documentación;
- Sistemas de archivos;
- Terminales y herramientas de desarrollo.
Esta capacidad es útil precisamente porque permite al agente actuar con más contexto. El mismo beneficio, sin embargo, aumenta el impacto de una configuración insegura.
La propia especificación de MCP trata las herramientas como una superficie que exige cautela. La documentación de seguridad destaca riesgos relacionados con autorización, robo de tokens, confused deputy, redireccionamientos y confianza en integraciones.
El riesgo ya dejó de ser teórico
Una investigación publicada por Snyk en junio de 2026 analizó casi 10 mil entornos de desarrollo. En la muestra analizada, el 50,8% de los desarrolladores tenía al menos un MCP Server instalado.
Entre los desarrolladores con servidores MCP, 1 de cada 7 presentó al menos un hallazgo de seguridad.
Este número debe interpretarse correctamente: es una investigación de un proveedor sobre la muestra observada por la propia Snyk, no una estimación universal de todo el mercado.
Aun así, la señal es importante. MCP, coding agents y skills ya están presentes en entornos reales a una escala suficiente para que AppSec deba tratarlos como parte de la superficie de desarrollo.
NIST llegó a una conclusión similar en otro contexto. En su informe de 2026 sobre seguridad de agentes de IA, el instituto registró un amplio consenso entre los participantes de que los agentes introducen riesgos específicos y que los principios tradicionales de ciberseguridad siguen siendo válidos, pero necesitan adaptarse al modelo agentic.
Tres superficies que necesitan ser gobernadas
Una forma práctica de organizar el problema es separar el riesgo en tres preguntas.
1. ¿Qué utiliza el agente?
Antes de ejecutar cualquier tarea, el agente puede depender de:
- MCP Servers;
- Tools;
- Skills;
- Plugins;
- Modelos;
- Bibliotecas;
- Documentación;
- Servicios externos.
La organización necesita saber de dónde provienen estos elementos, quién los aprobó, qué pueden hacer y cómo serán actualizados.
Un MCP Server conocido no debería tratarse como confiable para siempre solo porque fue aprobado una vez. Los cambios de versión, mantenedor, configuración o backend pueden modificar su riesgo.
2. ¿Qué puede hacer el agente?
Los permisos son una de las principales diferencias entre un asistente pasivo y un agente.
Considera dos escenarios:
- 01Asistente restringidolee código y sugiere una modificación
- 02Revisión humanael desarrollador decide qué aplicar
En otro escenario:
- 01Agente autónomolee código y contexto
- 02Herramientasejecuta terminal y llama APIs
- 03Dependenciasinstala componentes
- 04Sistemasaccede a cloud o repositorios
- 05Entregaabre PR y activa pipeline
Ambos utilizan IA, pero el riesgo operacional es muy diferente.
Cuanto mayor sea la autonomía, más importantes se vuelven:
- Mínimo privilegio;
- Segregación de funciones;
- Alcance de los tokens;
- Expiración de credenciales;
- Aprobación humana;
- Registro de auditoría;
- Límites de ejecución.
3. ¿Qué genera el agente?
Incluso si las herramientas y los permisos están controlados, el código producido sigue necesitando pasar por los controles normales de ingeniería.
Esto incluye:
- Revisión;
- SAST;
- SCA;
- Secret scanning;
- Pruebas;
- Análisis de IaC cuando corresponda;
- Políticas de pipeline;
- Validación de artefactos.
La adopción de agentes no elimina AppSec. Añade una nueva capa antes de los controles que ya existían.
Prompt injection cambia de impacto cuando el agente posee herramientas
El prompt injection en un chatbot sin acceso a sistemas puede producir una respuesta incorrecta.
En un agente conectado a herramientas, la consecuencia puede ser mayor.
Una instrucción maliciosa puede estar en:
- Documentación externa;
- Issue;
- Comentario;
- Página web;
- Descripción de tool;
- Archivo dentro del propio repositorio;
- Contexto devuelto por otra integración.
Si el agente interpreta la instrucción como parte legítima de la tarea y tiene permiso para actuar, el problema deja de ser exclusivamente de contenido y pasa a involucrar ejecución.
Por eso, la seguridad de agentes no puede depender solo de “un prompt mejor”. Es necesario combinar límites técnicos de autorización, confianza en el origen, validación de acciones y observabilidad.
Las dependencias instaladas por agentes merecen el mismo control que las humanas
Otro punto de atención es la instalación de software.
Un desarrollador puede elegir conscientemente una biblioteca. Un agente puede recomendar o instalar una dependencia como parte de una tarea mayor.
En ambos casos, el paquete entra en la misma Software Supply Chain. Por lo tanto, las reglas no deberían depender de quién ejecutó el comando.
- 01Solicitudhumano o agente solicita una dependencia
- 02Origenvalidar registro, namespace e identidad
- 03Riesgovulnerabilidad, malware, política y señales de confianza
- 04Instalaciónpermitir, bloquear, poner en cuarentena o revisar
- 05Buildejecutar con identidad y permisos controlados
- 06Evidenciaregistrar versión, origen y decisión
El control debe permanecer en el punto de ingestión y en el pipeline, y no solo en la intención del usuario o del agente.
Un caso real: cuando MCP entra en la Supply Chain
En septiembre de 2025, Postmark informó sobre un paquete npm malicioso llamado postmark-mcp que se hacía pasar por una integración legítima de Postmark.
El paquete parecía legítimo durante 15 versiones. En la versión 1.0.16, añadió una puerta trasera que enviaba en secreto copias ocultas (BCC) de los correos electrónicos a un servidor externo.
El caso muestra que el riesgo no está solo en el comportamiento del agente o en los permisos concedidos a una herramienta. El propio MCP Server utilizado por el agente puede convertirse en un componente comprometido de la cadena de software.
Para los equipos de AppSec, esto amplía la pregunta de "¿qué vulnerabilidades existen en este componente?" a "¿de dónde provino este componente, quién lo publicó, qué hace y a qué recursos podrá acceder el agente a través de él?"
Lo que AppSec debería empezar a inventariar
Antes de comprar una nueva herramienta, una organización puede comenzar con visibilidad.
Algunas preguntas simples:
- ¿Qué coding agents están autorizados?
- ¿Qué MCP Servers existen en los endpoints?
- ¿Quién puede instalar nuevos servidores, skills o plugins?
- ¿A qué sistemas puede acceder cada integración?
- ¿Los permisos son de solo lectura cuando sea posible?
- ¿Los tokens son personales, compartidos o específicos por workload?
- ¿Existe expiración y rotación?
- ¿El agente puede ejecutar shell sin aprobación?
- ¿Las instalaciones de dependencias pasan por los mismos repositorios y políticas que el resto de la empresa?
- ¿Existen registros suficientes (logs) para reconstruir lo que hizo el agente?
- ¿El código creado o modificado por un agente pasa por los mismos gates que el código humano?
- ¿Existe un proceso simple para revocar rápidamente una integración?
Si estas respuestas dependen de la memoria de cada desarrollador, ya existe una brecha de gobernanza.
Una arquitectura mínima para uso corporativo
No existe un único diseño válido, pero una arquitectura defendible tiende a separar confianza y ejecución.
- 01Agente aprobadoidentidad y configuración conocidas
- 02MCP y toolscatálogo, origen y permisos controlados
- 03Autorizaciónmínimo privilegio y credenciales de corta duración
- 04Ejecuciónlímites y aprobación para acciones críticas
- 05Dependenciasingestión mediante fuentes y políticas corporativas
- 06Códigorevisión y controles AppSec
- 07Pipelinebuild, evidencia y promoción
- 08Observabilidadlogs, detección y respuesta
El objetivo no es exigir aprobación manual para cada acción simple. Es definir qué acciones pueden ocurrir automáticamente y cuáles cruzan una frontera de riesgo que exige un control adicional.
La seguridad de agentes no debería convertirse en un silo
Existe el riesgo de crear una nueva disciplina aislada llamada “AI Security” y repetir problemas que AppSec ya aprendió a resolver.
Identidad, mínimo privilegio, origen confiable, validación de dependencias, segregación, observabilidad y respuesta siguen siendo relevantes.
Lo que cambia es la ubicación de estos controles.
Parte del riesgo ahora surge:
- En el entorno local del desarrollador;
- En la configuración del agente;
- En la integración con herramientas;
- Antes del commit;
- Durante decisiones automatizadas.
Por eso, el camino más sostenible es extender el programa de AppSec existente para cubrir la nueva superficie, y no crear una gobernanza paralela sin integración.
La prueba práctica
Elige un coding agent utilizado en la empresa e intenta responder:
¿A qué sistemas accede, con qué identidad, mediante qué tools, bajo qué políticas y con qué evidencias?
Si la respuesta no puede obtenerse rápidamente, el problema no es necesariamente la IA.
Es la falta de visibilidad sobre una nueva frontera de la Software Supply Chain.
Fuentes y referencias
- Model Context Protocol — Specification 2026-07-28
- Model Context Protocol — Authorization Security Considerations
- Model Context Protocol — Security Best Practices
- NIST — Summary Analysis of Responses Regarding Security Considerations for AI Agents
- OpenSSF — Securing Agentic AI
- Snyk Research — What nearly 10,000 developer environments reveal about agentic development risk
- Postmark — Security Alert: Malicious 'postmark-mcp' npm Package Impersonating Postmark
¿Tu entorno de desarrollo con IA ya tiene límites de confianza definidos?
Xmart apoya la evaluación de arquitectura, gobernanza y controles de AppSec y Software Supply Chain en entornos modernos de desarrollo con IA.
