AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: Proofpoint’s 2026 outlook says AI agents, cloud authentication abuse, and AI-assisted phishing will drive the next wave of identity and data exposure risks.

Why it matters: For IAM and NHI practitioners, the message is that identity governance now has to cover AI systems, partner access, and over-permissioned collaboration data, not just human users.

By the numbers:

• 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.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.

👉 Read Proofpoint's 2026 cybersecurity predictions on AI agents and cloud identity risk

Context

Generative and agentic AI are turning access governance into a moving target. When copilots can retrieve, summarise, and expose information across collaboration platforms, the control problem shifts from simple authentication to ongoing authorisation, data classification, and trust management across human and machine identities.

That matters because the article’s central risk is not only phishing or malware. It is the combination of over-permissioned content stores, AI systems that behave like peer actors, and blind spots in third-party AI usage that can bypass traditional IAM assumptions. In practice, this is where NHI governance and human identity governance start to converge.

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 over-permissioned collaboration stores increase AI data leak risk?

A: Over-permissioned collaboration stores make it easy for AI systems to surface content that should never have been broadly reachable in the first place. If the agent can index stale folders, unclassified documents, or legacy access rules, it can expose sensitive material while appearing to operate normally. The access problem exists before the prompt abuse begins.

Q: What breaks when third-party AI use is invisible to the security team?

A: When third-party AI use is invisible, organisations lose control over where sensitive data is processed, retained, and exposed. That creates blind spots in logging, contractual governance, and access review, especially if the supplier’s AI systems can touch regulated or confidential information. Security teams need disclosure, inventory, and data-flow mapping to close that gap.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

Why AI agents behave like high-risk identities

An AI agent is not just a tool that executes a task. In practice, it can retrieve data, choose actions, and expose information in ways that make its runtime behaviour closer to an identity than a static application component. That changes the control model because the agent’s privileges, data scope, and decision boundaries must be governed continuously. If the agent can access SharePoint, SaaS APIs, or connected workflows, then over-permissioned content becomes an exposure path rather than a storage issue. Practical implication: treat agent permissions, data scope, and audit trails as identity controls, not application configuration.

Practical implication: govern agent privileges and data reach as first-class identity controls.

Why cloud authentication pressure spills into NHI governance

The cloud authentication comments in the article point to a broader pattern: attackers exploit the same identity primitives that enterprises use to automate work. OAuth applications, delegated access, device-code abuse, and legitimate cloud services all create paths that look normal to monitoring tools while supporting attacker persistence or lateral movement. This is an NHI problem as much as a cloud problem because service access, tokens, and delegated applications are identities with lifecycle, privilege, and revocation requirements. Practical implication: align cloud auth monitoring with secret, token, and delegated-access governance.

Practical implication: connect cloud auth monitoring to token and delegated-access lifecycle controls.

Threat narrative

Attacker objective: The attacker aims to obtain durable access and force AI or cloud systems to disclose sensitive data while blending into normal enterprise activity.

1. Entry occurs when attackers use AI-generated phishing, device-code phishing, or legitimate cloud services to reach a trusted user or workload.
2. Escalation follows when stolen tokens, OAuth applications, or over-permissioned agent access are used to move beyond the initial foothold.
3. Impact occurs when sensitive data, persistent access, or misleading AI output is exposed across collaboration, cloud, or security workflows.

NHI Mgmt Group analysis

AI agents are becoming non-human identities before most organisations are ready to govern them. The article’s core insight is that copilots and autonomous systems are no longer passive software features. They make decisions, access data, and surface information in ways that require identity-style controls, not just application approval. That aligns directly with the governance gap highlighted in NHI work: systems with real access need lifecycle, privilege, and accountability boundaries. Practitioners should treat AI agents as governed identities with reviewable scope, not as convenience layers on top of existing IAM.

Prompt paths are the next governance boundary because they turn language into an access-control problem. When attackers can influence what an agent retrieves or reveals, the failure mode is not simply malware delivery. It is unauthorised disclosure through legitimate system behaviour, especially where collaboration stores remain over-permissioned and poorly classified. That creates a named concept worth tracking: prompt-path exposure, meaning adversarial input routes that cause an agent to reveal data it should not. Practitioners should model prompt abuse as an identity and data-governance issue, not only an AI safety issue.

Cloud identity abuse and AI agent abuse are converging on the same weak point: standing access. Device-code phishing, OAuth manipulation, and legitimate cloud service abuse all depend on credentials or delegated trust that outlive the moment they were needed. This is why identity programmes cannot separate human compromise from machine compromise in practice. The control failure is the same: persistent privilege creates durable attack paths. Practitioners should unify token, delegated-app, and workload identity governance under a single access-risk model.

Visibility into third-party AI use will become a board-level governance issue, not just a security hygiene problem. The article flags a real blind spot where organisations do not know where AI is embedded across vendors and partners. That matters because hidden AI usage can bypass approved data-handling rules, audit expectations, and retention controls. The broader lesson is that the security perimeter now includes AI-enabled suppliers and their data flows. Practitioners should extend governance review beyond internal deployment to the full ecosystem of AI-enabled services.

The market is moving toward identity controls that span humans, machines, and AI systems together. The article’s through-line is visibility, adaptability, and judgment, but the practical translation is tighter identity governance across every actor that can touch data or make decisions. That validates a shift already underway in NHI and IAM programmes: access control must follow the behaviour of the entity, not the label attached to it. Practitioners should expect identity governance to become more continuous, less static, and more tied to runtime behaviour.

What this signals

Prompt-path exposure: security teams need to start thinking about AI disclosure risk as an access-control problem, not only a model-risk problem. Once an agent can retrieve and summarise enterprise data, hostile prompting can turn ordinary search behaviour into unauthorised disclosure. The practical response is to align runtime authorisation, data classification, and monitoring around the agent’s actual reach, not the label on the application.

The strongest signal for 2026 is that identity governance will have to span human users, service accounts, tokens, and AI systems in one operating model. That convergence will reward organisations that can tie approval, revocation, and audit to behaviour rather than static entitlement lists. The broader standard-setter view is already moving in this direction through the NIST AI Risk Management Framework and related identity guidance.

For practitioners, the near-term priority is not to wait for a perfect AI policy. It is to identify where AI is already touching sensitive data, then reduce standing access and hidden delegation across those paths. That shift is especially urgent where cloud authentication, collaboration platforms, and third-party AI services intersect.

For practitioners

• Map AI agents to governed identity records Inventory each AI system that can read, write, or reveal enterprise data, then assign ownership, purpose, privilege scope, and review cadence as you would for a high-risk service account. Use the same lifecycle discipline for AI agents that you apply to other non-human identities.
• Test data exposure under hostile prompts Run red-team style evaluations against retrieval and summarisation workflows to see whether agents can surface unclassified, stale, or over-permissioned content when prompted adversarially. Prioritise collaboration platforms and document stores where access rules are already loose.
• Unify token and delegated-access governance Bring OAuth applications, device-code flows, API tokens, and workload credentials into one access-risk view so that abuse patterns are visible across both human and machine entry points. Pair that inventory with revocation playbooks and short-lived access where possible.
• Extend visibility to third-party AI usage Require suppliers and partners to disclose where AI is embedded in services that process your data, then map those dependencies to data classification, retention, and logging obligations. That is the only way to close blind spots created outside your direct IAM boundary.
• Review cloud authentication paths for AI-assisted abuse Audit device-code, OAuth, and remote-management flows for persistence and lateral movement opportunities that could be accelerated by AI-driven phishing or automation. Tie those findings to NHI and secret-management controls rather than treating them as isolated cloud events.

Key takeaways

• AI agents are emerging as governed identities, which means access scope and lifecycle controls matter as much as model output quality.
• The biggest practical risk is not AI itself, but the way over-permissioned data stores and delegated access let AI systems expose information beyond intended boundaries.
• Identity teams should unify NHI, cloud auth, and third-party AI oversight before agentic systems become a routine source of unreviewed disclosure.

Key terms

• Prompt Path Exposure: A prompt path exposure happens when an AI system is coaxed into revealing or acting on information it should not have surfaced. The risk comes from the agent’s retrieval and response behaviour, which can turn normal access into an unauthorised disclosure channel when controls are too broad or poorly classified.
• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• 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.

What's in the full article

Proofpoint's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific threat scenarios behind AI-driven phishing, prompt abuse, and cloud authentication manipulation.
• Expert commentary on how defenders can distinguish human compromise from AI-assisted abuse in live environments.
• The article's broader predictions for 2026 across espionage, cloud security, and detection engineering.
• Practical examples of how attackers are already using legitimate services and AI-generated content to bypass controls.

👉 Proofpoint's full analysis adds the expert predictions and threat examples behind the 2026 outlook.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to emerging AI and automation risks.