Shrink a coding agent's credential blast radius with secret proxies
NCSC guidance and Copilot's sandbox proxy point the same way: agents should not hold real secrets. How credential proxies work, their limits, and a checklist.
A coding agent can do whatever its credentials allow, which is often far more than its task needs. A developer's laptop typically holds a Git credential with push rights to every repository they can reach, a GitHub CLI session, cloud command-line logins and a few API keys in environment variables. An agent running as that developer, without isolation, can use all of them. The UK's National Cyber Security Centre calls this the agent's blast radius, and recent tooling shows a practical way to shrink it: give the agent a placeholder, and let a proxy it cannot read supply the real secret only where it is meant to go.
The context: what the guidance says
The NCSC's interim guidance on agentic AI, published on 20 August 2026, has a section on credentials. It recommends that every agent has its own identity, distinct from human users, and says the credentials an agent can reach "form part of its potential 'blast radius' if it behaves unexpectedly". It counts API keys, OAuth grants, SSH keys and any authenticated sessions among them, and warns that an agent with no compute isolation may use whatever credentials the user account it runs under can reach. Its advice is to restrict credentials to what the task needs, to use the shortest possible lifetime, and, for some uses, to put a proxy in front that injects credentials into requests so the agent never sees them and cannot use them against an unexpected endpoint.
GitHub's local sandboxing documentation for Copilot, which became generally available on 7 October 2026, describes that pattern in a shipping product:
- Sandboxed commands and scripts receive placeholder Git and
ghcredentials. A local proxy swaps in the real credentials only for approved HTTPS destinations. - Git credentials keep their host, port and repository path restrictions;
ghcredentials are used only for github.com, api.github.com and uploads.github.com. - Other environment variables, such as API tokens, can be masked the same way. Commands, local MCP servers and language servers in the sandbox see placeholders, and the proxy supplies each real value only to the hosts configured for it.
- The real value is only substituted in an HTTPS request header, such as
Authorization, or as the password in HTTP Basic authentication. Plaintext HTTP, request bodies, URLs and signed requests do not receive it.
Analysis: what to make of it
A proxy changes what a leak looks like
If an agent is tricked by prompt injection into printing its environment or posting a token to an attacker's server, a placeholder is worthless to the attacker. The real secret only leaves the machine inside a request to a host the administrator chose. That turns credential theft into, at worst, misuse of the credential against its intended service, which is a much smaller problem and one that service's own logs can show.
The limits are stated, and they matter
GitHub's documentation is direct about what masking does not cover. It protects only the configured environment variables and the enabled Git and gh authentication, and "does not hide secrets in credential files, other environment variables, or remote MCP authentication." It also notes that an approved command bypass skips both masking and the proxy, so the command runs with its ordinary environment, real secrets included. Bypass requests are on by default and can be turned off. A credential proxy is only as strong as the list of secrets it knows about and the discipline around bypasses.
Credentials must be bound to where they belong
A proxy decides which host receives a secret. Clients that fetch tokens themselves need the same discipline, and a recent advisory shows what happens without it. GHSA-6qxp-vccf-f47h, published on 30 September 2026 and rated high (CVSS 7.5), describes how the official MCP TypeScript SDK's OAuth client let the MCP server decide which authorisation server received the client's OAuth credentials. A malicious or compromised server could name its own authorisation server and, with no user interaction, receive stored refresh tokens and client secrets. The affected releases are @modelcontextprotocol/sdk 1.12.0 to 1.30.1, fixed in 1.31.0, and @modelcontextprotocol/client 2.0.0 to 2.1.0 in specific configurations, fixed in 2.2.0. The advisory itself is covered in MCP TypeScript SDK OAuth flaw: credentials followed the wrong issuer. The general lesson matches the proxy model: a credential should be tied to the one place it is meant for, and code acting on an untrusted party's instructions should not decide where it goes.
Shorter-lived credentials help too
The NCSC's advice on lifetimes is getting easier to follow. GitHub's least-privilege update of 13 October adds narrower repository permissions and lets GitHub Apps use the offline_access scope to move users gradually to expiring access tokens, for apps that had turned expiration off. The same post describes a new Credentials tab that leaves room for workload federation features GitHub describes as planned, not yet available.
What it means for engineering and security leaders
Treat the credentials on a developer machine as part of every agent's permissions, because without isolation they are. Three questions are worth answering for each AI tool in use:
- Which secrets can the agent reach directly, through environment variables, files and signed-in sessions?
- Which of those does it actually need for its tasks, and could a placeholder and proxy stand in for them?
- Where can a credential go if the agent, or a server it talks to, asks for it to be sent somewhere new?
Give agents their own identities where the platform allows it, so their actions are separable from the developer's in logs. Prefer short-lived, narrowly scoped tokens for agent work. And make bypasses visible: a sandbox that people routinely bypass offers little protection.
For the wider isolation picture, see the NCSC's sandbox maturity levels, what Copilot local sandboxing restricts and sandboxing coding agents.
Practical takeaways for this week
- Inventory the credentials on a typical developer machine that an agent could reach: environment variables, credential files, CLI sessions and cloud logins.
- Where Copilot local sandboxing is in use, add masked variables for API tokens agents use, with only the hosts that need them.
- Decide whether to allow sandbox bypass requests, and if so, how they are reviewed.
- Update MCP TypeScript SDK clients to 1.31.0 or 2.2.0, pass
expectedIssuerto bundled providers as the advisory describes, add an issuer to or clear credentials saved before the upgrade, and rotate credentials that may have been exposed to untrusted servers. - Move agent-used tokens to the shortest lifetime the service supports.
Where SpanDock fits
For MCP connectors, the SpanDock MCP gateway, on the Premium and Enterprise plans and in the 30-day trial, takes a similar line: connector tokens and sign-ins are kept in the server's credential store, never shown again, never logged and never sent to computers, so the AI tools on a laptop never hold them. Every connector starts read-only, and every call is recorded. The privacy page describes how each client sees only its own data.