Autonomous coding agents expose governance gaps in AI security

At a glance

What this is: Fiddler argues that autonomous coding agents break the human-in-the-loop assumptions behind traditional AI security by generating, reviewing, and deploying code through their own tool use.

Why it matters: IAM, PAM, and AI governance teams need to treat coding agents as governed identities because the control problem shifts from code review to scoped authority, telemetry, and approval boundaries.

Context

Autonomous coding agents are software identities that can plan work, call tools, write code, and take actions such as committing changes or preparing deployments. The governance problem is that these systems no longer wait for a human checkpoint before sensitive actions occur, so the control model changes from review-after-the-fact to authorization-before-action.

Fiddler's analysis places that shift squarely inside AI governance and non-human identity management. Once an agent can fetch credentials, choose tools, and move through development workflows on its own, traditional code review and static scanning only see the output, not the decision path that produced it.

Key questions

Q: What breaks when autonomous coding agents are given broad access?

A: Control breaks down when the agent can move across tools and repositories without tight limits on scope, attribution, or revocation. Broad access turns the agent into an uncontrolled identity layer, making it harder to know what was changed, who approved it, and whether the permissions still match the task.

Q: Why do AI coding agents create access and governance risk even when they are not autonomous?

A: Because they already operate with tool access, repository access, and execution permissions inside a live workflow. That means the risk comes from delegated authority, not just independence. Even partially supervised agents can still manipulate sensitive code, secrets, or deployment paths if their permissions and review boundaries are loose.

Q: What are the signs that a coding agent security control is failing?

A: A control is failing when benign-looking inputs can still trigger command execution, when skills or tools remain usable after the original task ends, or when untrusted content can influence agent actions across workflow boundaries. Repeated scanner bypasses, unexpected network access, and leaked environment variables are strong signals that the control is only screening content, not constraining execution.

Q: How should teams structure code review context for AI coding agents?

A: Teams should put the change intent, expected impact, and breaking behavior in the PR itself, not in side conversations or private knowledge. AI coding agents work best when they can read a concise summary first and then drill into linked issues, reviews, and test evidence only as needed.

Technical breakdown

Why autonomous coding agents break human approval checkpoints

An autonomous coding agent receives a high-level objective, decomposes it into tasks, and independently invokes tools to complete the work. That is materially different from a code-assist tool, which waits for a developer to approve each suggestion. The security impact is that credential use, dependency choice, repository changes, and deployment actions can all happen inside one agent session without a human making the risk decision. Static scanners only inspect artifacts after generation. They do not model the agent's runtime choices, so they miss the control failure that created the artifact in the first place.

Practical implication: Shift control design from post-change review to pre-authorised tool scope and session-level oversight.

How secret exposure happens inside agent-generated code

Coding agents often touch environment variables, secret stores, package managers, and infrastructure tooling as part of normal work. If the agent treats a production credential or connection string as just another text token, it can copy that value into code, logs, or commit messages. The failure is not only leakage, but the absence of a policy boundary that prevents sensitive material from moving into generated output. This is why output-side inspection matters. If guardrails only watch user input, the highest-risk data path remains unchecked at the point where the agent actually acts.

Practical implication: Apply redaction and secret-detection controls to generated outputs, not just to prompts or source context.

Why agentic audit trails must cover the full tool chain

Agent behaviour is distributed across orchestrators, sub-agents, LLM calls, and external tools, which makes the decision chain harder to reconstruct than a human developer's workflow. Without span-level traces, teams cannot tell why a library was chosen, why a deployment command was issued, or whether a tool call was initiated by the agent or inherited from prior context. That audit gap is operational, not cosmetic. It determines whether incident response can explain the chain of causality and whether governance teams can prove that policy enforcement actually happened across the session.

Practical implication: Record every tool call and sub-agent decision so governance teams can reconstruct the full session.

Threat narrative

Attacker objective: The attacker objective is to turn the agent's broad runtime authority into code changes, secret exposure, or deployment actions that bypass human review.

1. Entry occurs when an autonomous coding agent is given access to repositories, secrets, and development tooling as part of routine software work.
2. Credential access happens when the agent reads environment variables or secret stores and carries sensitive values into generated code or commit content.
3. Escalation follows when the agent is allowed to invoke tooling beyond its intended scope, including changes that can reach staging or deployment pathways.
4. Impact appears as unauthorised code changes, leaked credentials, or unreviewed actions that propagate into production-adjacent systems.

Breaches seen in the wild

• PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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

Autonomous coding agents turn code review into a governance problem, not a tooling problem. Traditional security assumed a human author and a separate human reviewer, but autonomous agents collapse those roles into one runtime actor. That means the control question is no longer whether code is scanned, but whether the agent was ever allowed to produce the action in the first place. The practitioner implication is that approval boundaries must move upstream of execution.

Scoped non-human identities are the correct baseline for coding agents. Treating an agent as just another automation job ignores the fact that it can choose tools and sequence actions at runtime. The most defensible model is a non-human identity with explicit permissions, rotatable credentials, and a defined session boundary. That aligns with OWASP-NHI and Zero Trust thinking, but only if the identity model follows the agent's actual authority. Practitioners should stop treating agent access as an exception to IAM.

Runtime observability is the missing control plane for agent governance. The central gap is not alert volume or model quality, but the inability to reconstruct what the agent did, in what order, and through which tools. A governance stack that cannot show the full agentic hierarchy cannot answer accountability questions after an incident. Decision-chain opacity: the system can produce code, but the organisation cannot reliably explain how that code came to exist. Practitioners need traceability that starts at policy decision and ends at output.

Output guardrails matter more than prompt hygiene once agents can act. Pre-input filtering can reduce prompt injection risk, but the highest-severity events in coding workflows often happen after the model has already generated code or invoked a tool. That is where secrets, unsafe commands, and unauthorised changes leave the system. The implication is structural: security must inspect what the agent emits, not just what it consumes.

OWASP-NHI and NIST AI RMF both fit here, but they solve different layers of the problem. NHI controls govern identity scope, secret lifecycle, and offboarding of the agent itself. AI governance frameworks govern the broader policy, monitoring, and accountability structure around that identity. Coding-agent programmes fail when those layers are blurred together. Practitioners should map identity controls to the agent and governance controls to the programme that supervises it.

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.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Coding Agents Security Guide

What this signals

Identity scope must be defined before autonomy expands: 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey. That gap becomes dangerous when the system can act, not just recommend, because excess privilege and runtime decision-making compound each other.

Governance teams should expect agent programmes to fail at the boundary between generation and execution, not only at the model layer. Decision-chain traceability: if the organisation cannot reconstruct tool use, sub-agent delegation, and output handling in one view, it cannot claim meaningful control over autonomous coding workflows.

For practitioners

• Inventory every live coding agent Document each autonomous coding agent, including informal deployments by individual engineers, and record which repositories, tools, and services it can reach.
• Assign the agent a scoped non-human identity Issue rotatable credentials with minimum necessary permissions and treat the agent as a distinct identity in your IAM and access review process.
• Define explicit tool allowlists Restrict each agent to approved package managers, CI actions, and deployment paths so a code-generation task cannot trigger broader infrastructure changes.
• Deploy output-side guardrails Inspect generated code, commit messages, and tool invocations for secrets, credentials, and unsafe actions before anything is committed or deployed.
• Capture full-session traces Log LLM calls, tool invocations, and sub-agent delegations so incident response can reconstruct the full decision chain for each session.

Key takeaways

• Autonomous coding agents change the security problem from reviewing code to governing runtime authority, because the agent can select tools, manage credentials, and push changes without a separate human checkpoint.
• The main control failure is behavioural visibility, not just secret detection. If teams cannot trace the full agent session, they cannot prove what happened or why a risky action occurred.
• Scoped identities, output guardrails, and full-session telemetry are the practical controls that separate manageable agent use from compounding governance risk.

Key terms

• Autonomous Coding Agent: A software agent that can decide, sequence, and execute development tasks with minimal human intervention. In practice, it reads code, invokes tools, and changes files in runtime, so governance must focus on its permissions, inputs, and action boundaries rather than only on the resulting code.
• Traceability Chain: A traceability chain is the link from a strategic intent to the work and evidence that proves it happened. Strong chains reduce interpretation and manual reconciliation, which is especially important when auditors or leadership need a reliable account of how progress was established.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
• Managed Non-Human Identity: A managed non-human identity is a machine or application credential whose lifecycle is controlled by a platform or intermediary rather than by the consuming application alone. It can simplify implementation, but the organisation still owns scope, ownership, review, and revocation decisions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or AI governance programme, it is worth exploring.