How to Prevent the GitHub MCP Server from Returning Secrets and API Keys to an AI Agent
Limit what the token and toolset can reach, then inspect every tool response before it enters the agent's context. Least-privilege tokens, restricted toolsets, read-only mode, secret scanning and push protection reduce exposure at the source, but none of them inspects what the server actually returns. Runtime enforcement on the tool response, with allow, redact or block, covers that gap and produces evidence of what was returned.
Enforce policy on the tool response
- 1
Intercept
Route each MCP tool call and its response through a policy decision point in the execution path.
- 2
Detect
Apply detection logic for credential patterns, API key formats and tokens to the response body.
- 3
Decide
Choose allow, redact or block based on policy, tool and repository.
- 4
Record
Write the decision, the tool call and the policy applied to durable evidence.
- 5
Test before enforcing
Measure false positives and false negatives on representative content, then tune rules before moving to enforcement.
Evidence to retain
- The tools, toolsets and token scopes available to the agent, with the date each configuration changed
- Each tool call: tool name, repository, arguments and time
- The enforcement decision on each response: allow, redact or block, and the policy version applied
- The category of secret detected, without storing the secret value itself
- Detection rule changes and test results for false positives and negatives
- MCP SDK versions in use and the outcome of vulnerability reviews
Apply preventive controls at the source
Scope the token to the task
Use the narrowest token the workflow needs, limited to the specific repositories and read operations required. Avoid reusing a token that also manages repository settings.
Restrict the toolsets
Expose only the tools the agent needs. An agent that triages issues does not need workflow files or commit diffs.
Use read-only mode where available
If the agent only reads, remove write capability so a manipulated agent cannot act on what it reads.
Enable secret scanning and push protection
These reduce new credentials entering repositories. They act on stored content, not on responses returned to an agent.
Keep secrets out of artefacts
Inject credentials dynamically at runtime rather than embedding them in code, configuration or workflow files, which reduces what any response can contain.
Where exposure occurs in the request and response path
An agent using the GitHub MCP server issues a tool call, the server reads from GitHub with the token it was configured with, and the result returns to the agent as a tool response. That response can be file contents, issue and pull request text, commit diffs or workflow definitions. If any of that content holds a hard-coded credential, the credential is now in the agent's context window.
From the context window, the value can be sent to the model provider, written into generated code or other output, passed as an argument to another tool, or surfaced through prompt injection in repository content. The exposure happens at the response, which is why the response is the practical control point.
By analogy with embedded secrets in container images, which NIST SP 800-190 notes can be read by anyone with access to the artefact, a secret in repository content is readable by any agent granted read access. That is an inference, but a sound one for threat modelling.
A related risk compounds this. NIST describes scenarios in which a GitHub-connected agent holds a high-privilege token and acts as a confused deputy, or interprets tool metadata as workflow guidance and performs unintended actions. Its stated prevention is not to trust instructions, metadata or artefacts from users or other agents. Prompt instructions alone are not a control.
Where source-side controls stop
These controls change what is stored and who can reach it. They do not inspect a response in transit, so three gaps remain.
First, controls that act when content is written do not remove content already in history. A credential committed before scanning was enabled can still be returned by a commit or file read. Second, secrets are not confined to source files. Issue text, pull request discussion and workflow data can also hold them, so check whether your scanning covers more than code. Third, a token with broader scope than the task widens the set of content that can be returned, and tool selection alone does not fix that.
Transport and SDK hygiene also matter for any MCP server you run. CVE-2026-116684 describes MCP Python SDK bearer authentication accepting a token issued for another service when the token verifier does not validate the audience claim. CVE-2025-66414 describes MCP TypeScript SDK versions before 1.24.0 lacking DNS rebinding protection by default for HTTP-based servers, which let a malicious website reach an unauthenticated local server. Stdio transport is not affected. Inventory your SDK versions, validate the audience claim, and prefer stdio or authenticated HTTP for local servers.
Runtime enforcement with Trussed
Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants. For a GitHub MCP deployment, that means policy is applied to individual tool calls and their responses, with actions of allow, redact, block, rate limit or escalate for human approval. Enforcement happens at runtime, not through review after the fact.
Each enforcement decision produces audit-ready evidence, mapped to frameworks including NIST. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, so evidence and the content it describes stay within your environment. It has run in continuous production in a regulated enterprise for more than 18 months.
Where a secret travels through a GitHub MCP call
Label: 1. Tool call
Description: The agent asks the GitHub MCP server to read a file, issue, pull request, commit or workflow.
Label: 2. Token-scoped read
Description: The server fetches content using the token it holds. The token defines the reachable data.
Label: 3. Tool response
Description: The response may include credentials embedded in code, diffs, text or workflow files.
Label: 4. Enforcement point
Description: Policy evaluates the response and applies allow, redact or block.
Label: 5. Agent context
Description: Only the permitted content reaches the model, generated output and downstream tools.
See how tool responses are enforced and evidenced
Review how policy applies to MCP tool calls and responses in your environment, and what evidence each decision produces.
Explore Agent and Tool-Call EnforcementHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.