Notifications
Clear all
Topic starter
19/08/2026 3:43 pm
TL;DR: Coding agents can surface API keys, tokens, and connection strings in generated code, logs, and pull request text, and Fiddler argues that only inline enforcement at the request and response path can stop exposure before it reaches downstream systems. Observation-only detection remains useful for audit, but it leaves the blast radius intact once a credential has already left the agent.
NHIMG editorial — based on content published by Fiddler: How To Prevent Coding Agent Credential Exposure in Production Pipelines
By the numbers:
- 28.6 million new hardcoded secrets hit public GitHub in 2025, a 34% year-over-year increase.
- Coding agents leaked secrets at roughly twice the baseline rate in GitGuardian's 2026 analysis.
Questions worth separating out
Q: How should security teams prevent coding agents from exposing secrets in generated output?
A: Place secrets detection at the agent request and response path so exposure is intercepted before delivery.
Q: When does observation-only detection fail for coding agent secrets?
A: It fails whenever the secret has already crossed into a branch, log, cache, or chat history before the alert fires.
Q: What do teams get wrong about security inside coding agents?
A: They often assume placing a scanner or policy bot inside the agent makes the experience developer-first.
Practitioner guidance
- Enforce inline secrets controls at the agent gateway Evaluate every coding agent request and response before delivery, and use allow, block, or redact decisions based on secret type and project risk.
- Restrict agent access to only the files and environment variables required Audit each agent's file-system and environment scope, then remove access to production .env files, signing material, and unrelated services.
- Treat every detected secret as a near-miss requiring rotation Rotate any credential that appeared in a prompt, output, or log, even if redacted before delivery.
What's in the full article
Fiddler's full blog post covers the operational detail this post intentionally leaves for the source:
- Model-level explanation of how the Fiddler AI Control Plane applies allow, block, and redact decisions at the gateway
- Examples of policy scoping by secret type, team, project, and agent type for production rollout
- Implementation detail on Centor Models latency, deployment modes, and inline evaluation flow
- Operational guidance on fleet-wide monitoring across first-party, third-party, and shadow agent instances
👉 Read Fiddler's analysis of preventing coding agent credential exposure in production pipelines →
Coding agent secrets exposure: are your controls catching outputs?
Explore further
19/08/2026 4:21 pm
Output-side secret exposure is a governance problem, not a logging problem. Coding agents can surface credentials before a human ever approves a commit, which means the breach moment occurs inside the interaction. That collapses the usefulness of after-the-fact scanning as a primary control. The practitioner conclusion is simple: if the exposure happens in-session, the control must also operate in-session.
A few things that frame the scale:
- 28.6 million new hardcoded secrets hit public GitHub in 2025, a 34% year-over-year increase, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: What should organisations do when a coding agent exposes a credential?
A: Rotate the credential immediately, review the agent's access scope, and check whether the secret appeared in prompts, outputs, or downstream artifacts. Then decide whether the agent needs stricter redaction, blocking, or file access limits. Treat the event as a control failure, not just an alert.
👉 Read our full editorial: Coding agent credential exposure demands inline enforcement at runtime
