Enterprise AI agent adoption is broad, but governance lags

At a glance

What this is: This is an analysis of how enterprises are adopting AI agents and where the real implementation friction sits, with the key finding that uptake is broad but governance and operating-model maturity remain shallow.

Why it matters: It matters because AI agents are becoming identity-bearing systems in production, which forces IAM, PAM, and NHI teams to govern access, delegation, audit, and accountability differently from traditional automation.

By the numbers:

• According to Gartner, by 2028, one-third of all enterprise software applications will include some form of agentic AI up from less than 1% in 2024.
• Among adopters, 66% report higher productivity, 57% cost savings, and 54% better customer experience.
• AI agents could resolve 80% of common customer service issues by 2029, reducing operational costs by nearly 30%.

👉 Read Akto's analysis of the current state of AI agent adoption in enterprises

Context

AI agent adoption is rising faster than most enterprises can define, govern, and audit it. In practical terms, these systems are moving from chat interfaces into workflow execution, which means they inherit access rights, data exposure, and decision authority that traditional automation models were not designed to manage. That creates a direct governance challenge for IAM, PAM, and NHI programmes, especially where agents touch sensitive systems or regulated processes.

The article’s core point is that enterprises want the productivity gains of agentic AI, but most are still layering agents onto old operating models. That is a familiar pattern in security: technical adoption outruns control design. For identity teams, the issue is not only whether the model can act, but who or what is authorised to act, under what scope, and with what traceability.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they often inherit delegated credentials, operate across multiple systems, and keep acting after the initial approval moment has passed. Human session assumptions, periodic reviews, and static privilege models do not reflect that behaviour. The result is a governance gap between what was granted and what the agent can actually do.

Q: What do organisations get wrong when scaling agentic AI?

A: They often treat agents as workflow enhancements instead of governed actors with identity, privilege, and audit requirements. That leads to hidden overreach, weak accountability, and poor rollback options. The common mistake is scaling usage before establishing control boundaries, especially for systems that touch customer, employee, or financial data.

Q: When should organisations pause agent deployment and tighten controls first?

A: Organisations should pause when an agent can reach sensitive systems, make decisions with external impact, or operate without reliable logging and human override. Those are the conditions where productivity gains can quickly become governance failures. If access cannot be traced and revoked cleanly, the rollout is ahead of the control model.

Technical breakdown

What makes an AI agent different from a chatbot or workflow bot?

An AI agent is goal-driven rather than purely task-driven. It can perceive context, choose actions, call tools, and adjust its path as conditions change. That makes it more than a scripted automation or a conversational interface. In enterprise settings, this distinction matters because the agent may hold or request credentials, inherit delegated permissions, and operate across systems with limited human supervision. Once an LLM is paired with tools and orchestration, the security boundary shifts from model output to runtime authority.

Practical implication: treat agents as governed runtime actors, not just application features.

Why do embedded agents change identity and access assumptions?

When agents live inside Salesforce, Workday, ServiceNow, or similar systems, they stop being isolated experiments and start operating inside established identity, access, and logging boundaries. That creates a new problem: the agent may execute legitimate actions using human-like context without being a human. IAM and PAM controls must therefore distinguish user identity, delegated agent identity, and service-to-service access. Without that separation, audit trails become ambiguous and privilege review becomes unreliable.

Practical implication: define and register agent identities separately from human accounts and service accounts.

Why does multi-agent orchestration create governance debt?

Agent fleets increase coordination complexity because each agent may have its own tool access, memory, and task scope, while the orchestration layer passes state between them. That can multiply trust relationships across departments and systems. The security risk is not only misuse of a single agent, but hidden privilege transfer between agents that were not designed for end-to-end accountability. This is where NHI governance and AI governance overlap: delegated access, traceability, and revocation become shared control problems.

Practical implication: inventory inter-agent trust paths before scaling orchestration across business functions.

Threat narrative

Attacker objective: The attacker objective is to exploit the agent’s delegated access and operational trust to reach systems, data, or actions that should not be available under the intended scope.

1. Entry occurs when enterprises connect AI agents to internal systems, APIs, and business workflows without a mature identity model for the new runtime actor.
2. Escalation happens when the agent inherits broad delegated permissions or tool access that exceeds the minimum scope needed for the task.
3. Impact emerges when the agent can access inappropriate data, trigger unauthorised actions, or make decisions that outpace human review and auditability.

NHI Mgmt Group analysis

AI agent governance is now an identity problem, not just an AI problem. Once agents can act on behalf of an organisation, they become runtime identities that need scoping, accountability, and revocation. Traditional application controls do not answer who authorised the action, which permissions were inherited, or whether the actor was human, automated, or agentic. Practitioners should treat agent governance as part of identity architecture, not a separate AI pilot stream.

Operational value will continue to outpace governance maturity until enterprises separate agent identity from human identity. The article shows strong intent and growing deployment, but trust and maturity are still uneven. That is exactly where identity programmes need to intervene: every agent should have explicit registration, bounded permissions, and a traceable ownership model. The practitioner conclusion is straightforward: if the agent cannot be named, scoped, and reviewed, it cannot be governed.

Delegated access drift is the named concept this market is creating. Enterprises are embedding agents inside live systems faster than they are defining how delegated authority should expire, be reviewed, or be constrained. That drift is not just technical debt. It becomes governance debt when multiple teams assume somebody else owns review, logging, and rollback. The practitioner conclusion is to make delegated access a first-class control surface in both IAM and NHI programmes.

The most mature organisations will stop measuring agent adoption and start measuring agent control boundaries. Productivity gains are easy to report, but they do not tell you whether an agent stayed within its intended scope. The meaningful metrics are access breadth, policy exceptions, audit completeness, and the proportion of agent actions that can be traced back to a clear human owner. The practitioner conclusion is to shift reporting from usage to control assurance.

AI agent rollout is widening the overlap between NHI governance and AI governance. The same questions recur across both domains: what is the identity, what can it do, how is it authenticated, and how is it revoked. That overlap means identity teams should own the runtime control model while AI teams own model behaviour and use-case risk. The practitioner conclusion is to align those functions before adoption outpaces oversight.

What this signals

AI agent adoption will keep climbing, but the control baseline is now the differentiator. The practical programme question is whether identity teams can register agent identities, bound their privilege, and produce evidence when an agent crosses scope. That is where governance starts to look less like policy writing and more like runtime assurance.

Delegated access drift: once agent permissions are allowed to expand implicitly across workflows, review processes lose their value because no one can tell where human delegation ended and autonomous action began. The result is a measurable gap between adoption and assurance, which is why agent rollout should be tied to audit coverage, revocation speed, and exception management.

For IAM and NHI teams, the next planning cycle should assume agent identity will sit alongside human identity rather than outside it. That means updating access models, ownership records, and logging standards now, while the architecture is still flexible enough to absorb the change.

For practitioners

• Define a separate agent identity model Create explicit identity types for human users, service accounts, and AI agents. Record owner, purpose, allowed systems, and revocation path for each agent identity so review does not collapse into a generic automation inventory.
• Bound delegated permissions by use case Limit each agent to the smallest tool and data scope needed for its intended workflow. Use just-in-time access where possible, and require approval for privilege expansion that crosses systems or data classes.
• Instrument audit trails for agent actions Log the prompt, tool call, identity, target system, and downstream effect for every agent action that changes state or exposes data. Without that evidence, compliance and incident review will both fail.
• Review inter-agent trust paths Map how state and permissions move between agents in orchestration layers. This exposes hidden delegation chains that can create over-privilege, unclear accountability, or uncontrolled propagation across business functions.
• Tie rollout decisions to control maturity Do not expand agent deployment faster than identity, logging, rollback, and human-in-the-loop controls can keep pace. Use a control checklist for each new workflow instead of treating adoption as a platform-only decision.

Key takeaways

• AI agents are now behaving like identity-bearing runtime actors, which makes access governance a core security requirement rather than an optional control layer.
• The evidence shows strong adoption intent but weak control maturity, with agent overreach already visible in real enterprise environments.
• Organisations should define agent identity, bound delegated access, and tighten auditability before expanding deployment across sensitive workflows.

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 drift: The point at which a valid token or OAuth grant begins being used in ways that no longer match the original user intent. In practice, this shows up as mailbox reconnaissance, inbox-rule changes, or data access that follows the sign-in event but does not fit normal user behaviour.
• Runtime actor: A runtime actor is a system that makes operational decisions while it is executing, rather than only following a fixed script or scheduled workflow. For AI agents, that means access control and monitoring must account for live decision-making, not just pre-approved configuration.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

• The specific enterprise use cases and adoption archetypes the vendor observed across back-office, embedded, and multi-agent deployments
• The Gartner and PwC context in the original narrative, including how the author interprets productivity gains and execution friction
• The vendor's framing of trust, governance, and operating-model redesign as AI adoption scales
• The article's supporting examples and commentary on where enterprises are currently stalling in production

👉 Akto's full post covers enterprise use cases, adoption patterns, and the governance friction slowing scale.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that helps practitioners build control models for emerging runtime actors. It is suited to identity, security, and governance teams that need to align access, accountability, and auditability.