Notifications
Clear all
Topic starter
14/08/2026 6:32 pm
TL;DR: AI coding assistants are associated with roughly twice the baseline secret-leak rate, and GitGuardian reports 24,008 unique secrets in public MCP configs plus 81% year-over-year growth in AI service credential leaks. The governance problem is no longer whether agents should be used, but how access, tracking, and containment are enforced before workflow speed becomes exposure.
NHIMG editorial — here’s why we think this discussion matters
By the numbers:
Questions worth separating out
Q: How should security teams control AI agents that can read secrets and modify code?
A: They should control the action boundary, not just the credential boundary.
Q: Why do AI coding tools increase secrets risk?
A: AI coding tools increase secrets risk because they can accelerate the reuse of insecure patterns across repositories, test fixtures, and automation scripts.
Practitioner guidance
- Classify coding agents as bounded identities Assign each agent a named owner, an approved purpose, and a revocation path.
- Reduce secret reach in developer environments Remove long-lived credentials from local workstations, shared config files, and agent context wherever possible.
- Scan MCP and agent config files for secrets Include MCP configurations, agent manifests, and orchestration files in secret discovery and remediation workflows.
What to expect at the briefing
GitGuardian's full webinar covers the operational detail this post intentionally leaves for the source:
- A practical session on how to grant, track, and contain coding agent access in developer workflows.
- Discussion of the AI service credential leak patterns and public MCP configuration exposure behind the headline numbers.
- Concrete guidance for AppSec and DevSecOps teams that need controls beyond a policy statement.
- The live format and registration context for teams preparing to operationalise agent containment.
👉 Register for GitGuardian's live session on hardening developer workflows for AI coding agents →
AI coding agents and secret leakage at scale: are controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/08/2026 6:38 pm
AI coding agents are becoming non-human identities in practice, even when organisations still treat them as mere productivity tools. Once an agent can read code, call tools, and access credentials, it needs explicit lifecycle governance: provisioning, scoping, auditing, and revocation. That is an IAM and NHI problem as much as it is an AppSec problem, because unmanaged agent access becomes a hidden privilege layer. Practitioner conclusion: govern the agent as a distinct identity class, not as an extension of the developer keyboard.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who should own secret governance for coding agents?
A: Ownership should sit with identity, PAM, and platform security teams together, because the problem spans authorization, session control, and auditability. Developer teams can use the workflow, but they should not define the trust boundary. The governing question is whether access is short-lived, traceable, and revoked as soon as the task ends.
👉 Read our full editorial: AI coding agents are exposing secrets faster than policy can contain
