The Agents Nobody Owns: AI Identities Are Quietly Becoming Your Worst Insider Risk

Key points

• AI agents spun up by employees who later leave the company keep running with full credentials intact
• Standing privileges granted during pilots rarely get downgraded after the pilot ends
• Non-human identities now outnumber human ones in most cloud environments by an order of magnitude
• Legacy joiner-mover-leaver workflows have no slot for an AI agent that never appeared in HR records
• Regulators already hold you accountable as data controller regardless of which model touched the record

Ask your IAM team which human employee authorized the AI agent currently reading your customer database. If the answer takes more than thirty seconds, you have a problem.

The rush to roll out internal AI tooling has created an identity sprawl most enterprises can't audit. Agents get spun up by developers or contractors under their own credentials. Those people move teams, or leave. The agent keeps running. That's administrative debt, and it compounds.

Our June coverage of sovereign cloud deployments found that European enterprises spent two years on data residency and largely skipped AI agent identity governance entirely. The pattern isn't regional.

Two categories of risk, both ugly

Orphaned agents. An AI service account created by an employee who no longer works at the company. The agent still has API keys, still has read access to source repositories or CRM data, and still executes on schedule. Nobody reviews its logs because nobody knows it belongs to them.

Standing privileges. Agents granted broad, persistent access, often production-tier, because scoping a least-privilege role for a non-human identity is harder than ticking the admin box. The privilege never gets downgraded after the pilot ends.

Neither is hypothetical. Non-human identities now outnumber human ones in most cloud environments by an order of magnitude, and machine identities are a leading vector in cloud-related incidents tracked by major IR firms.

Why traditional IAM misses this

Legacy joiner-mover-leaver workflows assume the identity belongs to a person who shows up in HR records. AI agents don't. They live in service principals, OAuth apps or API tokens, and increasingly in agentic frameworks that chain tool calls without any human in the loop for individual actions.

If an agent goes rogue, through hallucinated SQL, prompt injection, or plain misconfiguration, your incident responders need an owner to call. "The team that built it" is not an owner.

What to actually do

Inventory first. Pull every service account and OAuth grant touching AI workloads, then tag each one with a named human owner and an expiry date. Anything without both gets disabled, not investigated later.

Then attack standing privilege. Move agents to just-in-time credentials issued per task where the platform supports it. Where it doesn't, scope tokens to the narrowest dataset the agent demonstrably needs and rotate aggressively.

Log agent actions to the same SIEM pipeline (the system that centralises security event data) as human activity, with the originating prompt or trigger captured. If your detection rules can't distinguish a bulk records pull by an AI agent from a legitimate batch job, write that rule today.

Should you worry about regulators?

Yes. The ICO's guidance on AI and data protection is pointed: you are the data controller, regardless of which model touched the record. Consent and access controls extend to AI processing.

Orphaned agents won't show up on a breach-notification letter by that name. They'll appear as "unauthorized access by a third-party service." Fix it before the regulator names it for you.

The uncomfortable truth for security teams is that AI deployment has outrun identity governance by years, not months. Boards are funding agents faster than anyone is governing them, and the liability for what those agents touch sits squarely with the organisation that ran them.