Coding agents need a different security model for enterprise control

At a glance

What this is: Zenity argues that coding agents are shifting enterprise AI risk from content generation to task execution, which expands the attack surface across setup, runtime, and execution.

Why it matters: For IAM, PAM, and NHI teams, the key issue is that coding agents behave like privileged non-human identities with delegated action rights, so approval-based controls and conventional telemetry are no longer enough.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Watch Zenity's on-demand webinar on securing coding agents that take action

Context

Coding agents change the security problem because they do not just suggest actions, they take them. In practice that means a developer-facing AI system can reach repositories, shells, production-adjacent tools, and third-party services while still appearing to be a productivity feature rather than a privileged runtime.

That creates a genuine identity and governance issue as well as a cyber control issue. Once an AI system can act through tools, permissions, and approval prompts, it starts to behave like a non-human identity with operational authority, which forces IAM, PAM, and NHI teams to rethink how access is granted, observed, and revoked.

The article is typical of what many enterprise programmes are now discovering: the control gap is not theoretical, and the weakness appears first at the intersection of developer convenience, delegated access, and insufficient runtime guardrails.

Key questions

Q: What breaks when coding agents are governed like ordinary AI assistants?

A: The main failure is that ordinary assistant controls assume the system only suggests content, while coding agents can execute actions. That breaks approval-based governance, weakens endpoint assumptions, and creates privilege leakage across repositories, shells, and external services. Security teams need identity, action, and runtime controls that match the agent’s ability to change state, not just generate text.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

Q: How do security teams know whether an agent is operating inside its intended boundary?

A: They need evidence for both intent and execution. That means recording what the agent was supposed to do, what it actually did, what tools it called, and whether it deviated from the approved workflow. If you only measure the final outcome, you miss unsafe paths that still ended well.

Q: Who is accountable when a coding agent makes an unsafe change?

A: Accountability should sit with the delegating owner of the workflow, the policy administrator who allowed the action, and the platform team that exposed the tool path. If the organisation cannot trace who authorised the task, which tools were available, and why the action was permitted, governance has failed.

Technical breakdown

Coding agent security spans setup, runtime, and execution

Coding agent risk is distributed across three layers. Setup and supply chain cover repositories, configuration files, plugins, packages, skills, and MCP servers that shape what the agent can reach. Runtime covers prompts, memory, reasoning, and approval flows, which influence what the agent decides to do. Execution is the moment the agent reads, writes, launches, or connects to external services. The problem is that a single malicious signal rarely tells the full story. Security teams need to correlate configuration, context, and actions before they can understand whether the agent is merely useful or materially dangerous.

Practical implication: Map controls to each layer so one failed approval prompt does not become a full compromise path.

MCP expands the agent’s effective trust boundary

Model Context Protocol gives agents structured access to tools and data sources, but that also means the agent inherits a broader operational trust boundary than a chat interface ever had. If the MCP server, connected tool, or upstream repository is compromised, the agent may faithfully execute poisoned instructions or misuse permissions in ways that look legitimate from the outside. The security question is not only whether the model is safe, but whether the connected toolchain can be trusted at task time. That makes MCP governance an access problem, a supply chain problem, and a runtime authorisation problem at once.

Practical implication: Treat every MCP connection as a privileged integration that needs inventory, policy, and continuous review.

Approval dialogs are not a durable control for autonomous actions

Approval prompts assume a human can meaningfully interrupt and evaluate a task before harm occurs. Coding agents weaken that assumption because they are designed for speed, often operate repeatedly, and can treat human approvals as routine friction rather than a control boundary. When the agent has enough context and privilege, the prompt becomes a formality instead of a safeguard. This is why destructive behaviour can occur even without an external attacker. The core failure is not malice, but misplaced confidence that human confirmation alone can contain machine-executed actions.

Practical implication: Use task-scoped limits, action filtering, and enforced stop conditions instead of relying on repeated human approval.

Threat narrative

Attacker objective: The attacker aims to turn a trusted coding agent into an execution channel that can alter systems, destroy data, or expand access without looking overtly malicious.

1. Entry occurs when an attacker plants malicious content, poisoned instructions, or compromised dependencies in a repository or connected toolchain that a coding agent is asked to process.
2. Escalation happens when the agent follows those instructions through MCP access, over-trusting context, or excessive permissions and begins executing commands or modifying files.
3. Impact follows when the agent reaches production-adjacent systems, deletes critical data, installs harmful packages, or performs actions that the user did not intend.

NHI Mgmt Group analysis

Coding agents are becoming non-human identities with action authority, not just assistants. Once a system can execute commands, alter files, and connect to external services, the governance question shifts from content safety to delegated operational authority. That means IAM, PAM, and NHI controls need to reason about task scope, execution scope, and revocation scope together. Practitioners should treat these systems as governed actors, not merely interfaces.

Approval fatigue is now a control failure mode, not just a usability issue. The article describes a familiar enterprise pattern: users click through repeated prompts because productivity pressure is high and friction is low. That behaviour creates a standing privilege effect even when the system is nominally task-bound. The relevant governance lesson is that human confirmation cannot be the primary containment model for autonomous execution. Practitioners should design for enforced boundaries instead of expecting vigilance.

MCP governance is emerging as a named control gap in agentic environments. The most distinctive risk here is not the model itself but the trust chain between the agent, the tool server, and the enterprise systems it reaches. That creates what we would call a toolchain trust gap, where a secure-looking agent can still be dangerous because its connected context is unbounded or unverified. Practitioners should inventory and constrain every tool connection as part of identity governance.

Traditional telemetry is too shallow for agentic execution risk. Endpoint and binary controls can detect obvious malware, but they do not explain why a coding agent made a harmful decision or which upstream context caused it. This is a correlation problem across supply chain, runtime, and execution layers. Security teams should build detection around behavioural sequences, not isolated events, and align that with NIST AI Risk Management Framework governance expectations.

The market is moving toward policy enforcement around agent actions, not just model prompts. That direction validates the shift from AI content moderation to AI operation control. For identity and security teams, the practical consequence is that access governance will increasingly include action-level authorisation, not just authentication. Practitioners should prepare for policy, logging, and review models that understand what the agent did, not only what it said.

What this signals

Toolchain trust gap: agentic systems create a new governance boundary between the model, the tools it can reach, and the enterprise identities it can exercise. That boundary needs policy, inventory, and review, not just prompt filtering. For practitioners, the immediate signal is that identity governance must extend into runtime action control and connected-service authorisation.

Coding agent programmes should now be measured by how well they limit state-changing actions, not by how often users approve prompts. When approval fatigue becomes normal, the control is effectively ceremonial. Teams should align their review model with NIST AI Risk Management Framework governance expectations and treat agent action logs as first-class security evidence.

The operational lesson is that developer productivity pressure will keep pushing agent privileges upward unless guardrails are enforced centrally. Security teams should prepare for policy-as-code, action throttles, and per-workflow scoping as the baseline for agent rollout. That is where NHI governance and AI governance begin to overlap in a practical way.

For practitioners

• Inventory coding agents as governed identities Classify every coding agent, plugin, MCP server, and connected workflow as a privileged non-human actor with an owner, an allowed action set, and a revocation path. That inventory should include where the agent runs, what it can touch, and which approvals it can bypass.
• Separate setup risk from runtime and execution controls Apply different controls to repository content, live context, and action execution so one compromise does not cascade across all three layers. Enforce code scanning, prompt and context monitoring, and command-level restrictions as distinct controls rather than a single policy layer.
• Constrain MCP servers and tool integrations Approve only the minimum tool connections required for a specific agent workflow, then review those integrations as privileged access paths. Maintain an inventory of MCP servers, data sources, and external services so hidden trust expansion does not go unnoticed.
• Replace approval fatigue with task-scoped guardrails Use enforced limits, stopping conditions, and action filtering for dangerous operations such as file deletion, package installation, and production access. If the control depends on a user noticing and rejecting a prompt, it is too weak for agentic execution.

Key takeaways

• Coding agents are not just content tools. They are action-capable systems that create a privileged execution problem for security teams.
• The article shows that setup, runtime, and execution all contribute to risk, which means single-layer controls will miss the real failure path.
• The practical response is to govern coding agents as non-human identities with strict action scopes, toolchain inventory, and enforced stop conditions.

Key terms

• Coding Agent: A coding agent is a software system that can plan, generate, and modify code with limited human prompting. In governance terms, it is not just a tool but an actor whose permissions, tool access, and rollback path must be managed as part of the delivery process.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Approval Fatigue: The point at which repeated approval requests cause users to stop evaluating each one carefully. In agent governance, this is a control failure mode because the human reviewer becomes desensitised, making the oversight layer ineffective even though the workflow still appears compliant.
• Toolchain trust gap: A toolchain trust gap is the mismatch between how safe an agent appears and how much authority its connected tools actually provide. It emerges when repositories, plugins, MCP servers, and external services are not governed as one access path, allowing trusted workflows to carry hidden risk.

What's in the full article

Zenity's full webinar covers the operational detail this post intentionally leaves for the source:

• Live attack demonstration showing how a coding agent can override a defensive control and continue executing a task.
• Extended Q&A on YOLO Mode, MCP security, monitoring, and governance decisions that were only summarised here.
• Researcher walkthrough of the full coding agent threat model across setup, runtime, and execution.
• Practical discussion of how teams can balance developer speed with destructive-action prevention.

👉 The full Zenity session includes the live attack demo, extended Q&A, and the complete coding agent threat model.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to connect identity controls to the broader security programme they run.