Why do AI coding agents create security risk even when they use the same model?

Because the model is only one part of the system. The harness determines whether the agent plans securely, uses approved libraries, validates output, and runs checks before handoff. Two agents can produce very different risk profiles from the same model when one is guided by guardrails and the other is not.

Why This Matters for Security Teams

AI coding agents change the risk equation because they can move from suggestion to action. The same model may be safe enough in a chat window but materially riskier when wrapped in a harness that can read repositories, call tools, write files, open pull requests, or execute code. That means the control question shifts from model quality alone to system design, approval flow, and output validation, which is why the NIST AI Risk Management Framework is a better starting point than model performance metrics by themselves.

Security teams often underestimate how quickly a harmless-looking code suggestion becomes a supply chain event once it is merged, deployed, or used as a dependency in another workflow. Prompt injection, poisoned repository content, and unsafe tool use can all shape the agent’s decisions even when the underlying model is unchanged. The practical issue is not whether the model can reason, but whether the surrounding agent runtime can constrain what it is allowed to see, do, and emit. In practice, many security teams encounter agent risk only after an automated commit, credential exposure, or dependency mistake has already reached the review queue, rather than through intentional testing.

How It Works in Practice

An AI coding agent is usually a model plus orchestration logic. That orchestration may include repository access, retrieval, task decomposition, memory, tool calling, linting, test execution, and commit or merge permissions. Each of those layers can widen the attack surface. A model that merely drafts code is one risk profile; the same model that can fetch issues, read secrets, and execute shell commands is a different system entirely. Current guidance from the OWASP Top 10 for Agentic Applications 2026 emphasizes that agentic failures often arise from tool abuse, excessive autonomy, and inadequate output validation.

Operationally, strong implementations usually add layered controls:

• scoped tool permissions so the agent can only access approved repos, branches, and environments
• human approval gates for code changes, dependency additions, and secret-handling actions
• deterministic checks such as unit tests, static analysis, dependency scanning, and policy validation before handoff
• retrieval hygiene so the agent cannot blindly trust repository comments, tickets, or external content
• logging and traceability so prompts, tool calls, and code diffs can be reviewed after the fact

This is where NHI thinking becomes useful: the agent is acting with delegated authority, so its identity, permissions, and session boundaries need the same discipline applied to privileged non-human systems. If the agent can impersonate a developer, access secrets, or open a release path, then its runtime should be treated as a privileged workload rather than a simple productivity feature. Threat modeling with the CSA MAESTRO agentic AI threat modeling framework and adversary patterns from the MITRE ATLAS adversarial AI threat matrix helps teams separate model weakness from orchestration weakness. These controls tend to break down when the agent is granted broad filesystem and network access because the runtime can transform untrusted instructions into real execution paths.

Common Variations and Edge Cases

Tighter agent controls often increase friction, requiring teams to balance developer speed against the cost of extra review, slower automation, and more configuration effort. That tradeoff is especially visible in fast-moving CI/CD pipelines, where teams want agentic assistance but also need reproducibility and change control.

Best practice is evolving for autonomous coding agents that can open pull requests, manage tickets, or interact with production-adjacent systems. There is no universal standard for how much autonomy is acceptable, so organisations should classify use cases by blast radius. A low-risk refactoring assistant may only need read-only repo access and post-generation validation, while an agent that can modify infrastructure code or secrets handling needs stricter guardrails, separation of duties, and stronger approval workflows.

Edge cases matter when the agent is exposed to untrusted repository content, external web pages, or issue trackers that may contain prompt injection attempts. The same model can behave differently depending on whether the harness filters instructions, strips sensitive context, or checks outputs against policy before execution. Recent reporting on real-world AI-enabled attacks, including the Anthropic report on AI-orchestrated cyber espionage, reinforces that capability without containment is the real issue. For governance and assurance, map these workflows back to the NIST Cybersecurity Framework 2.0 so detection, response, and recovery are defined before an agent reaches production.

Related resources from NHI Mgmt Group

• Why do AI coding agents create governance risk even when they improve productivity?
• Why do AI agents create new risk even when they are short-lived?
• Why do AI agents create risk even when they stay within approved permissions?
• How should security teams govern AI use when the same model creates different risk in different contexts?