TL;DR: Autonomous AI coding agents can open files, call APIs, install dependencies, and modify repositories without human approval, expanding exposure across filesystems, CI/CD, and cloud environments, according to Knostic. That shift collapses the review loop assumption behind traditional assistant-era controls, making sandboxing, scoped permissions, and runtime diff validation the practical baseline.
NHIMG editorial — based on content published by Knostic: Key Findings on AI Coding Agent Security
By the numbers:
- 88% stated that their organizations plan to increase budgets related to AI-agent deployment, integration, or management within the next 12 months.
- Only 3.1% of respondents in a 2025 Develop Survey said they highly trust AI in their workflows.
Questions worth separating out
Q: How should security teams govern autonomous AI coding agents without breaking developer workflows?
A: Start by giving agents their own execution identity, not shared developer permissions.
Q: Why do AI coding agents increase secret exposure risk in software delivery?
A: Because they can read configuration files, environment variables, and dependency metadata as part of normal task execution.
Q: What breaks when human-in-the-loop review is the only control for AI coding agents?
A: The review loop breaks when the agent can act faster than a person can inspect the change.
Practitioner guidance
- Separate assistant and agent privileges Do not let autonomous coding agents inherit the same repository, shell, and API scopes used by interactive developer tools.
- Sandbox every agent execution path Run agents in disposable environments with read-only mirrors of source and secrets, blocked host access, and constrained outbound network reach.
- Gate writes and merges with runtime review Require side-by-side diff inspection, commit gating, and human approval for risky file changes, dependency updates, and deployment hooks.
What's in the full article
Knostic's full analysis covers the operational detail this post intentionally leaves for the source:
- A deeper breakdown of the seven AI coding agent threat categories and how they map to specific execution paths.
- Implementation detail for execution sandboxes, explicit command allowlists, and diff approval workflows in developer environments.
- Role-by-role guidance for SecOps, DevOps, and AppSec ownership across agent monitoring and containment.
- Knostic's Kirin-specific policy enforcement examples for IDE extensions, MCP server checks, and dependency scanning.
👉 Read Knostic's analysis of AI coding agent security and runtime controls →
AI coding agents and MCP security: are your controls keeping up?
Explore further
Assistant-era review is no longer a sufficient trust model for AI coding agents: The security assumption behind human approval loops is that a person will see and judge each meaningful change before it affects shared systems. That assumption fails when the actor can open files, call tools, and modify repositories on its own within the same workflow. The implication is that governance must move from human review dependency to runtime action control.
A few things that frame the scale:
- 60,000 successful prompt-injection attacks out of 1.8 million attempts were recorded in a 2025 red-teaming experiment, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Our research also shows that organisations maintain an average of 6 distinct secrets manager instances, which fragments control and complicates agent-era secrets governance.
A question worth separating out:
Q: What is the difference between sandboxing and least privilege for coding agents?
A: Sandboxing limits where the agent can run and what systems it can touch. Least privilege limits what the agent is allowed to do inside that environment. Teams need both, because a safe runtime without narrow permissions still allows damaging actions, while narrow permissions without isolation still exposes the host.
👉 Read our full editorial: AI coding agent security demands controls beyond human review loops