Security teams should separate the authority to request work from the authority to execute it, then scope each agent to the minimum repositories, tools, and pipeline stages needed for its task. The safest design uses explicit approval points for sensitive actions, strong logging for delegated steps, and periodic review of which agent identities still need those permissions.
Why This Matters for Security Teams
Developer agents are not just another service account. They can plan, chain tools, open pull requests, trigger builds, and push deployments, which means their failure modes look more like autonomous systems than static workloads. That is why guidance from OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework both push teams toward runtime governance, not just onboarding controls. Static RBAC alone cannot capture intent, context, or the fact that one agent may need read access to code but only JIT authority to deploy a release candidate.
NHI governance matters here because the agent itself is the identity boundary. If its Secrets are long-lived, if its workload identity is vague, or if approval is only checked at signup time, the agent can keep acting long after the original task should have ended. The safest pattern is to treat the agent as an NHI with scoped, revocable authority and to separate the identity that requests work from the identity that executes it. NHIMG research on the OWASP NHI Top 10 shows why agentic systems demand stronger delegation controls, and the pattern is reinforced by the Analysis of Claude Code Security.
In practice, many security teams discover overreach only after an agent has already touched a build, a secret store, or a deployment stage that no one meant to expose.
How It Works in Practice
Start with workload identity, not password-style access. A developer agent should authenticate as a distinct NHI using cryptographic proof of what it is, then receive narrow, short-lived permissions per task. In current guidance, this usually means pairing workload identity with JIT credential provisioning so the agent gets only the repository, CI runner, artifact store, or deployment target needed for the current action. For implementation patterns, teams often look to SPIFFE-style workload identity and policy engines that evaluate requests at runtime, because agent behaviour is dynamic and cannot be safely encoded as a static role matrix alone.
For sensitive steps, separate request from execution. A coding agent may propose a dependency change, but a release agent should need a second approval before promotion to production. That approval can be enforced through policy-as-code, OPA-style checks, or equivalent context-aware authorisation logic. CSA MAESTRO agentic AI threat modeling framework and NIST Cybersecurity Framework 2.0 both support this kind of control layering: know the asset, limit the blast radius, and verify every privileged step.
- Use separate identities for planning, code review, build execution, and deployment.
- Issue short-lived credentials per job, then revoke them automatically at completion.
- Log every delegated step with actor, intent, context, and target system.
- Require human approval or stronger policy for production changes, secret access, and rollback actions.
- Review entitlements on a fixed cadence and retire unused agent identities quickly.
NHIMG’s research on the Top 10 NHI Issues is a useful reminder that over-privilege and weak monitoring remain common attack drivers, and the same applies when the NHI happens to be an autonomous developer agent. These controls tend to break down when one agent is allowed to span source control, CI, and production release systems without a hard policy boundary between them because the chain of trust becomes impossible to audit in real time.
Common Variations and Edge Cases
Tighter agent controls often increase build friction and slow release pipelines, so organisations have to balance speed against the cost of stronger governance. That tradeoff is real, and best practice is evolving, not settled, for fully autonomous code-changing agents. Some teams allow broad read access to repos but keep write, merge, and deploy permissions on separate identities; others isolate highly sensitive pipelines entirely. The right design depends on the organisation’s tolerance for agent autonomy and the sensitivity of the target systems.
The edge cases are usually where static IAM breaks hardest. An agent that can open a pull request, call an issue tracker, fetch a secret, and trigger deployment is effectively a multi-step attacker path if one credential is abused. That is why NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both favour runtime controls, traceability, and bounded autonomy. Where there is no universal standard yet, the safest operational choice is to constrain the agent to the minimum set of stages, apply ephemeral secrets, and force explicit approval at the point where code becomes runtime impact.
NHIMG’s Analysis of Claude Code Security also highlights a practical reality: controls need to fit developer workflows, or teams route around them. In fast-moving CI/CD environments, governance fails when the agent’s permissions outlive the task or when deployment authority is reused across unrelated repos and pipelines.
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 | A1 | Agentic systems need runtime boundaries and abuse-resistant tool access. |
| CSA MAESTRO | Covers threat modeling for autonomous agents across code and deployment chains. | |
| NIST AI RMF | Frames governance for autonomous AI behaviour and accountability. |
Model each agent workflow, then place approvals and monitoring at every privilege escalation point.
Related resources from NHI Mgmt Group
- How should security teams govern privileged access across service accounts and AI-driven systems?
- How should public sector teams govern hybrid identity security across cloud and on-prem systems?
- How should security teams govern SSO across multiple enterprise applications?
- How should security teams build a unified view of identity risk across IAM tools?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
