What breaks is the assumption that a developer tool only assists the user rather than acting on the user’s behalf. Once agent mode can clone repositories, edit files, run commands, and chain tool calls, the security question becomes one of delegated execution. Controls must follow the action path, not just the prompt content.
Why This Matters for Security Teams
Agent mode changes the trust boundary. A prompt is no longer just text to be interpreted; it can become a delegated execution request that reaches repositories, shells, package managers, ticketing systems, and secrets stores. That means security teams must think in terms of action authorisation, not prompt filtering. The risk is not only misuse by the user, but also unintended tool chaining, privilege escalation, and data exfiltration through autonomous steps.
This is why agentic guidance now aligns with OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework: the control problem shifts from static access review to runtime governance of what an agent is allowed to do, in what context, and for how long. NHI controls matter here because agents are workloads with identities, secrets, and execution privileges, not just chat interfaces. NHIMG research shows this is already being exploited in practice: 80% of organisations report AI agents have performed actions beyond their intended scope, including accessing unauthorised systems and revealing credentials, as covered in AI LLM hijack breach.
In practice, many security teams encounter this only after an agent has already touched a sensitive system rather than through intentional design review.
How It Works in Practice
The practical answer is to treat the agent as a governed workload with narrow, time-bound authority. Static RBAC is too coarse when behaviour is goal-driven and unpredictable. Instead, current guidance suggests combining workload identity, intent-based authorisation, and JIT secrets so the agent gets exactly what it needs for one task and nothing more. That usually means short-lived OIDC tokens or SPIFFE-style workload identity, policy-as-code checks at each tool call, and automatic revocation when the task ends.
A mature pattern looks like this:
- Authenticate the agent as a workload, not as a person, so every action is attributable.
- Issue ephemeral credentials per task rather than storing long-lived secrets in the agent runtime.
- Evaluate policy at request time, using context such as repository, branch, ticket, data sensitivity, and approved intent.
- Log every tool invocation and side effect so later review can reconstruct the action path.
That approach matches the direction of CSA MAESTRO agentic AI threat modeling framework and the OWASP Top 10 for Agentic Applications 2026, both of which emphasise runtime risk, tool abuse, and prompt-to-action boundaries. For code-centric environments, NHIMG’s Analysis of Claude Code Security is useful because it shows how fast agentic tooling can cross from assistance into delegated execution. The operational takeaway is simple: policy must follow the action path, not sit only at the chat front door. These controls tend to break down when agents are allowed persistent shell access in CI/CD, because one compromised session can chain file access, token discovery, and outbound delivery before human review can intervene.
Common Variations and Edge Cases
Tighter runtime control often increases friction, requiring organisations to balance autonomy against developer velocity. That tradeoff becomes especially visible in environments that rely on long-running jobs, shared build runners, or broad third-party integrations, where JIT provisioning and per-step policy checks can slow workflows.
There is no universal standard for this yet, but best practice is evolving toward intent-based authorisation for high-risk actions and static rules only for low-risk ones. In highly regulated environments, teams may need to deny autonomous writes to production systems entirely and force human approval for any change that affects secrets, infrastructure, or customer data. In less sensitive sandboxes, broader autonomy may be acceptable if the agent is isolated and every tool call is logged.
NHIMG data suggests why this matters: 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames, which makes persistent agent credentials particularly dangerous. That is why the Ultimate Guide to NHIs — 2025 Outlook and Predictions and OWASP NHI Top 10 both point toward least privilege, rapid rotation, and offboarding as baseline controls, not optional hardening.
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 | A2 | Agent tool abuse and delegated execution are core agentic risks. |
| CSA MAESTRO | T1 | Covers threat modeling for agent action chains and runtime authority. |
| NIST AI RMF | AI RMF governs risk, accountability, and oversight for autonomous agents. |
Bind every tool call to policy checks and restrict autonomous actions by task context.
