What Is Secret Scanning?

Secret scanning is the practice of finding API keys, tokens, passwords and other credentials in code, config and history, before an attacker does. A scanner looks for known token formats, high-entropy strings and, increasingly, model-detected secrets, then alerts or blocks the push.

Secret scanning is not secrets management. Secrets management is how a team stores and issues credentials, for example in a vault. Scanning is how a team finds a secret that has already landed in the wrong place.

In 2026, coding agents made that wrong place more common: agent configs, example fixtures, logs and prompts, rather than only a committed .env file.

Secret scanning in 2026: agents write the config, so agents leak the keys

In January 2026, secret scanning was already mature for known token formats, and push protection was common on public repositories. The year’s shift was where the secrets appeared, and when the scan ran.

Agents write config files, test fixtures and tool settings. Some of those files, including MCP and agent configs, became a new place to leave a key. Git hosts moved scanning into the agent session itself, and later extended push protection to secrets found by a model, rather than only by a fixed pattern.

Our view: a scanner can tell you a string looks like a key; review tells you whether the code treats it like one.

2026 secret scanning highlights

• GitHub put secret scanning inside AI coding agents through its MCP server, in public preview (March 17, 2026, GitHub changelog).
• GitHub made MCP server secret scanning generally available (May 5, 2026, GitHub changelog).
• Microsoft described the ChainDrop supply chain worm, which harvested developer credentials and injected agent config files (August 4, 2026, Microsoft).
• GitHub launched a purpose-built model for leaked secret detection (October 7, 2026, GitHub changelog).
• GitHub extended push protection to AI-detected secrets in public preview, and said the change more than doubled the pushes caught. Agents needed authorization before bypassing (October 28, 2026, GitHub changelog).

What secret scanning needs next: the 2027 outlook

• Expect scanning to run inside the agent session before a file is saved, rather than only at push time.
• Expect agents to need explicit human authorization to bypass push protection, not a quiet skip.
• Expect review to check how secrets flow into logs, prompts and client code, rather than only whether a token string is present.
• Our verdict: secret scanning stops the leak you can pattern-match; review has to catch the leak you can only reason about.
• Qodo has Agentic PR Review whose Security findings include hardcoded secrets and other issues that could expose sensitive data, on the pull request.
• Qodo has an Agentic Toolbox that can run the same review engine on a local change, so a hardcoded secret can be caught before the pull request exists.

How secret scanning works

1. Pattern match known token formats. Many providers issue keys with a recognizable prefix or shape.
2. Detect generic high-entropy strings. Some secrets have no tidy prefix, so scanners also look for random-looking values.
3. Use a model for unstructured secrets. Some 2026 scanners add a model to catch leaks that a regex misses.
4. Optionally check validity with the provider. A live check can tell whether a found key still works. Not every tool does this.
5. Alert, or block the push. Push protection stops the secret at the Git host, before history is rewritten.
6. Revoke and rotate. A finding is not a fix. The team still has to revoke the credential and scrub what was exposed.

Where secret scanning runs

Secret scanning vs secrets management vs SAST

A secrets manager does not replace a scanner. A scanner does not replace a manager. Software composition analysis is a different check again: it is about packages, not about keys in your own files.

Secrets AI agents leak most often

• AI service keys in config or example files, because the agent was told to "just get it working."
• MCP and other agent config files, which may hold tokens for the tools the agent can call.
• Test fixtures and sample payloads that include a real key "temporarily."
• Secrets sent to logs, error reports or prompts, which a pattern scanner on the repo may never see.

What to do when a secret leaks

1. Revoke first. Treat the credential as compromised, even if the repo is private.
2. Rotate the replacement secret in the manager, not in a new committed file.
3. Scrub history if the secret was pushed, and check access logs for use of the old key.
4. Fix the path that put the secret in code, so the next agent run does not repeat it.

Costs and risks

False positives on test keys train people to ignore alerts. Bypass habits on push protection do the same. Scanning only the default branch misses secrets on feature branches and in agent worktrees.

Qodo’s take: review how the change handles secrets

Qodo is not a secret scanner. Qodo does not claim provider validity checks, git-history scanning or push protection.

Qodo is the best AI code review platform for this adjacent job because Qodo reviews how a change handles credentials, flags hardcoded secrets in Security findings, and can apply a team rule about secret handling once Rule enforcement (Beta) is on.

Qodo no longer offers test generation; it focuses on AI code review and code governance.

The shared outcome is agent code merged sooner, with fewer rollbacks.

Enterprise engineering teams get Security findings, and optional secret-handling rules, on every pull request, once Rule enforcement (Beta) is on, on GitHub, GitLab, Bitbucket Cloud and Azure DevOps. Gerrit is not covered by Rule enforcement.

High-velocity teams can also run the review in the agent session, so a hardcoded secret is visible before the push.

Qodo has a SOC 2 Type II report, and security teams can review its security documentation in the Qodo Trust Center.

What Qodo flags in a pull request

Qodo’s Security category covers vulnerabilities that could be exploited, with examples such as injection, hardcoded secrets and missing authorization checks. High severity covers blocking issues such as security violations and sensitive data exposure (docs checked November 10, 2026, Qodo).

Team rules about secret handling

Once Rule enforcement (Beta) is on, a team can write a rule such as "load credentials from the secret manager, never from files committed to the repo," and Qodo checks pull requests against it. The Git host’s scanner and push protection still do the pattern-match and block-the-push jobs.

Before the pull request

Qodo has an Agentic Toolbox whose Review skill runs the same review engine on local changes, so a hardcoded secret can be found while the agent is still writing.

Qodo example: the key was not in a .env file

Context: an organization like a product team whose agents were adding a new integration, and whose Git host already had secret scanning and push protection on known token formats.

Problem: an agent wrote a helper that logged a request header containing an API key, and also left a token in a sample fixture. The usual scanner patterns did not all fire, and the leak was a flow, rather than only a committed .env.

How Qodo helped: Qodo’s pull request review raised a Security finding on the hardcoded secret and the risky logging. Once Rule enforcement was on, a team rule about credentials was applied as well. People revoked the key and fixed the logging path before merge.

Outcome: the leak shows up as a review finding on the pull request, alongside whatever the Git host scanner caught, and the merge decision stays with people and the host’s rules.

Ways to control secrets in code

Qodo features in this table were checked against Qodo’s documentation as of November 10, 2026.