By NHI Mgmt Group Editorial TeamPublished 2026-06-18Domain: Agentic AI & NHIsSource: Zenity

TL;DR: Coding agents are entering enterprises as autonomous actors that can access repositories, execute commands, invoke APIs, and change infrastructure in chains of action, according to Zenity. Traditional identity, data, endpoint, and governance controls were built for discrete actions, not runtime behaviour across multiple systems, so access policy alone no longer captures the real risk.


At a glance

What this is: This is an analysis of how coding agents become autonomous enterprise actors and why existing governance models break at runtime.

Why it matters: It matters because identity, IAM, and security teams now have to govern action chains, not just permissions, across NHI, autonomous, and human workflows.

👉 Read Zenity's analysis of autonomous coding agents and enterprise governance


Context

Autonomous coding agents are software systems that can decide and execute actions across tools and environments without a human approving each step. In identity terms, the key problem is not just access, but runtime agency: a system that can initiate a sequence of actions after it is already authorised. That shifts the security question from who can act to how behaviour is controlled once action has begun.

Enterprise security has historically assumed that software follows predefined logic and humans initiate the activity. Coding agents break that assumption because they can navigate file systems, access repositories, execute commands, and interact with SaaS services as part of one continuous workflow. The result is a governance gap that touches NHI, privileged access, and emerging agentic AI controls at the same time.


Key questions

Q: How should security teams govern autonomous coding agents in enterprise environments?

A: Security teams should govern autonomous coding agents as behaviour-bearing identities, not as ordinary automation. That means defining task-scoped access, instrumenting tool use, and watching the full sequence of actions across repositories, terminals, APIs, and infrastructure. Approval alone is not enough because the risk appears when the agent starts composing its own workflow.

Q: Why do existing IAM controls struggle with autonomous agents?

A: Existing IAM controls struggle because they were designed to answer who can access what, not how an actor will behave after access begins. Autonomous agents can inherit valid permissions and still create risk by chaining those permissions across systems in ways that were never reviewed as a single action path.

Q: What breaks when governance is used as the main control for AI agents?

A: What breaks is the assumption that a governance approval can reliably predict safe runtime behaviour. An autonomous agent may pass policy review and still make decisions after execution begins that produce unsafe infrastructure changes, data movement, or command execution. Governance is necessary, but it cannot substitute for behavioural controls.

Q: Who should own risk decisions for autonomous coding agents?

A: Risk ownership should sit with the teams that can see both identity and execution, usually security, platform, and infrastructure owners working together. If ownership is split so that governance approves the agent but no one monitors its live actions, the organisation ends up with accountability on paper and no operational control.


Technical breakdown

Runtime behaviour in autonomous coding agents

Autonomous coding agents do not just generate output. They read context, choose a next step, call tools, and continue operating across repositories, endpoints, APIs, and cloud services. That matters because risk emerges from the sequence, not any single action. An access grant that looks legitimate in isolation can still become dangerous when the agent chains multiple approved actions into an unintended outcome. Traditional policy checks are static, but agent behaviour is dynamic and stateful.

Practical implication: security teams need telemetry that reconstructs action chains, not just entitlement snapshots.

Why identity controls miss agentic behaviour

Identity systems answer whether an actor is allowed to act, but they do not explain why the actor is acting or what it will do next. In autonomous workflows, an agent can inherit valid permissions and still produce harmful results by combining them in ways no policy review anticipated. This is where least privilege becomes harder to define, because the relevant boundary is no longer a single permission but the full runtime path across systems.

Practical implication: scope controls by task, tool, and session behaviour rather than by identity alone.

Governance versus security for autonomous systems

Governance can approve deployment and set policy, but it does not observe or constrain the live behaviour of an autonomous system once execution begins. Security has to close that gap with runtime visibility, behavioural monitoring, and clear ownership for agent actions. The issue is not whether the organisation has governance, but whether governance can survive an actor that makes decisions during execution rather than before it.

Practical implication: align governance approvals with enforcement and detection controls that operate during execution.


Threat narrative

Attacker objective: The objective is to use legitimate autonomous access to carry out high-impact actions across enterprise systems without triggering controls designed for human-paced workflows.

  1. Entry occurs when a coding agent is given legitimate access to repositories, terminals, APIs, and related enterprise tools as part of a development workflow.
  2. Escalation happens when the agent chains those permitted capabilities into a broader sequence, such as reading secrets, modifying code, executing commands, or touching infrastructure.
  3. Impact follows when the agent’s approved actions create an unsafe change, expose sensitive data, or alter production systems in ways the security programme did not anticipate.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Autonomous coding agents turn policy from a gate into a record of intent. Zenity’s framing is accurate because the real security problem is not whether the agent was approved, but whether approval means anything once the system begins composing its own sequence of actions. Identity and governance controls can still be satisfied while the agent behaves in ways that were never reviewed. The practitioner conclusion is that runtime behaviour, not pre-deployment approval, becomes the real control boundary.

Access review assumptions collapse when the actor can decide and act within the same session. Access review was designed for actors whose permissions persist long enough to be observed, certified, and revoked on a cycle. That assumption fails when an autonomous agent can acquire access, use it, and complete a chain of work before any review window opens. The implication is not a new checklist, but a rethinking of what review is supposed to catch.

Identity, data, endpoint, and governance controls are all necessary, but none of them were built to interpret autonomous chains of action. This is the gap Zenity identifies: each control sees a slice of the environment, while the agent produces risk across the full sequence. Runtime behaviour gap: a useful named concept for this class of problem, because it describes the mismatch between static authorization and live, cross-system execution. Practitioners should treat this as a structural limitation of existing control models, not a tuning problem.

Coding agents are the first enterprise-scale proof that autonomous behaviour changes the unit of identity risk. Once a system can initiate action across tools without human pacing, the security programme must move from managing permissions to managing sequences, context, and delegated intent. That affects NHI governance, privileged workflows, and emerging agentic AI policy in the same programme. The practitioner conclusion is that autonomous actors must be governed as behaviour-bearing identities, not as enhanced automation.

From our research:

  • 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.
  • 52% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, which means the access model is already outpacing the control model.
  • That pattern makes OWASP Agentic AI Top 10 a useful reference point for the tool-misuse and identity-abuse risks that follow from autonomous execution.

What this signals

Runtime behaviour gap: enterprises are moving into a model where approval and safety are no longer the same thing. A coding agent can be authorised, comply with policy, and still cause damage through the sequence of actions it chooses after execution starts.

With 53% of security leaders expecting AI to run major portions of infrastructure autonomously within three years, per The 2026 Infrastructure Identity Survey, the control problem is already shifting from identity issuance to live behavioural containment.

Teams should expect governance, IAM, and detection functions to converge around agent behaviour rather than just access entitlements. That means building programme ownership around runtime visibility, action lineage, and task-bounded delegation instead of treating agent policy as a documentation exercise.


For practitioners

  • Map autonomous action chains Trace every step a coding agent can take after initial authorisation, including repository access, terminal execution, API calls, and infrastructure changes. Use that map to identify where one approved action can become a harmful sequence.
  • Separate approval from enforcement Treat governance approval as one control layer and runtime enforcement as another. Require monitoring that can detect and interrupt unsafe behaviour during execution, not just record that the agent was allowed to start.
  • Limit task-scoped privileges Constrain agent permissions to the narrowest task and session context possible, and remove standing access wherever the workflow allows it. The goal is to reduce the number of enterprise systems an agent can combine in one chain.
  • Instrument for behavioural telemetry Log tool calls, command execution, data access, and cross-system transitions as one correlated event stream. Behavioural telemetry is what lets teams see when an agent remains within policy boundaries but still produces unsafe outcomes.

Key takeaways

  • Autonomous coding agents change the security problem from permission management to behaviour management across multiple systems.
  • Traditional identity and governance controls can still approve an agent while failing to describe the risky sequence it will execute.
  • Security teams need runtime visibility, task-scoped access, and correlated action telemetry before agent adoption scales further.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Autonomous coding agents map to agentic AI risks around tool use and runtime behaviour.
NIST AI RMFAI RMF is relevant because governance must account for live autonomous behaviour.
NIST CSF 2.0PR.AC-4Least-privilege access is central when agents can chain actions across systems.

Assess agent tool access, delegation, and execution paths against agentic AI threat controls.


Key terms

  • Autonomous Agent: A software actor that can choose actions, select tools, and decide when to execute without a human approving each step. In identity governance, that means the unit of control is no longer just access, but the behaviour the actor can produce once access is granted.
  • Runtime Behaviour: The sequence of decisions and actions an identity or system performs after execution begins. For autonomous agents, runtime behaviour is the real security surface because the risk often appears only when multiple legitimate actions are chained together across systems.
  • Task-scoped Access: Access limited to one defined objective, one execution context, or one session of work. For autonomous actors, task-scoped access matters because it reduces the chance that an agent can combine permissions into a broader and less predictable action chain.
  • Behavioural Telemetry: Operational evidence that shows what an identity actually did, not just what it was allowed to do. For autonomous systems, behavioural telemetry is essential because policy compliance alone cannot prove that the sequence of actions was safe.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: The Enterprise Just Got Its First Population of Autonomous Actors. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org