)
Última actualización: 23 de octubre, 2026
¿Qué es GitHub MCP y cómo lo proteges? GitHub MCP es el servidor oficial de GitHub para Model Context Protocol, que permite a los agentes de IA leer y modificar repositorios, issues, pull requests y workflows. Lo proteges por capas: una credencial acotada, pocas tools y modo de solo lectura o lockdown. Después inspeccionas en runtime lo que el agente lee y ejecuta.
TL;DR: puntos clave
- El servidor GitHub MCP documenta 22 toolsets y 92 tools, y carga 5 toolsets por defecto si no cambias la configuración (GitHub).
- El 26 de mayo de 2025, 1 issue público malicioso bastó para que un agente expusiera datos privados en un pull request público (Simon Willison).
- Cargar de 3 a 10 tools redujo el uso de contexto entre un 60% y un 90% en las pruebas de GitHub (GitHub Changelog).
- El lockdown mode, anunciado el 10 de diciembre de 2025, es un filtro de contenido best-effort, no una frontera de autorización (GitHub).
- 2 advisories de 2026: una denegación de servicio con CVSS 7,5, corregida en la 1.1.0, y un fallo de lockdown con CVSS 6,0, corregido en la 1.1.2 (GitHub Security Advisories).
De un vistazo: los controles que más importan
Respuesta rápida
¿Cómo proteges GitHub MCP en producción?
Empieza con un token fine-grained o con OAuth por usuario, limitado a los repositorios que el agente necesita. Activa solo los toolsets que usa, aplica solo lectura cuando no haga falta escribir y excluye las tools de merge y borrado. Después inspecciona los resultados de las tools en busca de prompt injection indirecta y enmascara secretos.
| Capa | Control | Qué reduce | Límite |
|---|---|---|---|
| Identidad | PAT fine-grained, OAuth por usuario o GitHub App | El alcance de un token robado o mal usado | Los PAT van ligados al usuario y no están pensados para automatización en producción |
| Superficie de tools | Toolsets, tools individuales y tools excluidas | Las rutas de escritura que el modelo puede invocar | No inspecciona contenido |
| Escritura | Modo de solo lectura | Todas las tools de escritura, aunque se pidan | Limita lo que el agente puede hacer por ti |
| Contenido no confiable | Lockdown mode | Contenido público de usuarios sin permiso de push | Filtro best-effort, no autorización |
| Parches | Versión 1.1.2 o posterior | 2 advisories conocidos de 2026 | Solo corrige fallos conocidos |
| Runtime | Políticas y detectores en el gateway | Injection en resultados de tools y fugas de secretos | Solo cubre el tráfico que pasa por un gateway |
Qué puede alcanzar el servidor GitHub MCP
El servidor GitHub MCP alcanza todo lo que alcanza su credencial. La guía de gobernanza de GitHub dice que usuarios y apps no pueden usarlo para acceder a más de lo que podrían por la API. Ese techo suele ser alto: un token classic con el scope repo da acceso completo a repositorios públicos y privados, incluida la escritura de código.
GitHub distribuye el servidor de dos formas. El servidor remoto funciona en https://api.githubcopilot.com/mcp/ y lo aloja GitHub. El servidor local se ejecuta desde la imagen Docker ghcr.io/github/github-mcp-server o desde un binario en tu máquina.
En local, el README documenta un login OAuth en el navegador, aunque GITHUB_PERSONAL_ACCESS_TOKEN tiene prioridad si lo defines. El remoto admite OAuth, PAT y tokens de instalación de GitHub App.
El README enumera 22 toolsets y 92 tools para el servidor local, además de toolsets exclusivos del remoto como copilot_spaces. Sin configuración, recibes los toolsets por defecto: context, issues, pull_requests, repos y users. Ese paquete por defecto ya incluye tools que escriben código y hacen merge de pull requests.
| Toolset | Tools de ejemplo | Por qué importa para la seguridad |
|---|---|---|
repos (por defecto) | get_file_contents, push_files, create_or_update_file, delete_file, delete_repository | Lee código privado y puede cambiarlo o borrarlo |
pull_requests (por defecto) | create_pull_request, merge_pull_request, update_pull_request_branch | Un pull request público es un canal de exfiltración sencillo |
issues (por defecto) | issue_read, issue_write, add_issue_comment | El texto de desconocidos entra en el contexto del modelo |
actions | actions_run_trigger, get_job_logs | Lanza workflows y lee la salida de los builds |
secret_protection, code_security, dependabot | list_secret_scanning_alerts, list_code_scanning_alerts, list_dependabot_alerts | Revela dónde hay secretos y debilidades |
Si una escritura cambia un archivo de workflow, pide el scope workflow además de repo, así que ese agente puede editar tu CI. Además, el filtrado de tools por scope solo funciona con PAT classic; con fine-grained, la API de GitHub aplica los permisos.
)
Riesgos de GitHub MCP: cómo un issue público llegó a repos privados
El ataque mejor documentado contra GitHub MCP es un toxic agent flow, no un bug del servidor. Simon Willison (2025) señala que el servidor reúne la trifecta letal: acceso a datos privados, exposición a instrucciones maliciosas y capacidad de exfiltrar información. Bastó un issue malicioso en un repositorio público para iniciar la cadena.
La prueba de concepto, atribuida a los investigadores Marco Milanta y Luca Beurer-Kellner, funcionaba en cuatro pasos:
- Un atacante abrió un issue en un repositorio público de la víctima.
- El issue pedía al agente añadir datos del autor al README y listar "all other repos the user is working on".
- La víctima pidió al agente que revisara los issues abiertos, lo que metió el texto del atacante en el contexto.
- El agente leyó repositorios privados con el token de la víctima y abrió un pull request público que exponía sus nombres.
No se robó ninguna credencial ni se explotó código: el agente usó tools y permisos legítimos en el orden equivocado.
En el issue #844 de GitHub, abierto en agosto de 2025, un usuario reprodujo el flujo con OAuth y con personal access tokens.
GitHub (2026) afirma sus mitigaciones en la respuesta de un maintainer: lockdown mode, solo lectura, OAuth 2.1, tokens fine-grained estrictos y secret scanning en cada tools/call a repos públicos.
| Riesgo | Cómo aparece en GitHub | Primer control |
|---|---|---|
| Prompt injection indirecta | Instrucciones ocultas en issues, comentarios de pull requests o mensajes de commit | Lockdown mode más un detector de resultados de tools |
| Credenciales con demasiado alcance | Token classic con repo o admin:org sobre todos los repositorios | PAT fine-grained u OAuth por usuario |
| Exfiltración mediante escrituras | El agente abre un pull request, issue o comentario público con datos privados | Excluir o limitar las tools de escritura |
| Acciones destructivas | merge_pull_request, delete_file o delete_repository invocadas por error | Modo de solo lectura o tools excluidas |
| Exposición de secretos | Tokens o claves dentro de archivos, logs o salidas de tools | Secret scanning y data loss prevention |
Paso 1: elige la credencial más acotada
Según GitHub Docs (2026), debes usar personal access tokens fine-grained en lugar de tokens classic siempre que puedas. Los tokens fine-grained pertenecen a un único propietario, se pueden limitar a repositorios concretos y usan permisos granulares en lugar de scopes amplios.
La guía de gobernanza avisa de que los PAT van ligados al usuario, no siguen las políticas de OAuth App y no se recomiendan para automatización en producción. Para equipos, OAuth por usuario o una GitHub App dan más control.
| Credencial | Encaje ideal | Ventajas | Inconvenientes |
|---|---|---|---|
| PAT fine-grained | Un desarrollador, servidor local | Un propietario, repositorios elegidos, permisos granulares, aprobación opcional de la organización | Ligado al usuario; el servidor muestra todas las tools y confía en que la API rechace las llamadas |
| OAuth (remoto) | Equipos con hosts que tienen una app registrada | Scope challenges bajo demanda, políticas de OAuth App, SSO | Cada host necesita su propia app registrada |
| Instalación de GitHub App | Automatización a nivel de organización | Los administradores eligen repositorios y permisos; instalación a nivel enterprise | Más configuración; el SSO no se aplica a los tokens de instalación |
El scope que concedes decide el daño. Según la referencia de GitHub, repo da acceso completo a repositorios públicos y privados. En cambio, public_repo se limita a repositorios públicos.
Según Model Context Protocol (2025), un mal diseño de scopes agrava el impacto de un token comprometido. Recomienda empezar con scopes mínimos, pedir más solo cuando haga falta y evitar comodines. También prohíbe el token passthrough, es decir, reenviar tokens no emitidos para el servidor.
Aplica estas reglas antes de conectar cualquier agente:
- Crea un token por agente y entorno, nunca un token para todo.
- Limita los tokens fine-grained a los repositorios del agente y concede solo lectura salvo que la escritura sea imprescindible.
- Define una caducidad y rota los tokens con un calendario, como recomienda el README.
- En organizaciones, exige aprobación para los tokens fine-grained y desactiva los classic si puedes.
Paso 2: reduce la superficie de tools con los controles nativos
Los controles nativos deciden qué tools existen en la sesión y se pueden combinar. El modo de solo lectura gana a cualquier otro ajuste. Las tools excluidas ganan a los toolsets y a las tools individuales.
| Control | Servidor remoto | Servidor local | Qué hace |
|---|---|---|---|
| Toolsets | Cabecera X-MCP-Toolsets o URL /x/{toolset} | --toolsets o GITHUB_TOOLSETS | Carga solo los grupos indicados |
| Tools individuales | Cabecera X-MCP-Tools | --tools o GITHUB_TOOLS | Carga solo las tools indicadas |
| Tools excluidas | Cabecera X-MCP-Exclude-Tools | --exclude-tools o GITHUB_EXCLUDE_TOOLS | Elimina tools en todos los casos |
| Solo lectura | Cabecera X-MCP-Readonly o URL /readonly | --read-only o GITHUB_READ_ONLY | Desactiva todas las tools de escritura |
| Lockdown | Cabecera X-MCP-Lockdown | --lockdown-mode o GITHUB_LOCKDOWN_MODE | Oculta contenido público de usuarios sin permiso de push |
Dos recetas para el servidor remoto. La primera, para un agente de triaje que solo lee:
La segunda, para un agente de código que abre pull requests sin merge ni borrado:
Menos tools también ayudan al modelo. Según GitHub (2025), cargar de 3 a 10 tools redujo el uso de contexto entre un 60% y un 90% frente a los toolsets por defecto.
El lockdown mode solo muestra contenido de repositorios públicos creado por usuarios con permiso de push, y no afecta a los repositorios privados. GitHub lo describe como un filtro best-effort. No restringe lo que la credencial puede leer o escribir, y el contenido retenido puede seguir accesible mediante otras tools.
El contenido de github-actions[bot] y copilot siempre se trata como seguro, así que el texto externo copiado en un comentario de bot pasará el filtro. En modo HTTP, el lockdown del servidor es un límite que ninguna cabecera puede relajar.
Paso 3: parchea, monitoriza y prueba
Según GitHub Security Advisories (2026), este año se corrigieron dos fallos, y ambos importan sobre todo si alojas el servidor en modo HTTP. A 23 de octubre de 2026 la última versión era la v2.0.3, así que usa al menos la 1.1.2.
| Advisory | Gravedad | Versiones afectadas | Corregido en | Impacto |
|---|---|---|---|---|
| CVE-2026-47427 (GHSA-w4q6-qw23-4rg7) | Alta, CVSS 7,5 | Anteriores a la 1.1.0 | 1.1.0 | Una petición completion/complete malformada tumba el servidor antes de cualquier autenticación |
| CVE-2026-48529 (GHSA-pjp5-fpmr-3349) | Media, CVSS 6,0 | De la 0.22.0 a anteriores a la 1.1.2 | 1.1.2 | En modo HTTP con lockdown, las comprobaciones de acceso usaban las credenciales del primer usuario para todos |
La monitorización es el punto débil. Según la guía de gobernanza, el tráfico MCP aparece en el audit log como llamadas normales a la API. Aún faltan tres vistas: conexiones MCP activas en tiempo real, dashboards por tool o host y logs acción por acción.
Después prueba los controles con un canario inofensivo antes de confiar en ellos:
- Crea un repositorio público y otro privado de prueba con contenido ficticio.
- Abre un issue en el público que pida al agente añadir la palabra "canary-7731" en un comentario nuevo y listar tus otros repositorios.
- Apunta tu agente a los issues con tu configuración de producción.
- Comprueba que no aparece ningún comentario, pull request ni cambio de archivo, y que el detector de runtime que uses marca el texto del issue.
Cómo lo comparamos
Leímos el README, las guías de configuración y gobernanza, el changelog de diciembre de 2025, los advisories y la guía de seguridad de MCP. El incidente procede de Simon Willison y del issue #844. Los pasos de consola salen de pantallas de TrustGate y TrustGuard.
Seguridad y gobernanza: controles en runtime con NeuralTrust
Los controles nativos deciden qué tools existen, pero no leen lo que pasa por ellas. Ahí ayuda un gateway. Te recomendamos el Agent Gateway (TrustGate), cuyo Registry muestra una pestaña MCP con 203 entradas. Añade Agent Runtime Security (TrustGuard) para los detectores descritos abajo.
Registra GitHub en el Registry de TrustGate
- Ve a Registry > MCP > GitHub y pulsa Configure. Se abre el panel "New GitHub instance", descrito como "Repos, issues, pull requests, and workflows on GitHub."
- Rellena Instance name, que es obligatorio. La pista dice "e.g. GitHub – Production".
- En Authentication, elige User account, Shared account o API Key y completa los campos de esa opción.
El recuadro de ayuda se titula "Register TrustGate as an OAuth app in GitHub". Su primera línea dice "GitHub personal access token (PAT), sent as a Bearer token". La segunda dice "Add TrustGate's OAuth callback URL, then enter the client ID".
User account
La pantalla indica que este proveedor "requires a pre-registered OAuth app" y que "users still log in at runtime". Registra una OAuth app en GitHub y añade la callback URL de OAuth de TrustGate. Después introduce su Client ID y, si aplica, el Client secret, marcado como opcional. Pulsa Done.
Shared account
La pantalla dice "One OAuth identity is used by everyone granted this instance". Los campos son los mismos: Client ID y Client secret (Optional). El botón dice Create and connect. Da a esa identidad de GitHub solo los repositorios y permisos que necesita el grupo.
API Key
La pantalla dice "A key stored on the gateway is used for every call to this instance". El único campo se titula "GitHub personal access token (PAT), sent as a Bearer token". La nota bajo el campo dice "Paste the value. Stored encrypted on the gateway". Pulsa Done. GitHub Docs recomienda tokens fine-grained limitados a repositorios concretos, así que crea uno para esta instancia con mínimo privilegio y fecha de caducidad.
¿Qué opción de autenticación deberías elegir?
| Opción | Qué identidad llama a GitHub | Qué introduces | Encaja si necesitas |
|---|---|---|---|
| User account | Each user logs in at runtime (cada usuario inicia sesión en runtime) | Client ID de una OAuth app registrada previamente, Client secret (Optional) | Permisos por usuario y trazabilidad de cada cambio |
| Shared account | One OAuth identity used by everyone granted this instance (una identidad OAuth para todos los que tienen acceso) | Client ID, Client secret (Optional) | Una sola identidad de GitHub para un equipo pequeño en los mismos repositorios |
| API Key | A key stored on the gateway, used for every call (una clave guardada en el gateway, usada en cada llamada) | GitHub personal access token (PAT) | Automatizaciones o agentes de servicio sin nadie que inicie sesión |
Si te importa la responsabilidad individual, valora User account. Con Shared account o API Key, acota al máximo la identidad compartida o el PAT y rótalos con regularidad. La guía de gobernanza de GitHub tampoco recomienda los PAT para automatización en producción, así que trata API Key como una credencial de servicio muy acotada.
Añade políticas que se aplican al tráfico MCP
Abre Policies > Library en tu gateway; cada tarjeta tiene un botón Add policy. Cuatro tarjetas llevan las etiquetas LLM y MCP: TrustGuard, Per-Tool Rate Limiter, Rate Limiter y Request Size Limiter. Otras, como LLM Budget, solo llevan la etiqueta LLM.
| Política | Qué dice la tarjeta | Dónde podrías usarla |
|---|---|---|
| TrustGuard | Inspecciona petición o respuesta, bloquea lo marcado, aplica data masking y tiene failure_mode | Contenido de issues, comentarios y archivos en las respuestas |
| Per-Tool Rate Limiter | Limita cada ejecución de una tool en tráfico LLM y MCP, con ventanas fijas | create_pull_request, push_files y add_issue_comment, las tools de exfiltración más probables |
| Rate Limiter | Ventana deslizante | Bucles descontrolados de llamadas a GitHub |
| Request Size Limiter | Limita el tamaño de las peticiones | Payloads enormes, como subidas masivas de archivos |
La tarjeta de TrustGuard muestra un ajuste failure_mode; revísalo antes de dar permisos de escritura.
Añade detectores en TrustGuard
Abre Detectors > Catalog en TrustGuard y usa Add detector en dos entradas. La tarjeta de Indirect Prompt Injection dice que puntúa los resultados de tools, incluidos los de MCP, además de las descripciones y los esquemas de parámetros de tools/list. Un issue malicioso llega al agente como resultado de una tool. La tarjeta de Data Loss Prevention dice que enmascara PII en tránsito y reporta secretos como API keys, access tokens y JWT.
La tarjeta de Prompt Guard dice que no puntúa los system prompts, las definiciones de tools ni los argumentos de las llamadas a tools MCP. En GitHub MCP, la injection vive en los resultados de las tools, así que Indirect Prompt Injection es la tarjeta que encaja con este riesgo.
La página de precios muestra un plan Free con TrustGate, TrustGuard y 100.000 peticiones al mes.
¿Cuál deberías elegir?
| Tu situación | Credencial | Configuración nativa | Capa de runtime |
|---|---|---|---|
| Desarrollador que prueba en local | PAT fine-grained sobre pocos repositorios | Toolsets por defecto más solo lectura | Opcional |
| Agente de triaje en repositorios públicos | OAuth por usuario | issues,pull_requests en solo lectura con lockdown | Detector de Indirect Prompt Injection |
| Agente de código que abre pull requests | User account ("users still log in at runtime") | repos,pull_requests, sin merge ni borrado | Detector, DLP y Per-Tool Rate Limiter |
| Bot de automatización para toda la organización | Instalación de GitHub App | Solo tools nombradas con X-MCP-Tools | Política TrustGuard más rate limits |
| Servidor HTTP autoalojado | Tokens por usuario | Lockdown en el servidor, versión 1.1.2 o posterior | Request Size Limiter y Rate Limiter |
Conclusión
Proteger GitHub MCP consiste sobre todo en reducir lo que un solo prompt puede alcanzar. Empieza con una credencial fine-grained o por usuario, carga solo los toolsets que necesita cada agente y usa el modo de solo lectura, las exclusiones y el lockdown donde encajen. Después trata cada issue, comentario y archivo como entrada no confiable, porque los filtros nativos son best-effort. Actualiza a la 1.1.2 o posterior, prueba con un canario inofensivo y añade detección de injection y secretos antes de dar permisos de escritura en producción.
Asegura GitHub MCP en producción con NeuralTrust
Enruta GitHub MCP por un único gateway con Per-Tool Rate Limiter y los detectores Indirect Prompt Injection y Data Loss Prevention, empezando por el plan Free.
)
Lecturas relacionadas
- Seguridad para MCPs 101
- Tu servidor MCP es un vector de injection
- 6 Best MCP Gateways for Enterprise (2026)
- Registros MCP para empresas en UK
Preguntas frecuentes sobre GitHub MCP
1. ¿Es seguro usar el servidor GitHub MCP?
Es tan seguro como la credencial y las tools que le des. El servidor aplica los permisos de GitHub, sanitiza el contenido por defecto y corrigió dos advisories de 2026 en la 1.1.0 y la 1.1.2. El riesgo principal es la prompt injection en issues y comentarios. Tokens acotados, menos tools y detección en runtime reducen ese riesgo.
2. ¿Tiene GitHub MCP un modo de solo lectura?
Sí. Define la cabecera X-MCP-Readonly o usa la URL /readonly en el servidor remoto, o pasa --read-only en local. Desactiva todas las tools de escritura, incluso las que pidas de forma explícita, y gana a cualquier otro ajuste. Es ideal para agentes de triaje, aunque el agente sigue leyendo los datos privados que su token permita.
3. ¿Qué permisos necesita un token de GitHub MCP?
Solo los que exigen las tareas del agente. GitHub recomienda tokens fine-grained limitados a repositorios concretos y con permisos granulares. Para tokens classic, el README cita repo, read:packages y read:org como scopes habituales, pero repo da acceso completo a todos los repositorios privados. Empieza con lectura y añade escritura solo cuando haga falta.
4. ¿Qué es el lockdown mode del servidor GitHub MCP?
El lockdown mode oculta el contenido de repositorios públicos creado por usuarios sin permiso de push y reduce la injection de desconocidos. No afecta a los repositorios privados. GitHub lo define como un filtro de contenido best-effort, no como una frontera de autorización, y el contenido de github-actions[bot] y copilot siempre se permite. Actívalo con X-MCP-Lockdown o --lockdown-mode.
5. ¿Puede GitHub MCP filtrar repositorios privados?
Sí, si una sesión tiene un token con acceso a repositorios privados y además lee contenido público no confiable. En 2025, un issue público llevó a un agente a exponer nombres de repositorios privados en un pull request público. Tokens separados, solo lectura para el triaje, tools de escritura excluidas y un detector de injection indirecta reducen esa vía.
6. ¿Debo usar el servidor GitHub MCP remoto o el local?
Usa el remoto si trabajas en github.com o GitHub Enterprise Cloud y quieres que GitHub lo opere. Usa el local para GitHub Enterprise Server o cuando necesites control total del runtime y de su ruta de red. Si lo alojas tú en modo HTTP, usa la versión 1.1.2 o posterior y activa el lockdown en el lado del servidor.
7. ¿Qué tools de GitHub MCP debo desactivar primero?
Empieza por las tools con efectos irreversibles o públicos. Buenas candidatas son merge_pull_request, delete_file, delete_repository y push_files, y después actions_run_trigger si tus agentes no lanzan workflows. Usa X-MCP-Exclude-Tools o --exclude-tools, porque las exclusiones ganan a cualquier toolset que actives. Revisa la lista con cada toolset nuevo.
8. ¿Registra GitHub lo que hacen los agentes MCP?
En parte. Las llamadas a la API aparecen en el audit log de GitHub, pero como tráfico normal. GitHub indica que aún no hay una lista en tiempo real de conexiones MCP, ni dashboards por tool, ni logs MCP acción por acción. Para tener visibilidad y límites por tool hoy, enruta el tráfico por un gateway que vea cada llamada.
9. ¿Uso User account, Shared account o API Key para GitHub MCP?
Valora User account si necesitas que cada persona actúe con su propia identidad de GitHub; la pantalla dice "users still log in at runtime". Valora Shared account si tu equipo puede trabajar como "one OAuth identity". Valora API Key para automatizaciones; la pantalla dice que una clave guardada en el gateway se usa en cada llamada. Acota al mínimo esa identidad o PAT.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
- GitHub, GitHub MCP Server (README), consultado el 23 de octubre de 2026.
- GitHub, Server Configuration Guide, consultado el 23 de octubre de 2026.
- GitHub, Policies and Governance for the GitHub MCP Server, consultado el 23 de octubre de 2026.
- GitHub Changelog, The GitHub MCP Server adds support for tool-specific configuration, and more, 10 de diciembre de 2025.
- Simon Willison, GitHub MCP Exploited: Accessing private repositories via MCP, 26 de mayo de 2025.
- GitHub, Issue #844: Exfiltrate information from private repositories, abierto el 8 de agosto de 2025; respuesta del maintainer el 20 de abril de 2026.
- GitHub, Security advisories de github-mcp-server (GHSA-w4q6-qw23-4rg7, 20 de julio de 2026; GHSA-pjp5-fpmr-3349, junio de 2026), consultado el 23 de octubre de 2026.
- GitHub Docs, Managing your personal access tokens, consultado el 23 de octubre de 2026.
- GitHub Docs, Scopes for OAuth apps, consultado el 23 de octubre de 2026.
- Model Context Protocol, Security Best Practices (especificación 2025-11-25), 25 de noviembre de 2025.