AI Agents and Non-Human Identity Risk

Your organisation’s AI strategy almost certainly has a named executive owner.

The AI agents running underneath it almost certainly do not.

That gap — between who owns the strategy and who owns each agent’s access — is where the next wave of uncontrolled risk is building, and three incidents in the first half of 2026 show exactly what happens when it goes unmanaged.


The 30-second take

AI agents authenticate and act using non-human identities.

These identities are multiplying far faster than the governance processes built to manage them.

Palo Alto Identity Security Landscape research puts machine identities at roughly 109 for every human identity in the average enterprise, up from 82:1 a year earlier — and AI agents now account for around three-quarters of that machine population. Sixty-eight percent of organisations told CyberArk they have no identity security controls specifically for AI.


Three incidents, one root cause

None of the following incidents started with a sophisticated exploit. Each started with a non-human identity that nobody was watching.

Vercel, April 2026. The breach didn’t originate in Vercel’s own infrastructure at all. It started at Context.ai, a third-party AI productivity tool, where an employee’s device was compromised by infostealer malware. That gave attackers the OAuth tokens Context.ai held for its customers — including a Vercel employee who had connected the tool to their Google Workspace account — and from there, a path into Vercel’s internal dashboards, API keys and GitHub tokens. The failure point was a credential belonging to a tool that sat entirely outside any AI governance register.

GitHub, May 2026. A single engineer installed a malicious version of the Nx Console extension from the official Visual Studio Marketplace. The poisoned extension harvested credentials wherever it found them — including from Claude Code configuration files, 1Password vaults, npm and AWS — and used them to exfiltrate roughly 3,800 internal repositories. The extension itself wasn’t the asset at risk; the machine credentials sitting quietly alongside it were.

LiteLLM, March 2026. Attackers compromised the open-source LiteLLM package — present in an estimated 36% of cloud environments that connect applications to AI services — and used it to harvest credentials at scale. Mercor, a data-labelling firm working with several frontier AI labs, confirmed it was among thousands of affected organisations, with contractor data and source code exposed as a result.

Three different entry points, one shared pattern: a non-human identity with more access than anyone was actively managing.

Questions to ask your organisation

  • Can you produce a complete list of every AI agent and AI-connected tool currently operating in your environment, what each one can access, and who is accountable for it?
  • Are AI agent and API credentials subject to the same rotation, review and revocation discipline as privileged human access — or were they set up once and left alone?
  • If an employee installs a third-party AI plugin or extension on their own initiative, would your organisation know it existed before something went wrong?
  • Does your third-party and vendor risk process extend to the AI tools embedded inside vendor platforms, or does it stop at the platform’s own perimeter?
  • If a non-human identity were compromised today, could you reconstruct what it accessed and did, within your current logging and audit capability?
  • Is responsibility for AI agent governance sitting with a named business owner, or defaulting to IT because nobody else has claimed it?

What good looks like

Organisations managing this well treat every AI agent and connected tool as a governed identity from the moment it’s provisioned — with a named business owner, a defined and time-bound access scope, and a review cycle that doesn’t wait for an incident to trigger it.

The Vercel, GitHub and LiteLLM incidents all involved credentials that would have been caught by exactly that discipline. The gap isn’t a technology problem. It’s a governance decision that most organisations haven’t made yet.

More from the Reading Room

Why AI Operational Resilience Must Be a Boardroom Priority Now

AI failures can disrupt critical operations and damage customer trust. Boards and executives must treat AI operational resilience as a core governance responsibility—not just a technical issue—to safeguard business continuity and reputation.

How to Master AI Risk Control Testing for Real-World Assurance

NIST’s August 2026 TEVV-Athlon draft makes real-world AI evaluation a current governance issue. Businesses should connect every test to pre-agreed acceptance thresholds, a named decision owner and clear retest triggers.

Why Clear Third-Party AI Evidence Requirements Are Non-Negotiable for Risk Management Success

ASD’s Australian Cyber Security Centre and the UK National Cyber Security Centre show why AI supplier assurance must cover the full lifecycle and extended supply chain. Moffatt v Air Canada demonstrates that business accountability remains with the organisation using the automated service.

Turning AI Risk Assessments into Business Accelerators: A Practical Path Beyond Bottlenecks

AI risk assessments often stall innovation when unclear ownership and inconsistent evidence requirements create bottlenecks. Business leaders must own AI risk decisions, supported by clear triage and third-party evidence standards to speed value delivery without compromising controls.