Notifications
Clear all
Topic starter
20/08/2026 5:31 pm
TL;DR: Autonomous coding agents can write code, invoke tools, and push changes without a human reviewing each step, which breaks assumptions in traditional AI security and code review, according to Fiddler. The practical issue is not just secret leakage or prompt injection, but governance failure when agent behaviour outruns IAM, audit, and approval controls.
NHIMG editorial — based on content published by Fiddler: How Autonomous Coding Agents Are Reshaping Artificial Intelligence Security Issues
Questions worth separating out
Q: What breaks when autonomous coding agents are not governed like non-human identities?
A: The control model breaks because the agent can act, choose tools, and change code without waiting for a human checkpoint.
Q: Why do autonomous coding agents increase credential exposure risk?
A: They increase risk because they can read local files, execute commands, and continue a task without a human approval prompt.
Q: How can organisations tell whether AI agent governance is actually working?
A: Look for evidence that agent access is ephemeral, traceable, and constrained at the action level.
Practitioner guidance
- Inventory every active coding agent Create a live register of all agent deployments, including informal tools used by individual engineers, and map each one to repositories, services, and tool scopes.
- Assign each agent a distinct NHI Treat every coding agent as a separate non-human identity with scoped, rotatable credentials and explicit ownership in IAM and lifecycle processes.
- Constrain tool invocations with allowlists Define which package managers, cloud CLIs, CI/CD actions, and deployment endpoints each agent may call, and deny everything else by default.
What's in the full article
Fiddler's full blog covers the operational detail this post intentionally leaves for the source:
- Span-level trace examples showing how orchestrator, tool call, and sub-agent events are recorded
- Example guardrail configuration for blocking prompt injection and redacting secrets from agent output
- A governance checklist for inventorying agents, defining scopes, and maintaining auditable traces
- The Fiddler Centor Models discussion on in-environment evaluation and the reported $260K annual external evaluation cost estimate
👉 Read Fiddler's analysis of autonomous coding agent security issues →
Autonomous coding agents: are your identity controls keeping up?
Explore further
20/08/2026 6:18 pm
Autonomous coding agents invalidate the assumption that risk is reviewable before action. Traditional IAM and code approval models assume access persists long enough for a human to inspect it. That assumption fails when an agent can plan, execute, and commit within one session. The implication is not just tighter policy, but a rethink of where control belongs in the software delivery chain.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to the AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
A question worth separating out:
Q: How should organisations decide when to allow autonomous coding agents?
A: Allow autonomy only when the task is bounded, reproducible, and reversible. If the work can change multiple files, call external tools, or run in cloud environments, it needs stronger scoping, monitoring, and rollback readiness. Higher autonomy should always require higher assurance, not just faster delivery.
👉 Read our full editorial: Autonomous coding agents expose governance gaps in AI security
