GitHub MCP secret scanning: agentes IA sin filtrar tokens

TL;DR: GitHub MCP Server llevó secret scanning a disponibilidad general (GA). Si usas Claude Code, Codex u otro agente conectado por MCP a tus repos, ahora puedes detectar tokens, claves de API y credenciales filtradas dentro del propio loop del agente, no solo al final en CI. Te enseño cómo activarlo, qué cambia en tu flujo diario y dónde están los límites.

El problema: el agente toca tus repos sin filtros

Un agente moderno con permisos de escritura es cómodo y peligroso a partes iguales. En sesiones reales con Claude Code he visto patrones que se repiten: archivos .env copiados como ejemplo en un README, tokens de Pinecone pegados en un script de prueba, credenciales de GitLab CI que terminan en un test local antes de un commit.

El secret scanning clásico de GitHub corre después de que el código llegue al servidor. Cuando el agente trabaja en local con tu permiso, ya hay una ventana de exposición: el secreto vive en tu disco, en logs de la sesión y, si te despistas, en un commit. La novedad de mayo de 2026 es que GitHub MCP Server expone esa capacidad de scanning como una herramienta más para el agente, lo que permite cerrar el bucle antes de empujar nada.

¿Qué es GitHub MCP Server?

GitHub MCP Server es la implementación oficial del Model Context Protocol que conecta agentes de IA (Claude Code, Codex, Cursor) con la API de GitHub mediante herramientas tipadas. Permite al agente leer repos, abrir PRs, gestionar issues y, ahora, ejecutar análisis de seguridad sobre el código que está manipulando.

Si nunca trabajaste con MCP, piénsalo como un puente con contrato: el agente no llama a la API REST a ciegas, llama a herramientas concretas (create_pull_request, list_secret_scanning_alerts) que ya validan parámetros y devuelven datos estructurados. Para entender mejor cómo encajan estas piezas, este post sobre memoria, MCPs y mapa de repo en Claude Code explica el modelo mental.

¿Qué es secret scanning y por qué importa ahora?

Secret scanning detecta cadenas que parecen credenciales (tokens, claves privadas, conexiones de bases de datos) usando reglas mantenidas por GitHub y por proveedores asociados. Llevaba años cubriendo repos públicos y, con GitHub Advanced Security, también privados.

Lo que cambia con el GA en MCP es el punto del flujo donde puedes invocarlo:

Antes: alerta tras el push, en la pestaña Security del repo.
Ahora: el agente puede listar alertas activas, comprobar archivos modificados y bloquear su propio commit si detecta un patrón conocido.

Para un equipo pequeño con presupuesto ajustado (10-30€/mes en herramientas de IA), esto significa una capa de defensa más sin pagar otro SaaS de DLP.

Configuración paso a paso con Claude Code

El servidor remoto oficial vive en https://api.githubcopilot.com/mcp/ y se autentica con OAuth o con un Personal Access Token (PAT) de granularidad fina. Para sesiones locales con Claude Code, el flujo más limpio es OAuth.

1. Registrar el servidor MCP

El siguiente bloque añade GitHub MCP a tu configuración de Claude Code (archivo ~/.claude/mcp.json o equivalente según tu setup):

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "transport": "http"
    }
  }
}

Si prefieres correrlo en local con Docker (útil si tu empresa bloquea servidores remotos), la imagen oficial ghcr.io/github/github-mcp-server acepta un PAT por variable de entorno.

2. Habilitar el toolset de seguridad

Por defecto, GitHub MCP carga un subconjunto de herramientas para no inflar el contexto. Las relacionadas con secret scanning están en el toolset code_security, que activas con un flag al iniciar el servidor:

# Activa solo los toolsets que vas a usar para reducir tokens por turno
github-mcp-server --toolsets repos,pull_requests,code_security

Reducir toolsets importa: cargar todos puede sumar miles de tokens a cada turno. Hablé del coste real de las definiciones MCP en este análisis sobre los 18.000 tokens ocultos por turno.

3. Probar la herramienta desde el agente

Una vez registrado, le pides a Claude que liste alertas activas en un repo concreto. El agente invoca list_secret_scanning_alerts y devuelve algo como:

[
  {
    "number": 12,
    "state": "open",
    "secret_type": "openai_api_key",
    "resolution": null,
    "created_at": "2026-05-04T09:12:00Z"
  }
]

Comparativa: scanning en CI vs scanning en el agente

Aspecto	Solo en CI	En el loop del agente
Detección	Tras push	Antes del commit
Coste por hallazgo	Rotación urgente del secreto	Corrección en sesión
Coste extra	Incluido en GHAS	Tokens MCP por turno
Cobertura	Solo lo empujado	Local + remoto
Riesgo principal	Logs y mirrors públicos	Falsos negativos en strings ofuscadas

El consejo práctico: no sustituyas, suma. El scanning en CI sigue siendo tu última línea; el del agente es el primer cinturón.

Caso real: bloquear un commit con clave filtrada

Patrón que uso en sesiones de Claude Code cuando trabajo con repos que tocan APIs de pago. Antes de cada commit grande, instruyo al agente con una regla en el CLAUDE.md del proyecto:

# Regla de seguridad obligatoria antes de cualquier commit
- Ejecuta `list_secret_scanning_alerts` sobre los archivos modificados.
- Si hay alerta abierta de tipo `*_api_key` o `private_key`, aborta y avisa.
- Nunca rotes secretos sin confirmación explícita del usuario.

El agente respeta la regla porque está en el contexto persistente del proyecto. La diferencia frente a confiar solo en GitHub Actions es que el secreto nunca llega al historial: la corrección ocurre en el archivo local, antes de git add.

En Producción

Cuatro consideraciones que separan un tutorial de un setup real:

Permisos del PAT. Usa fine-grained tokens con scope secret_scanning_alerts: read y nada más para esta función. Evita PATs amplios que el agente pueda usar fuera de contexto.
Coste de tokens. Cada llamada a una tool de MCP consume contexto. Si tu agente lista alertas en cada turno, vas a ver el efecto en la factura. Limita la herramienta a checks explícitos antes de operaciones de escritura.
Falsos positivos. Las reglas de scanning son buenas con tokens estándar (OpenAI, Stripe, AWS) pero fallan con formatos custom de tu empresa. Combina con detección semántica del propio agente: pídele que revise diffs grandes con un prompt de seguridad.
Auditoría. Si trabajas con datos regulados, registra qué tools usó el agente. GitHub MCP devuelve metadata por respuesta; puedes loguearla a un fichero local.

Errores comunes y depuración

Error: 403 Forbidden al llamar a la tool. Causa: el PAT no tiene scope secret_scanning_alerts: read o el repo no tiene Advanced Security activado. Solución: revisa permisos en github.com/settings/tokens y confirma plan del repo.
Error: la tool no aparece en la lista del agente. Causa: olvidaste el flag --toolsets code_security o el agente cacheó las definiciones. Solución: reinicia la sesión MCP y verifica con claude mcp list.
Error: alertas no detectan tu token interno. Causa: GitHub solo escanea patrones registrados. Solución: registra un patrón custom en Secret scanning custom patterns o añade una regla pre-commit en paralelo.

Preguntas frecuentes

¿Necesito GitHub Advanced Security para usar esta función?

Para repos privados, sí: secret scanning en privados requiere GHAS. En repos públicos está disponible sin coste. Si tu empresa no paga GHAS, la alternativa es correr github-mcp-server con detección local basada en gitleaks o trufflehog como fallback.

¿Esto sustituye a las herramientas pre-commit como gitleaks?

No. Cubren capas distintas: gitleaks corre offline en tu hook de git y no depende de GitHub; el scanning vía MCP integra el resultado en el razonamiento del agente. En equipos pequeños, lo razonable es mantener gitleaks como red de seguridad y usar MCP para el flujo asistido.

¿Funciona con Codex y otros agentes?

Sí. MCP es estándar abierto, así que cualquier agente que hable el protocolo puede registrar el servidor de GitHub. Si dudas qué herramienta usar para qué tarea, este artículo sobre OpenClaw y Claude Code para perfiles senior aclara los criterios.

Lo que me llevo

Mover secret scanning al loop del agente cambia la postura de seguridad sin pedir herramientas nuevas: aprovecha lo que GitHub ya hace y lo pone donde tu IA toma decisiones. La parte interesante no es la detección en sí, sino que la seguridad deja de ser una etapa al final y se convierte en una herramienta más dentro de la conversación con el agente.

Si esto te interesa, el siguiente paso natural es revisar cómo separar permisos por proyecto, algo que conecta directo con el principio de separación de responsabilidades aplicado a la arquitectura de tu agente. Y si trabajas con paquetes externos en sesiones de Claude Code, también vale la pena ver el patrón de MCP defensivo frente a paquetes que no existen.

¿Has activado ya secret scanning en tu setup MCP o sigues confiando solo en CI? Cuéntamelo en Twitter @sergiomarquezp_; me interesa saber qué falsos positivos os están saliendo en repos de empresa.