Identity governance has spent years chasing the human entitlement problem, and it still loses ground every quarter. So when a survey suggests that 84% of organisations using AI in critical business applications have reported an AI-related issue in the past year, the number deserves attention from anyone running privileged access management. The Delinea Fastpath findings, reported by The Manila Times, describe an estate where AI has been adopted faster than the controls around it.
The problem: AI adoption outpaces access discipline
AI in a business application is rarely a single model behind a chat window. It is a pipeline of service accounts, API keys, data connectors and orchestration tools, each holding credentials that reach into production systems. Each integration is a privilege grant. Multiply that across departments experimenting independently, and the privileged account estate grows without an owner, a register or a review cycle.
The AI-related issues organisations reported in the survey are unlikely to be confined to model accuracy or hallucination. In practice, the failures that bite are access failures: an integration with credentials broader than its purpose, a connector left enabled after a pilot ends, an agent with write access to a system it only needed to read. These are unglamorous problems, and they are exactly the ones privileged access management exists to solve.
Why PAM controls keep getting bypassed for AI projects
The first reason is velocity. AI pilots are often run outside the standard change process, with credentials issued by whoever controls the target system rather than through a vault. By the time the pilot becomes a production dependency, the shortcut is embedded in the architecture and removing it looks like a risk rather than a fix.
The second is identity ambiguity. It is often unclear whether an AI integration should be treated as an application, a workload identity or an emerging agent identity. Without a clear classification, it falls outside entitlement reviews, and the session management controls that apply to administrative accounts never get applied to it.
The third is measurement. Most organisations cannot state how many non-human identities exist across their AI estate, let alone which carry privileged access. A survey finding that four out of five AI adopters hit a related issue is consistent with that blind spot: risk accumulates quietly until an integration misbehaves or an audit asks a question nobody can answer.
What a defensible AI access posture looks like
Start with discovery. Credentials issued to AI pipelines and connectors should be enumerated, attributed to an owner, and classified by privilege level. Secrets stored in code repositories, notebook environments or CI variables should be rotated and moved into a managed vault, because those locations are exactly where attackers look first.
Then apply least privilege to the integration, not the project. An AI service that reads a data warehouse does not need write access to it. Scoping by function rather than by convenience reduces the blast radius when a key leaks or a model is manipulated into unexpected behaviour. Short-lived credentials and automatic rotation should be the default for anything machine-driven.
Finally, put AI integrations inside the existing governance rhythm. That means entitlement reviews that include non-human identities, session records that capture what an integration actually did, and a documented decommissioning step so retired pilots do not leave live credentials behind. The Delinea data is a warning about adoption speed, and privileged access management is the discipline that lets organisations keep the speed while closing the gap.