AI agent governance in business apps exposes gaps in IAM controls

At a glance

What this is: This is Delinea’s analysis of AI agents inside business applications and the governance gaps they create when agents can act with broad access across ERP, CRM and finance workflows.

Why it matters: It matters because IAM and governance teams must treat AI agents as identities with their own access, audit and lifecycle requirements, not as ordinary automation bolted onto existing human controls.

Context

AI agents in business applications are non-human identity actors that can reason, plan and take actions inside ERP, CRM and finance workflows. The identity problem is not whether they are useful, but whether the organisation can govern the access they need without importing human IAM assumptions that no longer fit.

Delinea’s examples focus on agents that read email, update purchase orders, reconcile exceptions and organise expenses. That makes the control question concrete: the agent is operating on business data, taking actions on behalf of users, and potentially crossing boundaries that were designed for people rather than software identities.

The starting point is typical of many AI adoption programmes. Business units want speed and automation first, while identity governance, auditability and lifecycle controls are added later, after access has already expanded.

Key questions

Q: What breaks when AI agents in ERP and CRM apps are not tightly governed?

A: The control failure is not just excess access, but the loss of clear authority boundaries. Agents can read data, recommend actions and update records across business workflows, so a weakly governed agent can expose information or change transactions faster than human review cycles can catch up.

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: How do security teams know if an AI agent has too much access?

A: Look for agents that can reach multiple systems without task-specific limits, use persistent tokens, or touch high-value services such as email, chat, cloud consoles, and file stores. A healthy deployment leaves a clear audit trail of what the agent can do, what it actually did, and which credentials it used.

Q: How should organisations govern accountability for AI agents in business apps?

A: They should assign each agent a unique identity, track every action back to that identity, and require human oversight for material changes. Accountability fails when agent actions are attributed only to a generic account or buried inside a shared workflow.

Technical breakdown

Why AI agents break the static automation model

AI agents are not the same as rule-based automation. A static workflow follows predefined logic, while an agent combines reasoning, memory and tools to decide what to do with the information it sees. That means the access decision is no longer just about whether a workflow may run, but about what data the agent can read, which systems it can touch, and how far its toolchain can extend. In business applications, that distinction matters because the agent may move from analysis to action in the same session, which changes the governance boundary from execution permission to decision authority.

Practical implication: model agents as identities with scoped authority, not as inert workflow steps.

Why MCP and tool access matter for agent governance

The Model Context Protocol is a bridge between the LLM and external systems such as files, APIs and infrastructure. In governance terms, it becomes part of the control surface because it determines which tools the agent can reach and under what context. If that bridge is broad, the agent can retrieve sensitive data, modify records or trigger other actions with little friction. The core risk is not simply connectivity. It is that the agent’s toolset can expand faster than the organisation’s ability to review intent, context and downstream impact.

Practical implication: inventory tool connections and constrain them to the minimum context each agent actually needs.

How business application agents create an identity supply chain problem

When native agents, third-party agents and custom agents all operate inside the same business application estate, the organisation inherits an agentic AI security supply chain. One agent may be vendor-managed, another may be built by a department, and a third may rely on weaker external controls. That mix creates uneven assurance across the same data and workflow paths. The governance challenge is not only what the agent can do, but whether the source, ownership and accountability for each agent remain visible across the application estate.

Practical implication: track agent provenance, ownership and scope as part of the application access inventory.

Threat narrative

Attacker objective: The objective is to exploit overbroad agent access to read, alter or exfiltrate business data through trusted application workflows.

1. Entry occurs when an AI agent is granted access to business application data and workflows so it can perform operational tasks.
2. Credential or authority abuse follows if the agent is given broader permissions than the task requires, including access to mailboxes, purchase orders or customer records.
3. Impact occurs when the agent exposes, modifies or misroutes sensitive business data at machine speed, with limited human review.

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.
• 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.

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

AI agents inside business apps turn identity governance into a runtime control problem: the access decision is no longer enough if the agent can reason and act inside the workflow. Existing IAM models assume a user or service account can be reviewed against a stable permission set, but an agent’s behaviour can change with context, memory and tool access. Practitioners should treat the runtime decision boundary as the real control point, not the login event.

The governance gap is not just policy lag, it is attribution lag: organisations can no longer rely on human accountability assumptions when an agent updates records or recommends actions on behalf of multiple users. Delinea’s framing shows that business applications now need action-level attribution, not just account-level visibility, because the question is who or what changed the record and under what authority. Practitioners should expect audit evidence to move from session ownership to action provenance.

Agentic AI security supply chain is the right name for the new exposure pattern: once native, third-party and custom agents coexist, assurance weakens at the seams between vendors, builders and business owners. That breaks the old assumption that application trust boundaries map cleanly to a single control owner. Practitioners should govern agent provenance and permission inheritance as first-class risks.

Least privilege remains valid, but only if it is applied to agent tool reach rather than just application login rights: the article’s examples show that an agent can be harmless at authentication and dangerous at the moment it is allowed to read mail, update orders or act on exceptions. The practical consequence is that identity teams need to review what the agent can invoke, not only what the agent can enter.

AI agents should be managed as users with shorter review cycles and clearer offboarding paths: Delinea’s guidance reinforces that agents need unique identities, lifecycle ownership and human oversight. The critical point is that shared or indistinct agent accounts hide responsibility and make later review nearly meaningless. Practitioners should make agent lifecycle control part of the business application access model.

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.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Action provenance is becoming the new identity boundary: business applications now need to tell reviewers not just who signed in, but which agent changed a record, why it did so and which tool path it used. Without that level of attribution, audit trails remain descriptive rather than governable.

Agents change the review unit from account to behaviour: traditional access reviews assume permissions remain stable long enough to certify them. AI agents can exercise and combine those permissions within a workflow, so governance has to look at tool reach, decision scope and offboarding ownership together.

Agentic AI security supply chain: once native, third-party and custom agents coexist inside the same application estate, trust breaks at the seams between builders, vendors and business owners. Programmes that do not inventory those seams will miss where accountability and control actually live.

For practitioners

• Inventory every AI agent in business applications Maintain a current register of native, third-party and custom agents, including the workflows they touch, the data they can read and the systems they can modify.
• Scope agent permissions to specific tasks Limit each agent to the narrowest mailbox, record set or application function needed for its job, and remove broad access that exists only because the agent can technically use it.
• Require action-level audit trails Log what each agent accessed, changed or recommended, and preserve the business context so reviewers can distinguish legitimate automation from unsafe behaviour.
• Assign unique identities to agents Avoid shared service accounts for multiple AI agents so ownership, revocation and review stay tied to one operational purpose.
• Keep humans in the approval path for high-risk actions Use human review for actions that change financial, procurement or customer records, especially when the agent is operating across multiple business systems.

Key takeaways

• AI agents in business applications create a governance problem because their reasoning and tool use can outpace human-paced IAM controls.
• The article frames excess access, weak attribution and poor lifecycle control as the main exposure points for ERP, CRM and finance workflows.
• Identity teams should govern agent scope, provenance and auditability as part of the application access model, not as an afterthought.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority, API access, file writes, workflow triggers, the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
• Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.
• Human-in-the-Loop (HITL): A governance pattern requiring human approval before an AI agent takes high-impact, irreversible, or out-of-scope actions. HITL is a critical control for agentic AI identity governance.

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.