AI coding agents prove useful in a number of ways, among them: they read everything. Your source files, configs, environment variables, and even the errors in your terminal, are all fodder for agentic action. An agent consumes this information to better understand the task at hand, then transmits the relevant portions to a model to inform its response. That long reach is central to the value that these agents provide, but also raises a problem, because everything might include your secrets.
As a blunt example, earlier this month, a security researcher captured xAI's Grok Build coding agent quietly uploading developers' entire Git repositories to a cloud storage bucket. A canary API key and database password placed in a .env file showed up verbatim and unredacted in the transmitted traffic (Cybernews, The Next Web). But oftentimes it doesn’t take a dramatic bug to expose a secret; in reality, most leaks are far less conspicuous.
How a secret reaches the model
Secrets can reach a model in a number of ways, but we’ll focus on the two worst offenders. Sometimes you hand over a secret yourself, pasting, for example, a failing API call into the chat (key and all) to ask why it keeps returning a 401. That path is at least visible. The other is quieter than a breach: to build context, the agent reads the files sitting in your project, and that often includes a .env:
# .env — sitting in your project root, read as "context"
DATABASE_URL=postgres://app:S3cr3t-Pa55@db.internal:5432/prod
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
OPENAI_API_KEY=sk-proj-3f9a...redactedHere, nothing malicious has happened. The agent did its job, but those values are now part of the prompt it sent to a model provider and, as a result, that prompt can get stored: in the provider's logs, and often in the logs of whatever gateway sits between you and the model (frequently in plain text). In this case, nobody typed the key into a chat box; it rode along with the context.
While the first example can be attributed to human oversight, the second is more subtle (and insidious) because it results from the default behavior of a helpful tool doing exactly what you asked of it.
Why secrets are now harder to contain
A secret committed to Git at least sits in one or more places that you can locate and scrub. Once it has traveled through an agent, however, it's scattered across systems you don't own. Rotating a key, for example, closes the door moving forward, but does nothing to address the months of prompt history already sitting in provider and gateway logs, and you can't simply grep someone else's data retention.
Attackers have noticed this and are taking action. Our team recently analyzed a series of Shai-Hulud attacks, including Mini Shai-Hulud, the first in-the-wild supply chain attack built to persist through AI coding agent sessions. It hunts for more than 80 environment variables and more than 130 file paths, including ~/.aws/credentials, ~/.ssh/, and ~/.npmrc, plus database strings and wallet files. For bad actors, the agent's context window has become a target worth attacking.
And even for secrets you can actually find and fix, remediation is a different matter altogether. The clock can be unforgiving as the median time to remediate one leaked secret in a public repository is 94 days, according to the Verizon 2025 Data Breach Investigations Report. Three months is more than enough time for an automated scanner, for example, to locate and abuse a leaked secret.
Catch secrets before they leave the prompt
As the modern software development lifecycle becomes increasingly reliant on agentic workflows, it’s now imperative that secrets are detected at the earliest possible point, before they can travel onward: as you type, before you commit, before the agent ships your context to a model, and again when a PR is opened. Detection must live where the secret is still local and still yours.
One principle stands above the rest here: catching a secret shouldn't depend on the model that's about to transmit it. Detection instead needs to run in a dedicated scanner, separate from the agent, that matches the prompt and files against known secret patterns and returns a plain block-or-allow. A secret is stopped by a rule, not by the model's judgment.
Where SonarQube stands at every door
Secrets detection from SonarQube sits at each point that a secret could potentially slip out, running the same detection engine everywhere: covering 450+ secret patterns across 248 cloud services, with a false-positive rate under 5%.
- SonarQube for IDE flags a secret the moment you write it, before it ever leaves your machine.
- The SonarQube CLI and SonarQube agent plugins push secrets detection into the agent loop itself, scanning locally at roughly 100 ms per file so your flow isn't interrupted. What gets covered depends on the agent: the prompt you submit, the files the agent reads, or both. When a secret is caught before that prompt or file read goes through, it's blocked on your machine and never reaches the model. The plugins cover Claude Code, GitHub Copilot CLI, Codex, Cursor, Antigravity, and more.
- SonarQube Cloud and SonarQube Server catch anything that reaches the repository, flagging secrets in PR analysis and allowing a quality gate to block the merge.
Next steps
Select the environment where your agents run and place a gate there. For terminal-driven workflows, install the SonarQube CLI with the plugin for your preferred agent so that prompts and file reads are scanned locally, then back it with a quality gate in SonarQube Cloud or Server so that nothing slips through at the PR level.
AI coding agents supercharge productivity, enabling developers to ship code faster than ever, but without zero-trust, multi-layered verification, your secrets are vulnerable to leakage. SonarQube provides verification at every step of the software development lifecycle, from prompting to PR. SonarQube secrets detection puts a door in front of your agents that your secrets can't pass through, so you ship fast without mailing credentials to systems you can't audit or control.