They create risk because they can act on local systems using persistent project context, not just answer questions. That means the authority to execute can come from mutable repository content, which is a very different control problem from static secrets or ordinary chat interactions. Governance must cover the context that shapes action, not only the action itself.
Why This Matters for Security Teams
Agentic coding assistants change the control problem because they do more than generate text. They can read local files, interpret repository context, call tools, and execute actions that persist beyond a single prompt. That creates governance risk for NHI teams because authority may be inherited from project state, scripts, and token scope rather than a clean human approval flow. Current guidance suggests treating the assistant as an active workload, not a passive interface, especially when it can reach build systems or deploy pipelines.
This is where static IAM assumptions fail. A role granted to “the developer” does not describe which repo files, shell commands, or secrets a coding assistant may consume at runtime. The risk pattern is already visible in the broader NHI landscape: NHI incidents are common, and the The State of Non-Human Identity Security report by Astrix Security & CSA found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. Agentic tools extend that visibility problem into the workstation and repository itself.
Security teams should also look at the control themes in the OWASP NHI Top 10 and the OWASP Agentic AI Top 10, because the main failure is not just credential theft. It is the assistant using legitimate access in unexpected ways. In practice, many security teams encounter this only after an assistant has already touched a sensitive path, rather than through intentional governance design.
How It Works in Practice
The right control model starts with workload identity and runtime policy, not permanent privilege. A coding assistant should be treated as an authenticated workload with narrowly scoped, short-lived authority tied to a specific task, repository, and environment. That usually means ephemeral tokens, just-in-time access, and explicit session boundaries rather than standing credentials that can be reused across projects. The assistant’s identity is not the same as the human operator’s identity, even if the human initiated the session.
Practical governance usually combines four elements:
Workload identity for the assistant process so policy can distinguish one agent session from another.
Context-aware authorisation so access is decided at request time, based on file path, repo trust level, command type, and intended action.
Short-lived secrets with automatic revocation, so tokens do not outlive the task that needed them.
Logging that captures both the action and the context that caused it, because the mutable repository content may be part of the authorisation chain.
This approach aligns with the runtime focus in the NIST AI Risk Management Framework and the implementation emphasis in the CSA MAESTRO agentic AI threat modeling framework. It also fits the operational lessons documented in Analysis of Claude Code Security, where code-centric assistants need governance that follows execution context, not just user intent. These controls tend to break down when agents are allowed to chain tools across local shell, CI, and cloud APIs because the effective privilege surface expands faster than the approval model can track.
Common Variations and Edge Cases
Tighter control over agentic assistants often increases friction for developers, so organisations have to balance speed against containment. There is no universal standard for this yet, especially in fast-moving engineering environments where teams want assistants to refactor code, run tests, and open pull requests with minimal interruption.
One common edge case is a “read-only” assistant that still becomes risky because repository content can instruct it to pivot into actions the original policy did not anticipate. Another is a shared developer workstation where the assistant inherits cached tokens or environment variables from previous sessions. Best practice is evolving, but guidance increasingly points to separate policy for local development, CI automation, and production-facing toolchains.
Teams should also watch for prompt injection through code comments, README files, and task manifests. Those inputs can silently reshape what the assistant attempts next, which is why NHI teams should review the agentic application controls in the OWASP Agentic Applications Top 10 alongside broader identity governance. For some environments, especially air-gapped build systems or highly regulated release pipelines, the practical answer is still to prohibit autonomous execution and require human approval for every privileged step.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic assistants can be steered by context and tools, creating prompt and action abuse risk. |
| CSA MAESTRO | T1 | MAESTRO focuses on agent threat modeling and runtime control of autonomous behavior. |
| NIST AI RMF | AI RMF guides governance for contextual, runtime AI risk rather than static access only. |
Assign ownership, monitor behavior, and evaluate AI risk continuously across the lifecycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
