Una allowlist de MCP para agentes de código es el contrato que decide qué herramientas pueden descubrir, llamar y repetir Codex, Claude Code, Copilot y agentes similares. La frontera útil no es el servidor completo. Es cada herramienta, con alcance, origen, secreto, log y regla de bloqueo.
En 2026, una investigación sobre MCP analizó 57 amenazas en componentes de host, cliente, LLM, servidor, fuentes externas y autorización (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado el 2026-07-09). Si el agente recibe herramientas autónomas, la configuración de esas herramientas forma parte del pipeline de seguridad.
Resumen práctico
- Permite herramientas específicas, no servidores completos por comodidad.
- Trata cambios de MCP como cambios de código revisables.
- Separa lectura, escritura y ejecución con políticas distintas.
- Registra cada llamada para que el PR lleve evidencia breve.
¿Por qué la allowlist de MCP llegó al pipeline?
En 2026, el estudio de MCP identificó 57 amenazas y describió tool poisoning como una vulnerabilidad client-side prevalente (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado el 2026-07-09). El pipeline debe tratar MCP como superficie de ejecución porque una herramienta mala puede influir en patch, PR, secreto o deploy.
El error común es instalar un servidor MCP porque parece útil y dejar que el agente decida después. Ese modelo mezcla descubrimiento, permiso y ejecución en el mismo punto. En desarrollo real, la política debe existir antes del prompt: qué herramientas entran, en qué repositorio, con qué secreto y bajo qué log.
Este post continúa los textos sobre MCP de codebase RAG, agentjacking vía Sentry MCP y hooks para agentes de código. La diferencia aquí es gobierno de tool use. No hablamos solo del dato que vuelve. Hablamos de la puerta que deja existir a la herramienta.
En flujos largos, la allowlist también ahorra contexto. El agente no necesita cargar un catálogo entero de capacidades si el harness entrega solo lo que permite la tarea. Uso RemoteCode como extensión de contexto para Claude Code y Codex en flujos agentic largos cuando quiero continuidad sin volcar demasiado historial ni demasiadas herramientas en el prompt principal; es mi propia herramienta, así que esta mención es editorial.
Cápsula citable: La allowlist de MCP es control de ejecución para agentes de código. Como la investigación de 2026 mapeó 57 amenazas en el ecosistema MCP (arXiv, consultado el 2026-07-09), la política debe limitar herramientas antes de la llamada.
¿Qué entra en un registro privado de MCP?
En 2026, GitHub anunció soporte de registro propio con allowlists de MCP en Copilot CLI, en vista previa pública para clientes Copilot Business y Enterprise (GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", 2026, consultado el 2026-07-09). El registro privado se vuelve la fuente permitida de descubrimiento.
Un registro privado no es solo una lista de nombres amigables. Debe guardar origen del paquete, versión aprobada, hash cuando tenga sentido, dueño interno, herramientas expuestas, alcances de secretos, entorno permitido y contacto de revisión. Cuando un agente busca una capacidad, ve ese inventario, no toda internet.
GitHub lanzó el MCP Registry público en 2025 indicando que los servidores estaban dispersos entre registros, repositorios y conversaciones de comunidad, un escenario con riesgos de seguridad (GitHub Changelog, "GitHub MCP Registry", 2025, consultado el 2026-07-09). En una organización, el registro privado resuelve lo mismo con una decisión extra: descubrir no es autorizar.
Cápsula citable: Un registro privado de MCP separa descubrimiento de permiso. GitHub llevó allowlists basadas en registro a Copilot CLI en 2026 (GitHub Changelog, consultado el 2026-07-09); los equipos deben negar servidores fuera de la fuente gobernada.
¿Cómo permitir herramientas sin liberar todo el servidor?
En 2026, la documentación de GitHub para MCP en repositorios recomienda permitir herramientas read-only específicas porque Copilot cloud agent y Copilot code review pueden usarlas autónomamente sin pedir aprobación (GitHub Docs, "Configure MCP servers", 2026, consultado el 2026-07-09). La herramienta es la unidad de control.
Permitir * es cómodo, pero débil. Una herramienta que lee una issue no tiene el mismo riesgo que una herramienta que comenta un PR. Una herramienta que consulta un log no tiene el mismo riesgo que otra que ejecuta un comando. Una buena allowlist deja instalado el servidor, pero expone solo las llamadas que necesita la tarea.
{
"mcpServers": {
"observabilidad": {
"type": "http",
"url": "https://mcp.interno.example",
"tools": ["buscar_alerta", "leer_trace"]
}
}
}Usa nombres estrechos. buscar_alerta es mejor que observabilidad_total. leer_trace es mejor que ejecutar_consulta_libre. Cuando la herramienta necesita escribir, abre otro camino: confirmación humana, secreto separado, branch temporal y log de PR.
Cápsula citable: La allowlist debe apuntar a la llamada, no a la marca del servidor. GitHub Docs recomienda herramientas read-only específicas porque el agente puede usarlas sin aprobación (GitHub Docs, consultado el 2026-07-09);
*debe ser excepción revisada.
¿Cómo bloquea CI un cambio peligroso de MCP?
En 2025, la especificación MCP describió herramientas como model-controlled y recomendó humano en el loop para negar invocaciones (Model Context Protocol, "Tools", 2025-06-18, consultado el 2026-07-09). En un repositorio serio, ese humano empieza en la revisión de configuración, antes de que el agente ejecute.
Trata archivos de MCP como infraestructura. ¿Cambió servidor, comando, argumento, secreto, URL, herramienta o wildcard? CI debe alertar. Si el cambio aumenta capacidad, exige code owner. Si agrega escritura, exige revisión de seguridad. Si toca un secreto, bloquea hasta que el entorno pruebe que el token es corto y restringido.
Lo mismo vale para configuración en UI. GitHub Docs dice que la configuración MCP del repositorio es compartida por Copilot cloud agent y Copilot code review (GitHub Docs, "Configure MCP servers", 2026, consultado el 2026-07-09). Si dos flujos usan la misma superficie, la revisión debe considerar ambos.
Cápsula citable: La configuración MCP debe pasar por un gate de CI como IaC. La especificación MCP recomienda control humano para herramientas model-controlled (Model Context Protocol, consultado el 2026-07-09); en desarrollo, eso se vuelve diff revisable y code owner.
¿Dónde entran OAuth, alcances y secretos?
En 2025, la especificación más reciente de autorización MCP volvió obligatoria la validación de audience en tokens y prohibió aceptar tokens emitidos para otro recurso (Model Context Protocol, "Authorization", 2025-11-25, consultado el 2026-07-09). El alcance no es detalle de login. Es límite operativo del agente.
Evita secretos permanentes en configuración personal. Prefiere variables de entorno controladas, tokens de corta duración, alcance read-only por defecto y step-up cuando la operación realmente exige escritura. Si una herramienta necesita files:write, no debe compartir token con una herramienta de lectura.
La misma especificación exige que el access token vaya en el encabezado Authorization y no en query string, y recomienda retry limits cuando hay error de alcance insuficiente (Model Context Protocol, "Authorization", 2025-11-25, consultado el 2026-07-09). Para agentes, una falla de permiso debe detenerse o pedir alcance, no buscar una ruta alternativa.
Cápsula citable: OAuth en MCP debe reducir agencia, no ocultar riesgo. La especificación de 2025 exige token con audience correcta, prohíbe token en query string y orienta límites de retry en step-up (Model Context Protocol, consultado el 2026-07-09).
¿Cómo probar contra tool poisoning?
En 2026, la investigación de MCP evaluó siete clientes contra cuatro tipos de tool poisoning y señaló que cinco no aplicaban validación estática a descripciones de herramienta (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado el 2026-07-09). La prueba de MCP debe simular herramienta hostil, no solo servidor caído.
Monta un servidor falso en ambiente local con descripciones sospechosas, parámetros largos, retorno con instrucción maliciosa e intento de acceso fuera del alcance. El agente debe rechazar, pedir confirmación o quedar limitado por el harness. Si ejecuta sin fricción, la allowlist está solo documentada.
OWASP lista prompt injection, insecure plugin design y excessive agency entre riesgos de aplicaciones con LLMs (OWASP, "Top 10 for Large Language Model Applications", 2025, consultado el 2026-07-09). MCP cruza esos riesgos porque la herramienta se vuelve puente entre texto, sistema externo y acción.
Cápsula citable: La prueba de tool poisoning valida la frontera del agente. La investigación de 2026 mostró cinco de siete clientes sin validación estática (arXiv, consultado el 2026-07-09); los equipos deben probar descripciones, parámetros, salidas y llamadas fuera de alcance.
¿Qué implementar esta semana?
En 2026, GitHub lanzó Agent Finder con descubrimiento desde un registro elegido y settings gestionados que limitan qué recursos pueden descubrir y usar los agentes (GitHub Changelog, "Agent finder for GitHub Copilot now available", 2026, consultado el 2026-07-09). El camino práctico es controlar descubrimiento, permiso y ejecución por capas.
Empieza con inventario. Lista los servidores MCP usados por Codex, Claude Code, Copilot, IDEs y automatizaciones de CI. Luego marca herramientas de lectura, escritura y ejecución. Promueve a allowlist solo lo que tenga dueño, fuente, versión y razón de uso en el repositorio.
Después agrega gate. Cualquier cambio que amplíe tools, cambie URL, cambie comando, agregue variable sensible o libere wildcard debe fallar hasta revisión. En el PR, pide al agente registrar qué herramientas llamó, con argumento resumido y resultado verificable. Sin ese rastro, el revisor no sabe si el patch nació de contexto confiable.
Por fin, conecta esto con tus evals de PR para agentes y con el loop self-correcting en CI. MCP no debe ser excepción al harness. Es una entrada operativa del harness.
Preguntas frecuentes sobre allowlist de MCP
¿Una allowlist de servidor MCP alcanza?
No. En 2026, GitHub Docs recomendó allowlist de herramientas read-only específicas porque Copilot puede usarlas autónomamente sin aprobación (GitHub Docs, "Configure MCP servers", 2026, consultado el 2026-07-09). Un servidor aprobado todavía puede exponer una herramienta demasiado amplia.
¿Un registro privado reemplaza revisión de seguridad?
No. En 2026, GitHub describió registro propio como forma de impedir uso de servidores fuera de la lista en runtime (GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", 2026, consultado el 2026-07-09). La revisión decide qué entra al registro.
¿Tool poisoning es riesgo real en agentes de código?
Sí. En 2026, la investigación de MCP evaluó siete clientes contra cuatro ataques de tool poisoning y encontró brechas de validación, visibilidad y logging (arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", 2026, consultado el 2026-07-09). Código amplía el impacto porque una herramienta puede influir en el patch.
¿Debo bloquear toda herramienta de escritura?
No siempre. En 2025, la especificación MCP recomendó confirmación humana para operaciones sensibles y log de uso de herramientas (Model Context Protocol, "Tools", 2025-06-18, consultado el 2026-07-09). La escritura puede existir, pero necesita alcance, aprobación, token separado y evidencia en el PR.
Cierre
MCP con allowlist no es burocracia. Es la forma de convertir tool use en contrato de ingeniería. El agente puede seguir rápido, pero solo dentro de capacidades que el equipo aceptó revisar, auditar y revocar.
Empieza por la superficie menor: lectura aprobada, escritura bloqueada y wildcard prohibido. Cuando el equipo tenga logs confiables, agrega herramientas más sensibles con alcance y code owner. El objetivo no es reducir MCP. Es impedir que una herramienta útil se vuelva permiso invisible.
Fuentes consultadas
- arXiv, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning", consultado el 2026-07-09, https://arxiv.org/html/2603.22489v1
- GitHub Changelog, "Copilot CLI supports custom registry based MCP allowlists", consultado el 2026-07-09, https://github.blog/changelog/2026-04-16-copilot-cli-supports-custom-registry-based-mcp-allowlists/
- GitHub Changelog, "GitHub MCP Registry: The fastest way to discover AI tools", consultado el 2026-07-09, https://github.blog/changelog/2025-09-16-github-mcp-registry-the-fastest-way-to-discover-ai-tools/
- GitHub Changelog, "Agent finder for GitHub Copilot now available", consultado el 2026-07-09, https://github.blog/changelog/2026-06-17-agent-finder-for-github-copilot-now-available/
- GitHub Docs, "Configure MCP servers for your repository", consultado el 2026-07-09, https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
- Model Context Protocol, "Tools", consultado el 2026-07-09, https://modelcontextprotocol.io/specification/2025-06-18/server/tools
- Model Context Protocol, "Authorization", consultado el 2026-07-09, https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- NSA, "Model Context Protocol: Security Design Considerations", consultado el 2026-07-09, https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
- OWASP, "Top 10 for Large Language Model Applications", consultado el 2026-07-09, https://owasp.org/www-project-top-10-for-large-language-model-applications/
