TL;DR: AI agent security treats agent access, visibility, and governance as an identity problem rather than a generic AI operations issue, with NHI and access-graph controls positioned as the organising layer, according to Veza. The practical takeaway is that IAM teams must distinguish agent behaviour from human workflows, because delegated access and unmanaged tool use quickly outgrow traditional review cycles.
At a glance
What this is: Veza argues that AI agent security should be treated as an access governance issue, not just an AI operations issue, because delegated permissions and visibility gaps quickly outgrow human-centric review models.
Why it matters: IAM and NHI teams need to separate agent identity from human identity workflows so that access decisions, monitoring, and lifecycle controls match the way agents actually operate.
Context
AI agent security becomes an identity governance problem when a system can act on behalf of a business process while also selecting tools and access paths that humans did not pre-approve in detail. Traditional IAM models assume a person, a service, or a workflow can be reviewed after the fact with stable boundaries. That assumption weakens when an agent can move across data, applications, and delegated permissions during execution.
Veza's framing places the control question around visibility, access governance, and lifecycle management for agent behaviour. For identity teams, that means the relevant debate is not whether AI exists in the environment, but whether the organisation can explain, constrain, and revoke agent access with the same discipline used for other non-human identities. In practice, that shifts the programme from workflow oversight to identity control.
The article is typical of the current market conversation: AI agent access is being pulled into the same governance lane as service accounts, tokens, and other non-human identities. The challenge is not the label, but the boundary between delegated automation and independent runtime action.
Key questions
Q: How should security teams govern AI agents without creating a manual review bottleneck?
A: Use policy, automation, and class-based controls so agents are provisioned through deployment pipelines, not ticket queues. Every agent should have a unique identity, a named owner, and a bounded scope. Human review should focus on exceptions, anomalous behavior, and changes in business context, not on approving each routine action.
Q: Why do AI agents create more risk than traditional automation?
A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.
Q: What breaks when organisations cannot see an agent's delegated permissions?
A: When delegated permissions are invisible, teams lose the ability to explain who granted access, how broad it is, and when it should end. That undermines containment, incident triage, and offboarding because no one can prove the agent's actual authority.
Q: How can IAM teams decide when an AI agent needs fresh governance approval?
A: Fresh approval is needed whenever the agent's purpose, data scope, connected tools, or downstream privileges change. Those changes alter the identity boundary, so the original authorisation no longer matches the agent's real operational risk.
Technical breakdown
Why AI agent access does not fit human review cycles
AI agents can request, combine, and use permissions during runtime in ways that do not map neatly to human joiner-mover-leaver processes. A human access review assumes a relatively stable subject, a known business role, and a reviewable entitlement set. An agent can instead accumulate access through delegation, tool chaining, or temporary execution context, which makes post-hoc certification too slow and too coarse to catch misuse before impact.
Practical implication: Treat agent access as a runtime governance problem, not a periodic review problem.
Access visibility for AI agents and NHI governance
Visibility for agents is not just inventory. It is the ability to see which identities, scopes, tools, and downstream systems an agent can touch at any moment, including inherited or indirectly granted permissions. In NHI governance terms, the central issue is provenance of access: who or what granted it, how long it persists, and whether it can be explained after the fact. Without that, security teams lose the ability to distinguish intentional automation from uncontrolled delegation.
Practical implication: Build access graphs that show delegated paths, inherited scopes, and revocation points for every agent identity.
Lifecycle management for agentic AI identities
Lifecycle control is where agent identity governance becomes operationally real. Creation, approval, scoping, monitoring, and offboarding have to follow the actual agent, not just the software project that deployed it. If an agent can be reused, repurposed, or connected to new tools without a fresh governance decision, the organisation inherits access persistence that looks small at first and becomes difficult to unwind later. That is an identity lifecycle failure, not a model issue.
Practical implication: Bind each agent to a governed lifecycle record that can be retired, re-scoped, or revoked when its purpose changes.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
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 agent security is now an identity governance problem, not a side effect of AI adoption. Veza's framing is directionally correct because the security issue is the access path, not the model output. Once an agent can act across tools and data sources, IAM has to treat it as a governed identity subject with explicit scope and accountability. The practitioner conclusion is that AI agents belong in the same governance conversation as other non-human identities, but with tighter runtime oversight.
Access visibility is the named control gap: organisations cannot govern what they cannot explain. The practical failure mode is not just shadow AI, but shadow permission inheritance, where an agent inherits access through integrations, tokens, or delegated tooling that nobody can reconstruct cleanly. That makes review, containment, and incident triage much harder than in human-centric IAM. The practitioner conclusion is to prioritise access traceability over cosmetic inventory.
Lifecycle control breaks when agent identity is managed like application deployment instead of identity issuance. The assumption that a deployed agent remains bound to the same purpose, tools, and permissions is too weak for real operations. Once the agent is repurposed or reused, prior authorisation decisions may no longer fit its actual behaviour. The practitioner conclusion is that offboarding and re-scoping must be first-class governance events for every agent identity.
Agentic AI governance will converge with NHI governance faster than many programmes expect. The same discipline used for service accounts, API keys, and workload identity now has to absorb independently acting software subjects that can initiate access rather than merely consume it. That convergence does not eliminate the need for AI-specific oversight, but it does mean identity teams cannot wait for a separate governance model to mature. The practitioner conclusion is to extend NHI controls now and refine them for runtime autonomy as needed.
Identity blast radius is the right concept for this category. The article points toward a world where the important question is not whether an agent exists, but how far its access can spread if its purpose or behaviour changes. That is a governance and architecture issue, not a feature toggle. The practitioner conclusion is to measure and constrain the blast radius of every agentic identity before scale makes the problem systemic.
From our research library:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
- Read next: Agentic AI Identity Guide
What this signals
Agentic access governance will behave less like application onboarding and more like privileged identity management. As AI systems start acting on behalf of business workflows, programme owners will need a control plane that can show who granted access, where it flows, and how it is revoked. That is a stronger requirement than simple AI inventory.
Access review cycles will become less useful unless they are paired with issuance-time controls. A review can only attest to access that still exists, so organisations need stronger scoping and revocation decisions at the point of grant. The governance burden shifts from periodic certification to continuous boundary enforcement.
For practitioners
- Define agent identity as a governed subject Assign every AI agent a unique identity record, owner, and purpose statement so access can be traced back to a business function rather than a codebase.
- Map delegated access paths end to end Document which tools, data sources, and downstream services an agent can reach through direct grants, inherited scopes, or linked credentials.
- Separate agent review from human access review Create a governance workflow that evaluates runtime agent permissions, not just periodic user certifications, because agent access can change faster than review cadences.
- Tie offboarding to the agent lifecycle Revoke permissions when an agent is retired, repurposed, or disconnected from its original use case, and record the revocation as an identity event.
- Set blast-radius limits for high-value systems Restrict the systems an agent can reach by default, then expand only through explicit approval and monitored delegation for each new use case.
Key takeaways
- AI agent security is being reframed as identity governance because delegated access, lifecycle control, and visibility matter more than treating agents as generic automation.
- The main programme gap is that human-style review processes do not keep pace with agent behaviour once tools, scopes, and downstream permissions can change at runtime.
- Identity teams should move governance closer to issuance and revocation so that agent access is explainable, bounded, and removable when purpose changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on governing how agents authenticate and use delegated access. |
| NHI-05 — Overprivileged NHI | The core risk is agent access that grows beyond its intended business purpose. | |
| NHI-01 — Improper Offboarding | The article stresses lifecycle control, including retiring or re-scoping agent identities. | |
| Recommendation — Apply NHI-04 to ensure agent authentication is bound to explicit ownership and scoped access. Use NHI-05 to limit each agent to the smallest permission set its workflow actually requires. Apply NHI-01 to revoke agent access when the identity is retired, repurposed, or disconnected. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The topic is fundamentally about governing permissions and authorisations for agent identities. |
| Recommendation — Use PR.AA-05 to review and constrain agent entitlements against declared business purpose. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Agent overreach and delegated access can create paths to wider access across systems. |
| Recommendation — Map agent privilege drift to TA0006 and TA0008 to prioritise controls around credential use and reach. | ||
Key terms
- Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 25, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org