GitHub MCP Server: detecta secretos y dependencias vulnerables antes del commit

El problema de usar agentes de IA para programar no es que escriban código rápido.

El problema es que pueden escribir código rápido con tus secretos dentro.

Una API key pegada en un .env equivocado.

Un token temporal que se queda en un test.

Una DATABASE_URL real usada para probar algo deprisa.

Una dependencia vulnerable añadida por el agente porque “parecía la opción más cómoda”.

Y cuando te das cuenta, ya está en el commit, en la pull request o, peor todavía, en el repositorio remoto.

Aquí es donde GitHub MCP Server empieza a ser interesante de verdad.

No como otra moda más de IA.

Sino como una capa práctica para que tus herramientas, tu IDE o tu coding agent puedan pedir a GitHub que revise cambios antes de que lleguen al repositorio.

En mayo de 2026, GitHub anunció que secret scanning con GitHub MCP Server ya está generalmente disponible para repositorios con Secret Protection habilitado. Además, lanzó en public preview el escaneo de dependencias vulnerables mediante GitHub MCP Server para repositorios con Dependabot alerts activado.

Esto cambia bastante el flujo.

Porque hasta ahora muchas revisiones de seguridad llegaban tarde.

Ahora puedes llevar parte de esa revisión al momento en el que realmente estás escribiendo código.

Antes del commit.

Antes de la pull request.

Antes del susto.

Qué vas a ver en esta guía#

En esta guía vamos a aterrizarlo de forma práctica:

• qué es GitHub MCP Server
• por qué importa si usas agentes de IA
• cómo ayuda con secret scanning
• cómo encaja el dependency scanning
• cómo configurarlo en un flujo real
• qué prompts usar con tu agente
• qué errores evitar
• cómo combinarlo con buenas prácticas de seguridad

La idea no es montar una demo bonita.

La idea es dejar un flujo usable para desarrollo real.

Qué es GitHub MCP Server#

GitHub MCP Server es un servidor compatible con Model Context Protocol, el estándar que permite que un agente de IA use herramientas externas de forma estructurada.

Dicho fácil:

> Es una forma de conectar tu agente con GitHub para que pueda consultar repositorios, issues, pull requests, acciones, seguridad y otros recursos usando herramientas controladas.

No es simplemente “darle acceso a GitHub al chatbot”.

Es más parecido a esto:

1. tu agente necesita información
2. el cliente MCP expone herramientas disponibles
3. el agente pide ejecutar una herramienta concreta
4. GitHub MCP Server procesa la acción
5. GitHub devuelve una respuesta estructurada
6. el agente te ayuda con el resultado

Esto encaja muy bien con herramientas como:

• GitHub Copilot
• VS Code
• Cursor
• Claude Code
• clientes MCP compatibles
• flujos agentic en desarrollo

La gracia es que el agente no solo “opina”.

Puede usar herramientas reales.

Y eso es justo lo que permite llevar seguridad al flujo de trabajo.

Por qué esto importa ahora#

La IA está acelerando el desarrollo.

Pero también está acelerando los errores.

Antes un desarrollador podía copiar una API key por despiste.

Ahora un agente puede generar una configuración completa, una prueba, un script de despliegue o una integración con credenciales simuladas que se parecen demasiado a las reales.

Y si no hay revisión, todo eso puede acabar en Git.

Ejemplos típicos:

OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxx
DATABASE_URL=postgresql://user:pass@host:5432/app
STRIPE_SECRET_KEY=sk_test_51xxxxxxxxxxxxxxxx
AWS_SECRET_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE
JWT_SECRET=super_secret_value_2026

Esto no debería terminar nunca en el repositorio.

Ni en producción.

Ni en una rama temporal.

Ni en una pull request.

Ni en un comentario generado por un agente.

El problema es que cuando trabajas rápido, revisas menos.

Y cuando trabajas con agentes, a veces delegas demasiado.

Por eso tiene sentido meter una capa de seguridad en el momento anterior al commit.

Secret scanning antes del commit#

El cambio importante de GitHub MCP Server es que el agente puede pedir a GitHub que analice tus cambios actuales en busca de secretos expuestos.

No hablamos solo de revisar lo que ya está subido.

Hablamos de revisar cambios antes de que los confirmes.

Un prompt típico podría ser:

Escanea mis cambios actuales en busca de secretos expuestos antes de hacer commit.
Muéstrame el archivo, la línea afectada y cómo corregirlo.

O algo más directo:

Antes de hacer commit, revisa si he dejado tokens, API keys, credenciales o URLs sensibles en los cambios actuales.

Si el agente tiene disponible la herramienta MCP adecuada, puede invocar el flujo de secret scanning y devolverte resultados accionables.

Esto es muy útil porque reduce el típico ciclo peligroso:

escribir código -> commit -> push -> alerta -> pánico -> rotar secreto -> limpiar historial

Por este otro:

escribir código -> escanear con MCP -> corregir -> commit seguro

La diferencia parece pequeña.

Pero en seguridad, llegar antes lo cambia todo.

Dependency scanning antes del commit#

El segundo punto interesante es el escaneo de dependencias vulnerables.

GitHub anunció que el dependency scanning con GitHub MCP Server está en public preview para repositorios con Dependabot alerts activado.

Esto permite que el agente revise cambios en dependencias antes de hacer commit o abrir una pull request.

Por ejemplo, imagina que el agente añade esto:

{
  "dependencies": {
    "lodash": "4.17.20",
    "axios": "0.21.0"
  }
}

O esto en PHP:

{
  "require": {
    "symfony/http-foundation": "5.4.0",
    "guzzlehttp/guzzle": "6.5.0"
  }
}

El problema no es solo que compile.

El problema es si esa versión arrastra vulnerabilidades conocidas.

Con el flujo MCP, puedes pedir algo así:

Revisa las dependencias modificadas en esta rama y dime si alguna versión tiene vulnerabilidades conocidas.
Incluye severidad, paquete afectado y versión recomendada para corregirlo.

O:

Antes de hacer commit, analiza package.json, composer.json y lockfiles modificados para detectar dependencias vulnerables.

Esto convierte al agente en algo más útil que un generador de código.

Lo convierte en una especie de copiloto de seguridad temprana.

Qué necesitas para usarlo#

Depende del entorno exacto, pero a nivel práctico necesitas tres cosas:

1. un repositorio en GitHub
2. GitHub MCP Server configurado en tu entorno o cliente compatible
3. las funciones de seguridad correspondientes activadas

Para secret scanning:

• repositorio compatible con GitHub Secret Protection
• usuario con permisos adecuados
• cliente MCP o integración compatible

Para dependency scanning:

• Dependabot alerts activado
• toolset correspondiente disponible en GitHub MCP Server
• cambios en dependencias que el agente pueda analizar

No lo veas como “instalo una cosa y ya soy seguro”.

Velo como una capa más dentro de un flujo serio.

Configuración conceptual con MCP#

La configuración exacta puede cambiar según el cliente MCP que uses.

Pero la idea suele parecerse a esto:

{
  "mcpServers": {
    "github": {
      "command": "github-mcp-server",
      "args": ["stdio"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
      }
    }
  }
}

La parte importante no es copiar este JSON a ciegas.

La parte importante es entender lo que está pasando:

• registras un servidor MCP llamado github
• el cliente puede arrancarlo o conectarse a él
• el servidor expone herramientas de GitHub
• el agente puede usar esas herramientas cuando se lo pidas
• el token no debería estar hardcodeado en el archivo

Ese último punto es clave.

No pongas esto:

{
  "env": {
    "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_token_real_aqui"
  }
}

Esto es justo lo que estás intentando evitar.

Mejor usa una variable de entorno gestionada fuera del repositorio:

export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_xxxxxxxxxxxxxxxxx"

Y en el archivo de configuración:

{
  "env": {
    "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
  }
}

Limita los permisos del token#

Otro error típico es darle al agente un token con demasiado poder.

Si tu agente solo necesita revisar seguridad, no necesita permisos de administración de toda la organización.

Aplica el principio de mínimo privilegio.

Eso significa:

• token específico para este flujo
• permisos mínimos necesarios
• duración limitada cuando sea posible
• rotación periódica
• nada de tokens personales eternos compartidos entre proyectos

El objetivo no es que el agente “pueda hacerlo todo”.

El objetivo es que pueda hacer solo lo que necesita.

Toolsets: no actives todo por comodidad#

GitHub MCP Server permite trabajar con grupos de herramientas o toolsets.

Y esto importa mucho.

Porque cuantos más toolsets actives, más superficie le das al agente.

Un mal patrón sería activar todo porque sí:

github-mcp-server --toolsets all

Funciona, sí.

Pero no siempre es buena idea.

Un enfoque más razonable sería activar solo lo necesario para tu caso.

Por ejemplo:

github-mcp-server --toolsets repos,pull_requests,secret_protection,dependabot

O si tu caso es solo seguridad:

github-mcp-server --toolsets secret_protection,dependabot

La idea es simple:

> si el agente no necesita una herramienta, no se la des.

Esto mejora seguridad, reduce ruido y ayuda al modelo a elegir mejor qué herramienta usar.

Flujo recomendado antes de hacer commit#

Un flujo práctico podría ser este:

git status

Revisas qué has tocado:

git diff --stat

Le pides al agente que analice secretos:

Escanea los cambios actuales con GitHub MCP Server y dime si hay secretos expuestos.
No hagas commit. Solo analiza y dame correcciones concretas.

Después revisas dependencias:

Revisa los cambios de dependencias de esta rama con GitHub MCP Server.
Indica si hay paquetes vulnerables, severidad y versión recomendada.

Corriges lo que toque.

Luego haces commit:

git add .
git commit -m "feat: add secure integration flow"

Y solo después subes:

git push origin feature/secure-flow

Esto parece más lento.

Pero te ahorra muchísimo más tiempo del que cuesta.

Porque arreglar un secreto antes del commit tarda segundos.

Arreglarlo después de subirlo puede implicar:

• revocar token
• generar credenciales nuevas
• limpiar historial
• avisar al equipo
• revisar accesos
• desplegar configuración nueva
• documentar el incidente

Prompt útil para usar con tu agente#

Puedes guardar un prompt estándar en tu AGENTS.md, CLAUDE.md o documentación interna.

Por ejemplo:

## Revisión de seguridad antes de commit

Antes de proponer un commit, revisa los cambios actuales usando GitHub MCP Server.

Comprueba:

- secretos expuestos
- API keys
- tokens
- credenciales en archivos de configuración
- URLs con usuario y contraseña
- cambios en dependencias vulnerables
- lockfiles modificados

No hagas commit hasta que la revisión sea limpia.
Si encuentras problemas, indica archivo, línea, riesgo y corrección recomendada.

Esto es muy útil porque convierte la seguridad en una rutina.

No depende de que te acuerdes cada vez.

El agente ya tiene la regla.

Ejemplo de AGENTS.md para este flujo#

Si usas agentes de código, puedes añadir una sección como esta:

# AGENTS.md

## Seguridad obligatoria

Nunca hardcodees secretos, tokens, contraseñas, API keys ni URLs con credenciales.

Antes de sugerir un commit:

1. revisa los cambios actuales
2. ejecuta secret scanning mediante GitHub MCP Server si está disponible
3. revisa cambios en dependencias mediante dependency scanning si está disponible
4. si hay hallazgos, detén el commit y explica cómo corregirlos

## Variables de entorno

Usa `.env.example` para documentar nombres de variables, pero nunca valores reales.

Ejemplo correcto:

OPENAIAPIKEY=

DATABASE_URL=

STRIPESECRETKEY=

Ejemplo incorrecto:

OPENAIAPIKEY=sk-real-value

DATABASE_URL=postgresql://user:password@host:5432/app

## Commits

No hagas commit si:

- hay secretos detectados
- hay credenciales reales en el diff
- hay dependencias vulnerables sin justificar
- hay archivos `.env` reales incluidos

Este tipo de instrucciones no hacen magia.

Pero reducen bastante los errores tontos.

Y con IA, los errores tontos escalan muy rápido.

Qué archivos deberías vigilar especialmente#

Hay archivos donde los secretos aparecen más de lo que deberían.

Especialmente estos:

.env
.env.local
.env.production
.env.staging
docker-compose.yml
docker-compose.override.yml
compose.yaml
config/*.php
config/*.ts
.github/workflows/*.yml
package.json
composer.json
README.md
scripts/*.sh

También hay patrones peligrosos:

password=
passwd=
secret=
token=
api_key=
access_key=
client_secret=
private_key=
DATABASE_URL=

Una revisión manual ayuda.

Pero una revisión automatizada ayuda más.

Y si además la puede pedir tu agente antes del commit, mejor todavía.

Buen .gitignore para evitar sustos#

No dependas solo del escaneo.

Evita que ciertos archivos entren en Git desde el principio.

Ejemplo:

# Environment files
.env
.env.*
!.env.example

# Secrets
*.pem
*.key
*.p12
*.pfx
id_rsa
id_ed25519

# Local tooling
.cursor/
.claude/local/

# Logs
*.log
npm-debug.log*
yarn-debug.log*
pnpm-debug.log*

# OS / editor
.DS_Store
.idea/
.vscode/settings.json

Ojo con esta línea:

.env.*
!.env.example

Es muy útil porque ignora .env.local, .env.production, .env.staging, etc., pero permite subir .env.example.

.env.example bien planteado#

El .env.example debe documentar qué variables existen, no contener valores reales.

Correcto:

APP_ENV=local
APP_URL=http://localhost:3000

DATABASE_URL=
OPENAI_API_KEY=
GITHUB_TOKEN=
STRIPE_SECRET_KEY=
JWT_SECRET=

Incorrecto:

DATABASE_URL=postgresql://admin:SuperPassword@prod-db:5432/app
OPENAI_API_KEY=sk-real-token
GITHUB_TOKEN=ghp_real_token

Parece obvio.

Pero en proyectos con prisas, demos, agentes y pruebas rápidas, estas cosas pasan.

Pre-commit local como segunda capa#

GitHub MCP Server está muy bien, pero no tiene por qué ser la única barrera.

Puedes combinarlo con hooks locales.

Por ejemplo, usando pre-commit:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.0
    hooks:
      - id: gitleaks

Instalas:

pip install pre-commit
pre-commit install

Y pruebas:

pre-commit run --all-files

Otra opción es usar herramientas como:

gitleaks detect --source .

La idea no es elegir una sola protección.

La idea es tener capas:

• .gitignore
• .env.example limpio
• GitHub MCP Server antes del commit
• pre-commit local
• secret scanning en GitHub
• push protection
• revisión en pull request

Cuantas más capas razonables, menos depende todo de acordarte en el momento justo.

Ejemplo con package.json#

Supón que el agente añade una dependencia:

{
  "dependencies": {
    "express": "4.18.2",
    "jsonwebtoken": "8.5.1",
    "lodash": "4.17.20"
  }
}

Antes de aceptar el commit, puedes pedir:

Revisa las dependencias modificadas en package.json y package-lock.json con GitHub MCP Server.
Dime si hay vulnerabilidades conocidas y qué versiones debo usar.

El resultado debería darte algo accionable:

Paquete: lodash
Versión actual: 4.17.20
Riesgo: vulnerabilidad conocida
Recomendación: actualizar a 4.17.21 o superior

Esto no sustituye una auditoría completa.

Pero sí evita que metas problemas conocidos de forma silenciosa.

Ejemplo con composer.json#

En proyectos PHP o Laravel, el flujo es igual de útil.

Imagina un cambio en composer.json:

{
  "require": {
    "php": "^8.3",
    "laravel/framework": "^13.0",
    "guzzlehttp/guzzle": "6.5.0"
  }
}

Puedes pedir:

Analiza composer.json y composer.lock con GitHub MCP Server.
Comprueba si las dependencias añadidas o modificadas tienen vulnerabilidades conocidas.

Y si hay algo raro, lo corriges antes del commit.

Esto encaja especialmente bien en proyectos donde un agente te propone paquetes para resolver problemas.

Porque el agente puede elegir una librería útil, pero no siempre elegir la versión más segura.

No todo debe resolverlo el agente#

Este punto es importante.

GitHub MCP Server ayuda.

Secret scanning ayuda.

Dependency scanning ayuda.

Pero no convierten a tu agente en un responsable de seguridad infalible.

No deberías usar esto como excusa para dejar de revisar.

De hecho, el flujo bueno es:

agente propone -> herramientas escanean -> desarrollador decide

No:

agente propone -> agente aprueba -> agente commitea -> nadie mira

La IA puede acelerar muchísimo.

Pero la responsabilidad sigue siendo tuya.

Riesgos específicos con MCP#

MCP es potente porque permite conectar herramientas.

Pero precisamente por eso hay que tomárselo en serio.

Un servidor MCP puede exponer capacidades delicadas:

• leer repositorios
• crear issues
• abrir pull requests
• consultar alertas
• ejecutar acciones
• acceder a metadatos sensibles
• interactuar con sistemas internos

Por eso conviene aplicar varias reglas:

1. no instales MCP servers desconocidos sin revisarlos
2. limita toolsets
3. usa tokens con permisos mínimos
4. evita credenciales hardcodeadas
5. separa entornos personales, laborales y de producción
6. revisa qué herramientas tiene disponibles cada agente
7. no mezcles secretos reales con prompts largos
8. no des acceso de escritura si solo necesitas lectura

MCP no es malo.

Pero MCP sin control es peligroso.

Qué debería hacer tu agente cuando encuentra un secreto#

No basta con decir:

Hay un secreto.

Una buena respuesta debería incluir:

• archivo afectado
• línea aproximada
• tipo de secreto
• riesgo
• corrección recomendada
• si hace falta rotar la credencial
• si el secreto llegó o no a Git

Ejemplo:

He detectado una posible API key en `.env.local`, línea 4.

Riesgo:
- permite acceso directo a un proveedor externo
- no debe guardarse en Git

Corrección:
- elimina el valor real
- mueve la clave a tu gestor de secretos local
- deja solo el nombre de variable en `.env.example`

Si esta clave ya fue commiteada o subida, rótala inmediatamente.

Esto sí ayuda.

Una alerta genérica no.

Qué hacer si el secreto ya llegó al repositorio#

Si el secreto ya llegó a GitHub, no basta con borrarlo en un commit posterior.

El historial sigue teniendo el valor.

Pasos recomendados:

1. revoca o rota el secreto inmediatamente
2. comprueba si hubo uso sospechoso
3. elimina el valor del código
4. actualiza .gitignore y .env.example
5. revisa historial si procede
6. activa secret scanning y push protection
7. documenta el incidente si es un entorno profesional

La clave es esta:

> secreto subido = secreto comprometido

Aunque nadie lo haya usado todavía.

Trátalo como comprometido.

Checklist práctico para tu proyecto#

Antes de publicar este flujo en tu equipo o repositorio, revisa:

• [ ] GitHub MCP Server configurado
• [ ] Secret Protection activado donde corresponda
• [ ] Dependabot alerts activado
• [ ] toolsets limitados a lo necesario
• [ ] token sin permisos excesivos
• [ ] .env ignorados por Git
• [ ] .env.example limpio
• [ ] instrucciones en AGENTS.md o CLAUDE.md
• [ ] prompt estándar de revisión antes de commit
• [ ] pre-commit local opcional
• [ ] push protection activado si aplica
• [ ] documentación mínima para el equipo

Si tienes todo esto, ya no estás usando agentes a ciegas.

Estás metiendo límites.

Y eso es justo lo que hace falta.

Ejemplo de flujo completo#

Un flujo real podría quedar así:

# 1. Ver cambios
git status
git diff --stat

Luego pides al agente:

Antes de hacer commit, usa GitHub MCP Server para revisar:

1. secretos expuestos en los cambios actuales
2. dependencias vulnerables añadidas o modificadas
3. archivos de configuración sensibles que no deberían subirse

No modifiques archivos todavía.
Primero dame un informe breve con riesgos y correcciones recomendadas.

Si todo está bien:

git add .
git commit -m "feat: add github mcp security workflow"
git push origin feature/github-mcp-security

Si hay problemas:

# Corriges primero
# Vuelves a escanear
# Solo entonces commiteas

Esto es lo que deberíamos buscar con IA aplicada al desarrollo:

menos magia, más flujo.

Dónde encaja esto en un stack real#

Este flujo encaja muy bien si trabajas con:

• Laravel
• Symfony
• Next.js
• Node.js
• WordPress profesional
• APIs internas
• microservicios
• automatizaciones con GitHub Actions
• despliegues en VPS
• Docker Compose
• integraciones con IA
• agentes como Claude Code, Cursor o Copilot

Especialmente si tienes:

• .env
• tokens de proveedores externos
• APIs privadas
• claves de IA
• credenciales de base de datos
• servicios cloud
• dependencias que se actualizan a menudo

Es decir: prácticamente cualquier proyecto moderno.

Mi opinión#

GitHub MCP Server no es importante solo porque sea “MCP”.

Es importante porque lleva una parte de la seguridad al sitio correcto:

el momento en el que estás escribiendo código.

Ahí es donde se cometen muchos errores.

Y ahí es donde más barato es corregirlos.

En 2026, usar agentes para programar sin una capa mínima de seguridad empieza a parecerse demasiado a conducir rápido sin cinturón.

Puedes hacerlo.

Hasta que un día no.

Conclusión#

Los coding agents van a formar parte del desarrollo diario.

Eso ya no parece una hipótesis.

Pero cuanto más poder les damos, más necesitamos poner límites claros.

GitHub MCP Server con secret scanning y dependency scanning apunta justo en esa dirección:

• agentes más útiles
• commits más seguros
• menos secretos expuestos
• menos dependencias vulnerables
• feedback antes de llegar al repositorio

No elimina la revisión humana.

No sustituye una estrategia de seguridad.

Pero sí añade una capa muy interesante justo donde más falta hace.

Antes del commit.

Y eso, en proyectos reales, puede marcar la diferencia.

Recursos recomendados#

• GitHub MCP Server oficial
• Documentación de GitHub Secret Scanning con MCP Server
• Documentación de push protection con GitHub MCP Server
• GitHub Advanced Security
• Dependabot alerts
• Gitleaks
• pre-commit

FAQ#

¿GitHub MCP Server sustituye a GitHub Advanced Security?#

No. Es una forma de llevar capacidades de GitHub al flujo de trabajo con agentes e IDEs compatibles. Lo correcto es verlo como una capa más dentro de una estrategia de seguridad.

¿Puedo usarlo con Claude Code, Cursor o VS Code?#

Depende del soporte MCP y de la configuración concreta de cada herramienta. La idea general es que cualquier cliente compatible con MCP puede integrarse con servidores MCP, pero conviene revisar la documentación de tu cliente.

¿Esto evita al 100% que suba secretos?#

No. Nada lo evita al 100%. Pero reduce muchísimo el riesgo si lo combinas con .gitignore, .env.example, push protection, secret scanning y buenas prácticas de permisos.

¿Dependency scanning está estable?#

En mayo de 2026, GitHub lo anunció en public preview para GitHub MCP Server, por lo que conviene tratarlo como una capacidad útil pero todavía en evolución.

¿Qué es lo más importante al configurarlo?#

No hardcodear tokens, limitar permisos, activar solo toolsets necesarios y pedir explícitamente al agente que revise antes del commit.