Yes, when those agents can act on code, data, or tools in ways that affect production risk. Their permissions should be scoped, reviewed, and audited like other privileged systems, especially when they interact with sensitive routes, secrets, or regulated data. The governance question is who can let the agent act, and under what policy.
Why This Matters for Security Teams
AI coding agents are no longer just productivity helpers when they can commit code, open pull requests, access repositories, call APIs, or retrieve secrets. At that point, the question is not whether the system is “human” or “non-human”, but whether it exercises authority that needs identity governance, privilege review, and auditability. That is why the control lens should align with NIST Cybersecurity Framework 2.0 as well as AI-specific guidance.
The operational risk is straightforward: if an agent can choose actions, the permissions attached to its runtime, tools, and secrets become part of the attack surface. Security teams often focus on model behaviour and miss the identity layer that governs what the agent is allowed to do. That gap matters because abuse can come from prompt injection, poisoned instructions, overbroad OAuth scopes, or weak approval workflows for code changes and deployments. Current guidance suggests treating the agent as a privileged workload whenever it can influence production outcomes.
In practice, many security teams encounter agent risk only after a bad commit, leaked token, or unauthorised deployment has already happened, rather than through intentional governance of the agent’s access path.
How It Works in Practice
Organisations should map the agent’s operating model before deciding how it fits into IAM and PAM. The key questions are: who can register the agent, which identity represents it, what secrets it may use, what approvals are required for sensitive actions, and how all activity is logged. The agent may not need a human-style account, but it still needs an identity boundary, a policy boundary, and a revocation path. That is where identity governance overlaps with PAM.
A practical control design usually includes:
- Separate identities for development, testing, and production use.
- Least-privilege access to repositories, build systems, ticketing, and deployment tools.
- Short-lived credentials and tightly scoped secrets rather than reusable long-lived tokens.
- Human approval for high-impact actions such as release promotion, credential retrieval, or data export.
- Central logging for prompts, tool calls, code changes, and policy denials.
Security teams should also assess the agent through an AI risk lens. The NIST AI Risk Management Framework is useful for governance, accountability, and monitoring, while the OWASP Top 10 for Agentic Applications 2026 highlights risks such as tool abuse, excessive autonomy, and prompt-driven misuse. For attack-path analysis, MITRE ATLAS adversarial AI threat matrix helps teams think about injection, manipulation, and downstream impact.
This guidance tends to break down in environments where the agent shares a broad service account across many systems, because attribution, revocation, and blast-radius control become too weak to support meaningful governance.
Common Variations and Edge Cases
Tighter agent governance often increases friction for developers, requiring organisations to balance automation speed against control assurance. That tradeoff is real, especially in fast-moving engineering teams where agents are used for code generation, test execution, or incident support. Best practice is evolving, and there is no universal standard for this yet, but the direction of travel is clear: autonomy without identity controls does not scale safely.
Some agents sit in low-risk environments and only draft suggestions, which may not justify full PAM treatment. Others can merge code, update infrastructure, or interact with production data, which makes them operationally closer to privileged service accounts than to simple productivity tools. The more an agent can change state outside a sandbox, the stronger the case for formal approval workflows, session recording, and continuous review.
Edge cases include delegated agents acting on behalf of a named employee, multi-agent systems sharing tools, and vendor-hosted agents with opaque internal controls. In those scenarios, organisations should require clear ownership, explicit policy boundaries, and evidence that the agent cannot exceed its approved scope. Where sensitive code, regulated data, or privileged operational paths are involved, current practice should also align with control families from frameworks such as NIST AI Risk Management Framework and the NIST Cybersecurity Framework 2.0.
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 MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Agent access and approvals map to identity and access governance. |
| NIST AI RMF | GOVERN | AI governance covers accountability for autonomous agent actions. |
| OWASP Agentic AI Top 10 | Agentic AI risks include tool abuse, prompt injection, and excess autonomy. | |
| MITRE ATLAS | Adversarial AI techniques help model prompt and tool manipulation risks. | |
| NIST SP 800-53 Rev 5 | AC-2 | Account management supports lifecycle control for non-human identities. |
Track agent identity creation, changes, review, and deprovisioning like any privileged account.
