TL;DR: AI agents are moving from feature to actor inside business applications, and Delinea argues that access governance must expand to treat them as governed identities, while many organisations still run access reviews and segregation of duties manually. The assumption that identity can be reviewed after the fact is breaking as agents take actions at runtime and often with elevated access.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Delinea's blog post: AI agents in business apps should be governed as identities because current review and control models lag runtime behaviour in Delinea's 2026 view of application access governance.
Why it matters: It matters because IAM, IGA, and PAM teams will need to extend governance, least privilege, and review processes to machine actors operating inside business applications, not just human users.
By the numbers:
- Today, non-human identities account for about 60% of identities in a typical organization.
Context
AI agents are now being embedded directly into business applications, where they can take actions on behalf of users rather than just recommend them. That changes application access governance because the control problem is no longer limited to human approvals and periodic reviews.
Delinea’s argument is that most organisations have not yet built formal oversight for AI in general, let alone for agents inside ERP, CRM, or HCM systems. The governance question is becoming how to assign least privilege, review access, and maintain accountability when the actor is no longer purely human.
The article frames this as a 2026 operating shift for identity teams: application access governance, IAM, IGA, and PAM all need to converge around governed machine actors as well as people.
Key questions
Q: What breaks when AI agents are given broad enterprise access without tight governance?
A: Broad access turns AI agents into high-speed execution paths that can move data, spend money, modify records, or delete assets before operators can intervene. The failure is not only misuse by an attacker. The system itself can exceed intended scope during normal task completion, so the real control problem is bounding authority before runtime action begins.
Q: Why do AI agents increase risk in ERP and finance systems?
A: They increase risk because they can touch high-value records, make decisions from context, and operate with access that is often broader than a person would need. In ERP and finance, that can turn one over-privileged identity into a wide blast radius across payments, reconciliations, and supplier data.
Q: How can teams tell whether application access governance is keeping up with agents?
A: A useful signal is whether every agent has explicit ownership, a defined permission scope, and an automated review path. If agents are still managed through manual exceptions, ad hoc approvals, or unclear accountability, governance is lagging the actual access model.
Q: Should organisations treat AI agents like human users in IAM?
A: No. Human IAM assumes a person logs in, works within a session, and can be reviewed later as a stable identity holder. Agents can act at machine speed, across multiple systems, and with changing runtime context, so they need identity governance built around execution and delegation rather than human authentication patterns.
Technical breakdown
Why AI agents break the business application access model
Traditional application access governance assumes the identity requesting or using access is a person whose role, approval chain, and review cadence can be assessed offline. AI agents break that model when they execute inside business applications, take actions on behalf of users, and may do so with broader access than the task requires. The result is a mismatch between static entitlements and dynamic runtime behaviour. In governance terms, the issue is not just automation volume. It is that the subject of control is now an identity-like actor whose access scope can drift away from the human role that triggered it.
Practical implication: teams need to govern the agent as the access subject, not as a hidden feature attached to a user account.
Why manual SoD and access reviews lag agent-driven operations
Segregation of Duties and user access reviews were built for controlled, periodic assessment of stable entitlements. Delinea notes that many organisations still run these controls manually, even while business applications increasingly automate workflows. That creates a timing problem. If an agent can take action faster than reviewers can inspect, certify, or revoke, the review control becomes a retrospective record rather than a governance barrier. The real weakness is not only scale. It is that manual control paths cannot keep up with continuous, machine-paced access decisions inside business applications.
Practical implication: automation has to move into access review, SoD analysis, and provisioning before agent permissions become normalised.
Least privilege for AI agents inside ERP, CRM, and HCM systems
The article’s security position is that AI agents should follow the same least privilege and zero trust principles applied to human users, but with narrower task-scoped permissions and human oversight. In practice, that means agent access inside business applications should be limited to the specific workflow scope needed for the task, not inherited broadly from the surrounding user context. This matters most in ERP, CRM, and HCM environments, where an over-permissioned agent can move from helpful automation to enterprise risk very quickly. The control challenge is defining permission boundaries for a non-human actor that may operate across multiple business functions.
Practical implication: define task-scoped permissions for agents and separate them from the broader access of the human they assist.
Threat narrative
Attacker objective: The objective is to exploit over-permissioned agent access inside business applications to cause fraud, unauthorized actions, or broader enterprise risk.
- Entry occurs when an AI agent is embedded into a business application and granted access to act on behalf of a user.
- Escalation follows when the agent receives elevated permissions that exceed the specific workflow scope it actually needs.
- Impact occurs when excessive agent permissions translate into material business risk across ERP, CRM, or HCM processes.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Access governance must expand from user-centric review to actor-centric governance: business applications are no longer only serving people, because AI agents can now initiate actions inside the application boundary. That means the governance subject is shifting from the human account alone to the combined human-plus-agent execution model. The implication is that application access governance programmes need to treat agents as first-class identities, not as workflow decorations.
The review model is breaking because runtime access is outrunning retrospective control: access reviews and SoD checks assume a stable entitlement surface that lasts long enough to be evaluated. AI agents can exercise access at machine speed, which collapses the usefulness of periodic manual review as a primary control. The implication is that governance has to move upstream into issuance, scope definition, and runtime enforcement.
Least privilege for AI agents is becoming a business application design issue, not just an IAM policy issue: when agents operate inside ERP, CRM, and HCM systems, the permission boundary is set by workflow design as much as by directory policy. That makes application owners part of the governance problem, not just security administrators. The implication is that enterprise governance has to be shared across app teams, IAM, IGA, and PAM.
Automation will not solve governance unless it is applied to the control plane itself: Delinea’s broader point is that organisations still perform SoD analysis and access reviews manually, even in highly automated environments. That is a structural mismatch, because the volume and velocity of identities now include machine actors. The implication is that modern access governance has to be automated enough to keep pace with both human and non-human identity lifecycles.
Identity lifecycle thinking now has to cover agents inside business applications: lifecycle governance was built to provision, review, and remove access over time, but AI agents introduce a new class of actor that may be created, adjusted, and retired far faster than human processes expect. The implication is that JML, recertification, and offboarding logic must extend into business application control models or they will miss the real actor boundary.
From our research library:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Application access governance is becoming an actor model problem: the control stack can no longer assume that the identity behind a business application action is always a person. Once AI agents can execute inside the application itself, governance has to follow the actor rather than the interface. That shifts design pressure toward explicit ownership, scoped permissions, and runtime enforcement.
Agent governance will expose the weakest handoff between IAM and app teams: business applications often sit outside the daily control plane of central IAM, which is why access reviews and SoD checks are still often manual. As agents spread into ERP, CRM, and HCM environments, the most fragile point will be the boundary between identity policy and application execution.
Identity lifecycle now includes non-human workers inside business applications: when agents are created to automate repetitive workflows, they need the same lifecycle discipline as other non-human identities. Without that, organisations will keep discovering agents too late, reviewing them too slowly, and offboarding them too casually.
For practitioners
- Map every in-application AI agent Inventory where agents reside across business applications, identity providers, and security tooling so no agent remains invisible to governance workflows.
- Classify agents as governed identities Treat each agent like a privileged user in the access model, with explicit ownership, scope, and review cadence instead of assuming it inherits a human user role.
- Constrain permissions to task scope Limit each agent to the narrowest permissions needed for the specific business workflow it performs, especially in ERP, CRM, and HCM environments.
- Automate SoD and access reviews Move segregation of duties analysis and access recertification into automated controls so machine-paced changes do not outgrow manual review cycles.
- Preserve human accountability for autonomous actions Require human oversight for agent decisions that can materially change data, payments, or approvals, and make ownership explicit before deployment.
Key takeaways
- AI agents are changing application access governance by acting inside business applications, not just supporting users from the side.
- The practical gap is between machine-speed access and manual controls such as SoD and access reviews, which were built for slower human workflows.
- Governance now has to treat agents as identities with scoped permissions, ownership, and runtime oversight if organisations want to limit business risk.
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, OWASP Agentic AI 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-05 — Overprivileged NHI | The article centres on agents receiving elevated access in business applications. |
| NHI-10 — Human Use of NHI | The post covers humans assigning and overseeing non-human agents as governed identities. | |
| Recommendation — Constrain agent permissions to the minimum task scope and review any default elevation immediately. Separate human account controls from agent permissions and require explicit oversight for delegated actions. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The core risk is agents operating with excessive privileges inside business applications. |
| Recommendation — Apply ASI03 to detect where agent privileges exceed the workflow they are supposed to execute. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about entitlement scope and access governance for agents. |
| Recommendation — Use PR.AA-05 to enforce scoped authorizations and periodic entitlement review for agents. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | Over-permissioned agents can be abused to reach privileged actions that drive business impact. |
| Recommendation — Map agent abuse paths to credential access and impact tactics to prioritise monitoring and containment. | ||
Key terms
- Application-Aware Access Governance: Application-Aware Access Governance is identity governance that understands the rules, data, and workflows of a specific business system. It goes beyond generic provisioning by connecting entitlements to process context, transaction behaviour, and cross-system evidence needed for defensible decisions.
- Governed Identity Path: An access route that is tied to a known identity, a documented owner, and a reviewable lifecycle. For AI agents and other NHIs, this means the organisation can trace authentication, approve privileges, and revoke access through established governance processes.
- Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
- Task-scoped Permission: Task-scoped permission is access granted only for a specific job, action, or workflow step. It limits what a user, service, or agent can do to the minimum needed for that task, often with time and context boundaries. In identity systems, it reduces standing access and narrows misuse if credentials are exposed.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org