AI coding agents are exposing secrets faster than policy can contain

At a glance

What this is: This webinar argues that AI coding agents accelerate secret exposure because they need real access to code and credentials, and current policy-led controls are not keeping pace.

Why it matters: It matters because security teams now have to govern agent access, tracking, and containment as an identity and secrets problem, not just an AI policy problem.

By the numbers:

• AI service credential leaks grew 81% year over year.

👉 Read GitGuardian's webinar on hardening developer workflows with AI coding agents

Context

AI coding agents create a governance gap because they need enough access to read code, test changes, and interact with credentials, yet those same permissions can expose secrets if they are not tightly scoped. The first-order problem is not whether agents exist, but whether access is granted, tracked, and contained in a way that matches their runtime behaviour. In practice, that makes this a secrets-management and identity-governance issue as much as an AI-usage issue.

GitGuardian's event framing points to a familiar failure pattern in a new setting: developers adopt tools that accelerate delivery, while the surrounding controls still assume a human operating model. When agents can inspect repositories and adjacent credentials, policy documents alone do not reduce the attack surface. The subject's starting position is typical for organisations moving fast with AI tooling and still relying on broad developer access, weak monitoring, and retrospective review.

Key questions

Q: What breaks when AI coding agents are allowed to run Git operations on untrusted repositories?

A: The trust boundary breaks because the agent can trigger repository-local behaviour that was never meant to be safe by default. Malicious hooks, nested repositories, and injected instructions can turn a normal checkout into host-level code execution. That risk is highest when the workstation already contains tokens, source code, or internal access.

Q: Why do AI-assisted development environments make secret management harder?

A: AI-assisted development increases the number of generated scripts, debug paths, and temporary files that can expose secrets. It also compresses review time, so credential handling is more likely to be treated as a setup task rather than a governance control. The result is faster development with a larger secret sprawl surface.

Q: How should security teams implement MCP in multi-step AI workflows?

A: Security teams should place MCP behind a controlled gateway, define strict tool schemas, and limit which agents can discover which tools. MCP works best when paired with authentication, session isolation, role-based access control, and approval steps for sensitive actions. Treat it as an orchestration layer, not a trust boundary, and keep the underlying APIs governed separately.

Q: How do organizations prove AI agent controls are actually working?

A: Organizations prove control effectiveness by showing which agents accessed which data, what actions they executed, and whether those actions stayed within approved task boundaries. Useful evidence includes logs, policy decisions, anomaly alerts, and review records. Without that chain, governance is mostly declarative.

Background and context

Why AI coding agents increase secret exposure

AI coding agents are not passive autocomplete systems. They often need live repository access, build context, test data, and sometimes credentials or tokens to complete a task. That changes the control problem from static code review to runtime access governance. If an agent can read the same configuration files, environment variables, or MCP-connected resources as a developer, it can also surface or misuse embedded secrets. The core failure is not the model itself, but the combination of broad access and weak containment around the work context.

Practical implication: Treat agent permissions as operational access, not a documentation problem.

MCP configs and the new secret sprawl surface

Model Context Protocol lets agents connect to tools and data sources, which makes it useful and risky at the same time. Public or poorly governed MCP configurations can expose connectors, tokens, and other credentials that were never meant to be broadly visible. The article's figure of 24,008 unique secrets in public MCP configs shows that the exposure surface is already measurable. For practitioners, the issue is not just secret storage but secret discovery across integration points that are now part of the AI workflow itself.

Practical implication: Inventory MCP-connected systems and treat their configuration files as credential-bearing assets.

Why policy-only controls fail against agentic workflows

A policy can say what an AI assistant should not do, but it cannot reliably enforce who can expose what, where, and during which task. Agentic workflows create short-lived, high-context actions that move faster than manual review, so the relevant controls shift to issuance, observability, and containment. If secrets are present in the workflow, the question is whether they can be isolated, masked, rotated, or revoked before the agent or attacker can propagate them. This is a governance gap, not just an implementation bug.

Practical implication: Move enforcement from policy statements to access boundaries, telemetry, and revocation paths.

NHI Mgmt Group analysis

AI coding agents turn secrets exposure into a runtime governance problem: the decisive control is no longer just secret storage, but whether the agent can see, reuse, or leak credentials during execution. Traditional policy frameworks assume a human can be instructed and reviewed after the fact, but an agent acts inside the task boundary. Practitioners should therefore treat every agent-to-tool connection as an access decision with containment requirements, not as a productivity feature.

Agent access without containment creates a secret sprawl multiplier: the article's emphasis on real access is the point, because useful agents need context and context often contains credentials. That makes the naming of a specific concept useful here: agentic secret sprawl is the spread of credential exposure across prompts, configs, connectors, and logs as AI workflows scale. Security teams should assume the sprawl expands wherever the workflow can observe and persist sensitive context.

Policy-led AI governance is insufficient when the exposure path is operational: the gap is not awareness, it is enforcement at the moment access is granted. The right control model is closer to identity governance and secrets lifecycle management than to acceptable-use policy. That means access scoping, revocation, and monitoring must be wired into the developer workflow itself, or the exposure window stays open for both mistakes and exploitation.

The NHI dimension is now central to AI developer security: service accounts, tokens, API keys, and MCP connectors are the real control plane behind the agent experience. Once those non-human identities are overexposed, the agent inherits the risk and the organisation loses visibility into who or what touched the secret. Teams should govern these credentials as first-class identities, not as implementation detail.

Attackers are exploiting the productivity layer because it compresses trust and execution: the article's examples show that AI-assisted development can blur the line between authorized automation and malicious propagation. That is exactly where security programmes need sharper boundaries for tool access, secret scope, and output handling. The practitioner conclusion is straightforward: if the workflow can act like a user, it needs user-grade controls and machine-grade containment.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Agentic development is becoming a secrets-management problem before it is a model-governance problem. As AI coding tools take on more repository and connector access, security teams need to shift from documenting acceptable use to instrumenting issuance, containment, and revocation inside the workflow.

Agentic secret sprawl: the spread of credentials across prompts, configs, logs, and connectors is now a programme-level risk, not a developer hygiene issue. That means AppSec, DevSecOps, and IAM teams have to align on where non-human identities live, how they are scoped, and how quickly they can be withdrawn when exposure is detected.

For practitioners

• Define agent-specific access scopes Separate human developer permissions from AI agent permissions and grant the smallest repository, tool, and credential scope needed for the task.
• Scan MCP and developer configs for embedded secrets Treat MCP connector files, local configuration, environment files, and workflow metadata as credential-bearing surfaces that need continuous discovery and removal of exposed tokens.
• Mask and revoke credentials before agent reuse Use short-lived credentials, redaction, and rapid revocation so that agents cannot persist or replay secrets beyond the immediate task boundary.
• Add runtime logging for agent tool calls Record which agent used which connector, which secret class was touched, and whether the action stayed within the approved workflow boundary.

Key takeaways

• AI coding agents increase secret exposure because they operate with live context and access, not because policy has failed to keep up in a narrow procedural sense.
• The practical evidence in this article points to a growing non-human identity problem, where connectors, tokens, and configuration files become the real control surface.
• Containment, telemetry, and rapid revocation matter more than policy statements when the workflow itself can access and propagate credentials.

Key terms

• AI Coding Agent: An AI coding agent is software that writes, edits, reviews, or tests code with limited human prompting. It operates as an agentic system that can plan actions, call tools, and modify development artifacts, so its identity, permissions, and audit trail must be governed like any other privileged software actor.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agentic Secret Sprawl: The spread of credentials, tokens, and secret material across AI prompts, configuration files, logs, and connectors as agentic workflows expand. It is a governance problem because the exposure surface grows wherever the agent can observe or persist sensitive context.
• Runtime Access Containment: The practice of limiting what an AI agent can access, retain, and propagate while it is executing a task. It focuses on the moment of use rather than after-the-fact review, which is essential when secrets can be exposed before a human sees the result.

What to expect at the briefing

GitGuardian's full event covers the operational detail this post intentionally leaves for the source:

• Live guidance on granting, tracking, and containing AI agent access in developer workflows
• Concrete hardening approaches for secrets handling across code, test, and validation steps
• Discussion of AI coding agent attack patterns, including workflow exfiltration and propagation scenarios
• Practical framing for AppSec and DevSecOps teams that need controls beyond a generic AI policy

👉 GitGuardian's full webinar covers the access, tracking, and containment details behind AI coding agent secret leakage.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org resources that connect identity governance to the broader security disciplines your programme depends on.