When GitGuardian reported that 28.6 million hardcoded secrets hit public GitHub in 2025, a 34% year-over-year increase, most security teams doubled down on scanning. More alerts, faster detection, better dashboards. But here's the uncomfortable truth: observation-only detection tells you what leaked yesterday. It doesn't stop the credential from reaching your repository today.
Coding agents compound this problem. Commits co-authored by coding agents leaked secrets at roughly twice the baseline rate. Yet most organizations still treat agent-generated credentials like human-authored ones, relying on detection strategies built for a different threat model. The result? Preventable exposures that scanning tools catch only after the damage is done.
These myths persist because they're half-true. Detection matters. Scanning works. But neither prevents exposure when the architecture allows credentials to leave the agent before any control can act. Let's clear up what's actually blocking prevention.
Myth 1: "Our CI Secret Scanner Catches Everything Before Merge"
Reality: CI scanners run after the code has already been committed, pushed to a remote branch, and consumed by your build pipeline. The credential is now in repository history, cached build artifacts, and accessible to every service account with read permissions.
Consider the timeline. An agent generates output containing an AWS access key at 2:14 PM. The developer accepts it. The code is committed and pushed at 2:16 PM. Your CI scanner fires an alert at 3:02 PM. In that 48-minute window, the credential may have been copied into a container image, logged by a pipeline step, or cached by a package manager. Rotation at that point is damage control.
The OWASP Top 10 for LLM Applications identifies sensitive information disclosure as a top risk category for LLM-powered systems. Your CI scanner is valuable for compliance reporting and audit trails. It's not an exposure prevention mechanism.
Myth 2: "Prompt Injection Filters Cover Credential Leakage"
Reality: Prompt injection filters are designed to catch malicious instructions going into the agent, not credentials coming out. They won't stop an agent from surfacing a database connection string it memorized from training data. They won't catch a developer who pastes a live API key into the prompt to debug a connection error.
Coding agent credential exposure operates through four primary vectors:
Training data memorization: Research by Carlini et al. demonstrated that adversaries can extract verbatim training examples from language models, including personally identifiable information and unique identifiers present in the training corpus. When an agent generates code in an adjacent domain, those memorized credentials re-emerge.
Environment file ingestion: Agents with file-system access read .env files and config objects to understand project context. If the agent echoes those values into generated code or a pull request description, the secret is now in a downstream artifact.
Chain-of-thought serialization: Agents that expose reasoning steps can serialize runtime secrets into visible logs. A database connection string from a stack trace can end up in the agent's output verbatim.
Developer-pasted credentials: A developer debugging an integration will often paste a live token directly into the prompt. That credential now sits in the agent's context window and chat history before any code is generated.
Input-side controls don't address output-side risks. You need enforcement at both the request path (catching what developers paste) and the response path (catching what agents generate).
Myth 3: "We Monitor Agent Usage, So We'll Catch Exposures"
Reality: Monitoring shows you what happened. It doesn't prevent it from happening. Observability-only tools flag credentials after they've already left the agent, been committed to a branch, and entered your CI pipeline.
The distinction matters architecturally. Observation-only detection scans logs, outputs, or repositories asynchronously. By definition, detection happens after the fact. The credential is already exposed by the time anyone finds out. Flagging is not enforcing.
Inline enforcement changes the architecture. Instead of scanning after delivery, policy is evaluated at the agent's response path before output ever reaches the developer's IDE, terminal, or version control system. The credential never leaves the gateway. There's no exposure event to remediate because the secret was blocked or redacted before delivery.
The Fiddler AI Control Plane for Coding Agents delivers secrets detection verdicts in under 100 ms. The developer doesn't notice the evaluation. The credential never reaches the commit.
Myth 4: "Our Developers Know Not to Paste Secrets into Prompts"
Reality: Developer training is necessary but insufficient. When you're troubleshooting a production outage at 11 PM and the agent needs context to fix a broken connection, you paste the connection string. It's not negligence, it's how debugging works under time pressure.
The problem isn't developer discipline. It's that the architecture permits the exposure before any control can intervene. A credential pasted into a prompt at 11:03 PM is in chat history, potentially logged, and accessible to downstream systems before your security team wakes up.
Request-side enforcement catches this vector. Every agent request passes through a secrets detection model before the prompt reaches the LLM. If a developer pastes an AWS access key into the prompt, the request is blocked or the credential is redacted before the agent ever processes it. The developer gets immediate feedback: "Your prompt contained a credential. Replace it with a vault reference."
This isn't hypothetical. MCP configuration files alone exposed more than 24,000 unique secrets last year, many of them pasted by developers who needed to give agents access to production resources.
Myth 5: "We Only Need to Scan Agent Outputs, Not Inputs"
Reality: You need both. Response-side controls catch credentials the agent surfaces from training data memorization, environment file ingestion, or chain-of-thought serialization. Request-side controls catch credentials the developer pastes directly into the prompt.
Neither side is covered by controls built for the other. Prompt injection filters focus on malicious instructions, not secrets. Output scanners run asynchronously, after the credential has already been delivered. The gap between these two control points is where exposure happens.
Gateway-level secrets detection closes the gap. Every request and every response passes through the same enforcement layer. Policies apply uniformly: block production database credentials, redact API keys, allow everything else. The "redact" verdict is particularly useful, it strips the credential and delivers the rest of the output, preserving the agent's useful code while removing the dangerous fragment.
What to Do Instead
Start with architecture, not tooling. Inline enforcement requires an evaluation point between the agent and the developer. If your organization already runs an LLM gateway for routing and cost tracking, secrets enforcement plugs into that same path. If you don't have a gateway yet, that's your first step.
Audit every coding agent's access scope. Which files, environment variables, and services can each agent read? Restrict to least privilege. An agent generating frontend components doesn't need access to .env.production.
Implement fleet-wide dashboards covering all agent instances, including ones your security team doesn't know about. Shadow AI usage is a real vector. Unmonitored agents are the ones most likely to cause a breach.
Require under 100 ms detection latency for any inline enforcement tool. Anything slower degrades developer experience and invites workarounds. Developers will disable enforcement if it adds perceptible delay to every response.
Rotate credentials that have ever appeared in an agent's output, even if the output was blocked before delivery. Treat any detection event as a near-miss. The fact that the model generated the credential means the secret exists in a context the model can access.
The 34% year-over-year increase in hardcoded secrets isn't a scanning problem. It's a prevention architecture problem. Observation-only detection will always be one step behind. Inline enforcement puts the control where it belongs: between the agent and the exposure.
