AI coding agent governance is shifting to the source-code layer

At a glance

What this is: Arnica argues that AI coding agent governance now needs to happen at the source-code layer, because that is where generation, ownership routing, and secret remediation can be controlled before code spreads.

Why it matters: IAM, AppSec, and NHI practitioners need to see source control and identity routing as governance controls, not just developer workflow features, because AI-generated code changes where risk first appears.

Context

AI coding agents create a governance gap because code can now be generated, committed, and routed without a traditional developer workstation or a stable human owner in the loop. That shifts control pressure from scanning after the fact to governing the generation context, the commit path, and the human accountable for the change.

In this article, the identity angle is real: agent identities, departed authors, and stale ownership records all affect whether findings land with someone who can act. The broader lesson is that source-code governance is becoming an identity problem as much as a static-analysis problem.

Key questions

Q: What breaks when AI-generated code is only checked after commit?

A: Post-commit controls miss the moment when risky code is created, so secrets, insecure patterns, and policy violations can enter the repository before security ever sees them. That makes audit evidence incomplete and weakens defensibility. The practical failure is timing, because detection after commit cannot prove that policy was enforced at generation time.

Q: Why do stale CODEOWNERS records fail for AI-generated code?

A: Static ownership breaks because the named team may no longer include the person who can fix the issue, and bot-authored changes may not map cleanly to a human at all. If routing cannot resolve the current accountable person, remediation stalls. Active identity resolution is what makes ownership operational, not merely documented.

Q: How should security teams prevent secrets from reaching shared Git repositories?

A: Use a two-layer approach. Stop secrets locally with pre-commit detection, then enforce server-side rejection with pre-receive hooks so bypassed local checks do not matter. The goal is to prevent credential material from entering Git history at all, because cleanup after publication is unreliable and incomplete.

Q: Should security teams treat AI agents and model APIs as part of identity governance?

A: Yes. If an AI agent can call tools, access data, or act on behalf of a workflow, then its permissions, credentials, and delegation boundaries must be governed like any other non-human identity. Without that control, the model can become an over-privileged actor inside the environment.

Technical breakdown

Governance at generation time for AI coding agents

When an AI coding agent writes code, the practical control point is not the pull request or the IDE alone. The decisive layer is the rules the agent loads during generation, because those rules can steer output before insecure code exists. A source-code-layer model embeds policy into repository-managed configuration so the agent reads governed instructions every time it runs. That is different from perimeter scanning, which only sees code after it has already been produced. The governance question is therefore not whether code can be scanned, but whether the generation context was constrained before the first line was written.

Practical implication: Treat agent configuration as a control surface and govern it with the same discipline you apply to source and pipeline permissions.

Identity graph routing for code ownership

Owner routing breaks when CODEOWNERS points to a team alias, a departed employee, or a bot identity that has no direct human accountability. An identity graph addresses that by resolving SCM identity, chat identity, personal and corporate email, and agent-bot identity back to an active person. That matters because finding routing is only useful if the destination can remediate the issue. In AI-assisted development, the committed artifact may have been created by an agent, dispatched by a human, or inherited from an author who no longer exists in the organisation. The governance model has to identify the current accountable human, not just the historical author.

Practical implication: Build ownership resolution around active identity state, not static file ownership, so findings reach someone who can still fix them.

Secret removal at push time reduces exposure windows

A committed secret is dangerous as soon as it lands in shared history because clones, CI systems, and downstream developers can copy it immediately. Source-layer remediation changes the sequence by removing the secret from the commit history at push time and preserving the rest of the change in a masked branch. That does not replace live credential rotation, but it does reduce the spread of the leaked value across the development estate. The key control insight is that the exposure window starts at commit, not at detection triage, so remediation has to happen before the repository becomes a distribution channel.

Practical implication: Automate push-time secret excision and tie it to your existing rotation workflow so leaked values do not persist in git history.

Threat narrative

Attacker objective: The attacker objective is to turn source-code exposure into durable access or repeatable misuse before the organisation can contain the commit.

1. Entry occurs when an AI coding agent or developer pushes generated code into a repository with unsafe instructions or a committed secret already present.
2. Credential access happens when that committed secret is copied into repository history, clones, and CI systems before detection or rotation.
3. Impact follows when the exposed secret or unsafe code spreads beyond the original commit and becomes available to other developers, pipelines, or attackers.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Source-code governance is becoming the control plane for AI-era development: once code is generated by agents, the question is not only whether the code is secure, but whether the generation context was secure enough to begin with. Policy that lives in the repository can shape output before insecure patterns spread into shared history. Practitioners should treat the repo as a governance boundary, not just an asset store.

Identity resolution is now part of secure code routing: when ownership records point to teams, departed staff, or bot identities, remediation stalls even if the finding is accurate. The stronger model is to resolve the current accountable human from live identity signals and activity, because accountability has to match the person who can still act. Practitioners should align code-security routing with active identity state, not historical authorship.

Secret leakage is a source problem before it is a detection problem: once a credential is committed, every clone and CI copy multiplies exposure. That is why push-time remediation matters more than backlog speed for this class of issue. Practitioners should assume repository history is a distribution channel and design controls that remove secrets before they propagate.

Dynamic risk reprioritisation matters more than static backlog hygiene: a finding that was tolerable yesterday can become urgent when exploit intelligence changes. The governance gap is stale ownership combined with stale severity, which leaves old tickets attached to the wrong human. Practitioners should treat ownership refresh and threat-intelligence-triggered rerouting as part of the control model.

AI coding agent governance and NHI governance are converging: once an agent can generate, commit, and route code, it behaves like a non-human actor embedded in the software delivery chain. That creates a need for policy controls that address both machine-originated action and human accountability. Practitioners should plan for source-layer governance that spans agent identity, secret handling, and accountable human ownership.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Source-layer governance is the right response to AI-generated code because the policy has to exist before the code does. That is the practical shift practitioners should prepare for: the repository becomes the place where generation, review, and remediation are joined. For teams building around agentic development, the relevant question is whether controls fire at write time or only after the commit boundary.

Ownership resolution will matter more as cloud coding agents become normal contributors. When commits come from bot identities or from developers who have since left, static routing breaks down and remediation loses velocity. The programme implication is to align code-security routing with live identity state, active product ownership, and bot-to-human attribution.

Secret leakage in private repositories is still a live governance problem. According to the State of Secrets Sprawl 2026, internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), which means hidden development spaces are not safer by default. Practitioners should assume any repository can become an exposure channel unless push-time remediation and rotation are already operational.

For practitioners

• Govern agent rules at the repository layer Store approved guardrails in repo-managed agent configuration so policy is present whenever the coding agent generates code, not only when code is reviewed later.
• Replace static ownership with live identity resolution Map SCM, chat, email, and bot identities to the current accountable human so findings reach an active owner instead of a stale team alias or departed author.
• Remove committed secrets at push time Strip secrets from git history as soon as they are pushed, preserve the non-sensitive change in a masked branch, and route rotation through the existing secrets workflow.
• Re-prioritise findings when exploitability changes Re-evaluate historical code findings when KEV listings, EPSS shifts, or patch availability change, then reopen or reroute them to the current owner.
• Measure how often governed controls land in code Track whether security rule IDs appear in committed code and whether agent-generated output is consistently governed before merge.

Key takeaways

• AI coding agents change governance because the control point shifts to the source-code layer where generated code first takes shape.
• Identity-aware routing is now part of AppSec because findings are useless if they land with a departed author or a dead team alias.
• Secret exposure has to be interrupted at push time, because once a credential enters git history the distribution problem already exists.

Key terms

• Agentic Code Governance: The control of how AI coding agents generate, commit, and route code so that policy is applied before insecure output enters the repository. It combines generation-time guardrails, identity-aware ownership, and source-layer remediation to reduce downstream exposure.
• Identity Graph Routing: A routing model that resolves a finding to the current accountable person by combining identity signals such as SCM accounts, chat accounts, email, and bot identities. It replaces static ownership lists that often point to departed staff or generic team aliases.
• Push-Time Secret Remediation: A remediation pattern that removes a leaked secret from git history as soon as it is pushed, before the credential spreads through clones, CI, and additional commits. It reduces exposure window, but live credential rotation still has to happen in the secrets system.
• Source-Code Layer Governance: A control approach that treats the repository as the first place security policy should operate, not merely the place where code is reviewed later. It is especially relevant when generated code and machine-authored commits can appear without a traditional developer workstation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It helps security and identity practitioners build control models for non-human actors that now participate in software delivery.