AI coding assistants and leaked secrets: the risks and the controls

AI coding assistants and agents now read whole repositories, run shell commands, open pull requests and connect to other systems through plugins and MCP servers. That's what makes them useful, and it's also a new path for secrets and customer data to leave the company. None of this means teams should stop using them. It means treating them like any other powerful tool with access to code and credentials.

How secrets leak through AI tools

• Context sent to the model: when an assistant reads a file to answer a question, the file's contents, including any keys in a .env file or a config, can be sent to the model provider.
• Pasted data: people paste stack traces, database rows, customer records and connection strings into chat to get help.
• Command output: an agent that runs commands such as printenv, cat on a config file or a cloud CLI can put secrets into the conversation.
• Generated code: assistants sometimes write example keys into code, or copy real ones from context into new files that get committed.
• Plugins and MCP servers: each connected tool is another system the agent can read from and send data to, often with broad tokens.

Why it matters

A secret sent to a third party is a secret that has left your control, whatever that provider's retention policy says. Customer data sent the same way can be a reportable event under privacy laws, and an auditor will ask how you know what was sent. Most security teams today can't answer that question for AI tools.

Controls that work

Keep secrets out of reach

• Don't keep long-lived secrets in files in the repository. Use a secrets manager and short-lived credentials, so a leaked value expires.
• Configure assistants to ignore secret files (.env, credential files, private keys) where the tool supports it.
• Give agents their own least-privilege credentials, never a developer's admin token.

Inspect what leaves

• Put a gateway or local proxy in front of AI services that detects and masks keys, passwords and personal data before they leave, and restores them in the reply where needed.
• Log what was sent, so you can answer an auditor or investigate an incident.
• Block commands that print the environment or read credential files in agent sessions.

Know which agents you have

• Keep an inventory of AI agents with access to repositories: CI agents, assistant integrations, MCP servers and organisation-level AI apps.
• Review the scopes each one has, and remove the ones nobody uses.
• Treat new MCP servers like new third-party integrations: approve them before use.

Catch leaks that happen anyway

• Turn on secret scanning and push protection on your code host.
• Scan AI-generated pull requests like any other code.
• Have a leaked-secret runbook: deactivate, investigate, rotate, clean up.

A sensible policy for teams

1. Approve specific AI tools and plans with appropriate data terms, rather than banning everything and driving people to personal accounts.
2. Say clearly what may never be pasted: customer personal data, credentials, and anything under a confidentiality agreement.
3. Protect the path automatically, with masking and logging, rather than relying on people remembering.
4. Inventory agents and their access every quarter.
5. Include AI tools in incident response: know how to find what an agent sent and to whom.

A worked example

A developer asks an AI agent to fix a failing integration test. To understand the failure, the agent reads the test, the application config, and the .env file next to it, which holds a staging database password and a payment provider's API key. It runs the test, which prints a connection string in the error. All of this goes to the model provider as context, and the agent's fix copies the connection string into a new test fixture that's committed. Nothing malicious happened, yet two secrets have left the company and one is now in git history. Excluding .env files from the agent's context, masking secrets in what's sent, and secret scanning on push would each have stopped part of this.

Common mistakes

• Assuming the provider's data terms make leaks harmless. Secrets still leave your control and must be rotated.
• Giving an agent a developer's personal access token with full repository and organisation scope.
• Approving MCP servers from unknown publishers without reviewing what they can read and where they send data.
• Banning AI tools officially while people use personal accounts unofficially, with no controls at all.
• Having no way to answer "what did the agent send last Tuesday?" during an incident.

How to verify

Run a controlled test: put a fake but realistic secret, such as a canary token, in a file an assistant can read, and see whether it appears in what's sent, in logs, or in code the agent writes. Check that masking catches it, that the log records it, and that secret scanning blocks the push. Repeat the test whenever you add a new AI tool or MCP server.

What auditors and customers will ask

Security questionnaires from enterprise customers and auditors increasingly include questions about AI. Expect to be asked which AI tools staff and agents use, what data they're allowed to send, how you stop personal data and secrets reaching them, which agents can access code repositories and with what permissions, and how you'd investigate an incident involving an AI tool. Under India's DPDP Act and the EU's GDPR, sending customers' personal data to a new processor without a basis and without telling people can be a compliance problem in itself, regardless of whether anything is misused. Having an approved-tools list, automatic masking, a log of what was sent and an inventory of agents turns these questions from awkward into routine.

Checklist

• Approved AI tools and data terms documented.
• No long-lived secrets in repository files.
• Secret files excluded from assistant context where supported.
• Masking of secrets and personal data before requests leave.
• A record of what was sent, for audits and investigations.
• An inventory of AI agents, MCP servers and their scopes.
• Secret scanning and push protection enabled.
• A tested leaked-secret runbook.