TL;DR: AI agents are pushing identity lifecycle management, user access reviews, and change control beyond human-only assumptions, according to SailPoint. The audit problem is no longer whether controls exist, but whether they cover every non-human identity that can act inside material business processes.
At a glance
What this is: This is an analysis of how AI agents are stressing long-standing IT general controls by operating as non-human identities with production access.
Why it matters: IAM and NHI teams need to extend lifecycle, access review, and change-control governance to agents before audit gaps become operational gaps.
👉 Read SailPoint's analysis of AI agents and IT audit controls
Context
AI agent governance is now an identity security issue, not just an AI oversight issue. As agents are embedded into business workflows, they inherit access, make decisions, and touch regulated systems in ways that traditional human-centric ITGCs were not designed to govern.
SailPoint frames the problem as a control-silo issue: lifecycle management, access reviews, and change management are still often handled separately, while AI agents cut across all three. That pattern is increasingly atypical for mature programs, because the control failure is usually not the absence of policy, but the absence of a unified inventory and review model.
Key questions
Q: How should security teams govern AI agents as non-human identities?
A: Treat AI agents as first-class identities with named owners, explicit purpose, scoped entitlements, and a revocation path. Then apply lifecycle management, access reviews, and change control to the agent itself, not just to the human requester or surrounding application. That is the only way to make agent activity auditable and defensible.
Q: When do AI agents create more risk than they reduce?
A: They create more risk when they inherit broad tool access, operate across material business processes, or cannot be fully inventoried and reviewed. In that state, the agent expands effective access without equivalent governance. If you cannot explain what it can reach and who approves changes, the control model is too weak.
Q: What is the difference between human access reviews and agent access reviews?
A: Human access reviews ask whether a person still needs a role or entitlement. Agent access reviews must ask what the identity can do across systems, how its permissions were delegated, and whether its effective access has grown beyond the original business intent. Agents require an operational, not just role-based, review model.
Q: Should organisations build separate controls for AI agent deployments?
A: Yes. AI agents behave like software and identities at the same time, so they need both SDLC-style approval gates and IAM-style entitlement controls. A separate control path prevents informal deployment from becoming permanent production access and gives auditors a clear evidence trail.
Technical breakdown
Why IT general controls break down for AI agents
IT general controls were built around bounded human roles, approved changes, and periodic review of stable entitlements. AI agents disturb that model because they can be provisioned like software, execute like a user, and expand their effective access through tool use and indirect delegation. In practice, the control evidence can look clean for the human requester while the agent quietly holds broader access than the person behind it. That is why an agent can pass a human access review while still creating an unreviewed path into finance, operations, or customer systems. Practical implication: treat agent access as a separate control object, not as a side effect of the human account that invoked it.
Practical implication: Inventory each agent as its own identity and map its effective privileges before audit testing begins.
Agentic development lifecycle and production change control
The article’s Agentic Development Lifecycle idea is the software-control answer to AI agents in production. The underlying issue is not only how the agent was built, but whether its creation, approval, testing, deployment, and ongoing review are auditable in the same way as code changes. If agents are introduced through informal workflows, the organisation loses traceability over who approved access, what environments were used, and which business processes the agent can affect. That creates a gap between model deployment and operational accountability. Practical implication: extend SDLC-style gates to agents before they touch production systems or regulated data.
Practical implication: Require documented approval, testing, and ownership for every agent before it reaches a live process.
Why agent visibility is the real control boundary
Visibility is the control boundary that determines whether lifecycle and access rules are enforceable. Without a complete inventory of service accounts, bots, machine identities, and AI agents, teams cannot answer basic audit questions about scope, ownership, or revocation. The article’s core warning is that fragmented tooling leads to fragmented assurance, especially when an agent is allowed to act on behalf of a human, another agent, or a production workflow. Once delegation chains exist, the blast radius is no longer obvious from any single account view. Practical implication: build unified discovery and ownership mapping before relying on reviews or attestations.
Practical implication: Centralise discovery across all non-human identities so access reviews cover the full delegation chain.
Threat narrative
Attacker objective: The attacker wants to exploit hidden agent privileges to reach sensitive business systems through an access path that looks legitimate on paper.
- Entry occurs when an AI agent or related non-human identity is granted production access through informal provisioning or delegated human approval.
- Escalation follows when that agent inherits broader permissions than the human operator and can act across systems that the operator cannot directly reach.
- Impact arrives when the agent's indirect access touches financial records, customer data, or operational workflows without being visible in standard human-centric reviews.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI agents create an audit gap because they behave like identities, not like ordinary applications. That distinction matters because identity controls assume traceable ownership, bounded scope, and revocation paths. Agents blur all three by combining human intent, software execution, and tool access. Practitioners should govern them as first-class non-human identities.
Identity lifecycle controls are now incomplete if they stop at employees and contractors. The joiner-mover-leaver model is still useful, but it fails when service accounts, bots, and agents are created informally and never retired. A mature program needs explicit provisioning, attestation, and offboarding for every operational identity.
Agentic Development Lifecycle is a necessary control concept for production AI. The article correctly identifies that AI agents need the same kind of approval, testing, and change oversight that enterprises already demand for software. Without that discipline, regulators and auditors will see agent deployment as an unmanaged production change, not an innovation program.
Unified visibility is the named concept that should anchor NHI governance for agentic systems. Fragmented oversight is the real failure mode here, because no team can secure what it cannot inventory or trace. The practical conclusion is simple: if a program cannot enumerate every agent and its effective access, it cannot credibly claim control.
Audit teams will increasingly test effective access, not just declared access. An access review that looks clean on a human account can still miss the broader authority inherited through agents and delegation chains. That shifts the governance question from who logged in to what the identity can actually do.
From our research:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- That combination of secret sprawl and weak revocation makes Top 10 NHI Issues the next practical step for teams building agent governance.
What this signals
Unified visibility is becoming the control threshold for agentic environments. If teams cannot inventory every non-human identity and trace what it can access, the program is already operating below audit-ready maturity. The governance question is no longer whether AI agents exist, but whether their privilege paths are knowable and revocable.
With 98% of companies planning to deploy even more AI agents within the next 12 months, per SailPoint's cited research, the governance burden will grow faster than most IAM teams can manually review. That means lifecycle, change, and access controls have to move from periodic governance to continuous control enforcement.
For practitioners, the strategic shift is to treat agent governance as a cross-domain identity programme rather than a niche AI policy exercise. The right operating model joins inventory, approval, review, and offboarding into one chain of control, which is closer to OWASP NHI Top 10 thinking than classic application security.
For practitioners
- Implement unified NHI inventory discovery Create a single inventory for service accounts, bots, machine identities, and AI agents so ownership, purpose, and access scope are visible in one place.
- Extend access reviews to effective agent privileges Review what each agent can actually do across connected systems, not just the permissions attached to the human requester or primary application.
- Add approval gates to agent deployments Require documented review, testing, and business-owner approval before any agent is allowed into a production workflow or regulated process.
- Define offboarding for non-human identities Build a revocation path for agents and service accounts when scope changes, projects end, or the identity is no longer needed.
Key takeaways
- AI agents should be governed as non-human identities because they can hold, inherit, and expand access independently of the human operator.
- Traditional ITGCs fail when identity inventory is incomplete, because effective access can be broader than declared access.
- The practical response is to unify lifecycle, review, and change control around every agent before production exposure grows.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | NHI-03 | Agent lifecycle and privilege scope map directly to agent identity and tool-use risk. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control are central to governing agent permissions and ownership. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Continuous verification fits agents that act across systems and change scope over time. |
Review each agent's tool access, approval trail, and revocation path before production use.
Key terms
- Non-Human Identity: A non-human identity is any machine or software entity that authenticates to systems and performs actions under its own credentials. That includes service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities need ownership, lifecycle control, and access review because they can create real operational risk.
- Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
- Effective Access: Effective access is the actual set of actions an identity can perform across systems, including privileges inherited through delegation, tools, or chained permissions. It is often broader than the access listed on paper, which is why agent governance must measure what the identity can really do.
- Identity Blast Radius: Identity blast radius is the maximum scope of damage possible if an identity is misused, compromised, or left overprivileged. For AI agents and other non-human identities, blast radius is shaped by tool permissions, system reach, delegation chains, and how quickly access can be revoked.
What's in the full article
SailPoint's full blog covers the operational detail this post intentionally leaves for the source:
- How the author maps AI agents to IT general controls across identity governance, change management, and SDLC
- The Agentic Development Lifecycle control questions the article proposes for audit and compliance teams
- Examples of how indirect agent access can exceed the permissions of the human requester
- The article's closing audit prompt for inventorying every non-human identity and AI agent in the environment
Deepen your knowledge
AI agent governance, identity lifecycle control, and access review design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is extending IAM into agentic systems, it is worth exploring.
Published by the NHIMG editorial team on 2026-05-07.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org