---
url: 'https://www.corbado.com/blog/shadow-ai-agent-debt-identiverse-2026'
title: 'Shadow AI and Agent Debt: find the Agents you cannot see'
description: 'Where unknown AI agents hide, when an agent needs a human owner and how to build an off-boarding path before agent debt piles up.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-07-31T09:02:02.783Z'
lastModified: '2026-07-31T09:03:07.322Z'
keywords: 'shadow AI, agent debt, ownerless agents, AI agent discovery, AI agent inventory, non-human identity governance'
category: 'Passkeys Strategy'
---

# Shadow AI and Agent Debt: find the Agents you cannot see

## 1. Introduction: everyone has Agents they cannot see

The most useful thing about Identiverse 2026 was not a framework. It was the arithmetic.

The headline figure: 82% of respondents said they had found unsanctioned AI agents in their
environment, and they said it *while already running programs to inventory and control
agents*. The underlying research is a Cloud Security Alliance survey of 418 IT and security
professionals, sponsored by Token Security and fielded in January 2026.

Sitting next to that number is another one from the same survey: 68% believe they have
strong visibility into the AI agents in their environment. Both cannot be true. That
contradiction is the whole shadow AI problem in two data points, and it is why every
practical conversation at Identiverse started in the same unglamorous place: discovery.

Discovery is the operational half of the problem. The accountability half, deciding who is
answerable once an agent acts on someone's behalf, starts with
[how AI agents authenticate](https://www.corbado.com/blog/ai-agents-passkeys) in the first place.

## Key Facts

- **82% of enterprises found AI agents in their environment they did not know about**, while
  **68% believed they had strong visibility**. That gap was the most-quoted number of the
  week (Cloud Security Alliance survey of 418 practitioners, sponsored by Token Security,
  January 2026).
- **65% had an AI-agent-related incident in the past 12 months.** 61% involved data
  exposure, 43% operational disruption, 35% financial loss.
- **Only 21% have a formal process for decommissioning an AI agent.** Creation is trivial,
  retirement is not, and the difference is accumulating as **agent debt**.
- Shadow agents surface in **internal automation and scripting (51%)**, **LLM platforms
  (47%)**, **SaaS tools with built-in automation (40%)** and **developer workflows (40%)**.
- Only **11% automatically block an out-of-scope agent action**. 38% require human approval,
  24% only log it.
- Microsoft now ships an **ownerless agents** view in the Microsoft 365 admin center, read on
  stage as an admission of how common the problem already is.
- Half of AI agents in production authenticate with a **shared account (27%)** or a **static
  API key (23%)**, the two credential types with no expiry and no per-action scope (Omdia,
  n=400).
- Scale of the underlying problem: **45 billion+ non-human identities**, **85% of privileges
  unused in the last 90 days**, and the evidence spread across **80+ security tools** in the
  average enterprise.

## 2. Numbers in Full

The CSA and Token Security data is worth reproducing properly, because it is the most
concrete public picture of enterprise agent governance available right now.

### 2.1 Visibility

This table is the paradox in three rows: more organisations have found an agent they did not
know about than believe they have a blind spot in the first place.

| Finding | Share |
| --- | --- |
| Believe they have strong visibility into AI agents | 68% |
| Discovered previously unknown AI agents in their environment | 82% |
| Discovered previously unknown agents more than once | 41% |

### 2.2 Where shadow Agents show up

This table says the biggest source is not the LLM platform everyone is watching. It is
internal automation and scripting, a category that predates the agent wave and sits outside
most AI governance programs.

| Environment | Share |
| --- | --- |
| Internal automation and scripting | 51% |
| LLM platforms | 47% |
| SaaS tools with built-in automation | 40% |
| Developer-created workflows | 40% |

### 2.3 Incidents in the past 12 Months

This table shows the exposure is already realised rather than theoretical: two thirds have
had an incident, and the dominant consequence is data leaving where it should have stayed.

| Finding | Share |
| --- | --- |
| Experienced an AI-agent-related incident | 65% |
| Data exposure or mishandling | 61% |
| Operational disruption | 43% |
| Financial loss | 35% |

### 2.4 Controls

This table separates policy from enforcement. Two thirds have written down what an agent may
do, and only a ninth of them can actually stop an agent that ignores it.

| Control | Share |
| --- | --- |
| Have clear guardrails for agent boundaries | 66% |
| Require human approval when an agent exceeds scope | 38% |
| Only log it when an agent exceeds scope | 24% |
| Automatically block out-of-scope actions | 11% |
| Have a formal agent decommissioning process | 21% |
| Say context-aware controls will matter in the next two years | 79% |

The rows that should worry an identity team are in the last block. 11% can stop an
out-of-scope action automatically and 21% can retire an agent through a defined process.
Everything else is observation. Read as a maturity curve rather than as isolated
percentages, the survey describes a population that has arrived at awareness and stalled
well before control, as the following visual makes clear.

## 3. Three Places to look for Shadow Agents

The most usable discovery model of the conference splits the problem by location: agents
live in three distinct layers, and each needs a different detection method.

1. **Local agents on employee laptops.** Coding assistants and personal productivity agents
   installed directly on the endpoint. The only way to see these is endpoint telemetry:
   processes, file system activity and EDR signals.
2. **Agents inside managed SaaS.** Copilot, OpenAI and the agent features every SaaS vendor
   has now shipped. Discovery here runs through the SaaS admin surface.
3. **Agents running in production.** Built by engineering, deployed into infrastructure,
   holding real credentials.

The visual below maps each layer to the detection method it requires and to the share of
shadow agents the CSA survey actually found there.

The three layers carry different levels of risk. A program that covers only one of them will
report a clean inventory that is wrong.

There is a second-order effect here that identity teams should take seriously. Because local
agents run on endpoints, discovery work is turning up a *rising* number of plain-text secrets
and credentials on employee machines, after a decade of vaulting had been steadily shrinking
that surface.

> "[Something] we thought is shrinking over time because of vaults and other things ... is
> now actually expanding."

## 4. Why Attackers prefer Non-Human Identities

Before the lifecycle problem, the reason it matters. The clearest inventory of why non-human
identities are the preferred target came out of the non-human identity track, and the first
item on the list is the one identity teams underrate:

- **No MFA, and no equivalent.** There is no second factor for a service account.
- **Long-lived credentials and secrets**, rarely rotated in practice.
- **Rarely monitored, poorly understood, lacking documentation.**
- **Missing IAM disciplines**: no PAM, no IGA, often not in the IdP at all.
- **Faults in joiner, mover and leaver processes.**
- **Excessive privileges** as the default rather than the exception.

The summary line is worth internalising: **secrets are the "new" password**, whether they
take the form of API keys, tokens or certificates. Everything the industry learned about
protecting passwords has to be re-learned for a credential class that never sits behind a
login prompt.

The same session placed agentic AI on a risk scale against plain LLMs, RAG and
task-executing agents. Across data leakage, privilege abuse, lateral movement, workflow
escalation, identity sprawl, governance complexity, audit burden and blast radius, agentic AI
is the only column rated high on every single row. The framing for why: **AI is the new
middleware**, and it reintroduces the confused deputy problem at machine speed.

### 4.1 Credentials Agents actually hold today

The most useful data in the session came from Omdia research asking 400
respondents what credential types their AI agents use when calling internal or external APIs
directly, and how they expect that to change within 24 months:

| Credential type | Today | In 24 months |
| --- | --- | --- |
| OAuth client ID and client secret | 27% | 34% |
| Human user or shared service accounts | 27% | 18% |
| Static API keys | 23% | 13% |
| Client secret | 16% | 11% |
| Mutual TLS (mTLS) | 6% | higher |

Half of agents today run on either a shared human or service account (27%) or a static API
key (23%). Both are credential types with no expiry, no per-action scope and no clean way to
attribute an action to a specific agent. The direction of travel is right, but the honest
reading of the left column is that most agent deployments in production right now are
authenticated by exactly the thing the industry spent a decade telling people to vault.

## 5. Scale Nobody has an Inventory for

One discovery session opened with three numbers that frame why it is not a nice-to-have:

| Finding | Value |
| --- | --- |
| Non-human identities in existence | 45 billion+ |
| Privileges not used in the last 90 days | 85% |
| Cybersecurity tools in the average enterprise | 80+ |

The middle row is the one that turns zero standing privilege from an ideal into an obvious
cleanup job. If 85% of granted privileges went unused for a quarter, most of what is standing
is not serving anyone, it is only waiting to be abused. And the third row explains why nobody
sees it: the evidence is spread across 80-plus tools with no shared view.

The session also cited **Anthropic research that AI now executes 80-90% of tactical attack work
autonomously**, and a projection of **1.3 billion AI agents by 2028**. Whatever the exact
figure turns out to be, the direction makes a manual, quarterly review cadence untenable.

The framing of the starting point matches everything else at the conference, and it is the
same sentence we would write about a login funnel:

> "You cannot protect what you cannot see."

## 6. Agent Debt: created by an Employee who left

The lifecycle question turned out to be sharper than the discovery question.

The sharpest version of the point was made by a speaker against themselves. Twenty years in
identity, and they still went back through their own environment and found half a dozen
agents they had built for side projects, never checked on and left running.

> "They completed their task, they're still out there, they're still doing things."

Vendors working on discovery confirm it as a pattern rather than an anecdote: "agent created
by off-boarded employee is a phenomenon and we see it quite often."

The structural cause is that agent creation moved outside engineering. The industry has done
a decent job educating developers and security teams, and that is not where the exposure sits
any more:

> "It's everyone else in the company. It's your finance organization, it's your marketing
> team, HR. They're able to take some low barrier, no code environment right now and spin up
> an agent because it's that easy."

An agent created in a no-code tool by someone in finance never passed through a provisioning
system, so there is nothing to trigger when that person leaves. Microsoft's response is
telling: the Microsoft 365 admin center now surfaces **ownerless agents** as a first-class
dashboard item, with filters and rules to reassign or block them. The read on stage was
blunt: it exists because orphaned agents are already normal.

That accumulation picked up a name on the interview stage: **agent debt**. It behaves like
technical debt with a running meter attached, because an unowned agent keeps consuming
tokens. Nobody notices until "the CFO says wait, we spent how much this month, what is this
doing?"

## 7. When does a Tool become an Employee?

Discovering every agent is not the goal. Chasing every browser extension is "a game of
Whac-A-Mole that we probably won't ever win". The governance question is which agents cross a
threshold that makes them worth governing.

The cleanest test anyone offered:

> "If it drafts an email for me and then I send it, I'm still reviewing, I still ultimately
> have control ... conversely, if it can draft the email, send the email, transfer the money,
> whatever it might be, then it's sort of become an employee that we didn't interview."

The trigger is autonomous action, not intelligence and not access. The moment software can
complete an action without a human confirming it, it needs an owner, an entry in the
inventory and a review cadence.

## 8. Model everyone converged on: JML for Agents

The fullest version of the lifecycle deliberately reuses the joiner-mover-leaver structure
identity teams already run for staff.

- **Discovery.** Find every agent in the environment, continuously rather than once.
  "Otherwise you're in the dark continent."
- **Inventory.** Build the repository of agents you are going to monitor.
- **Joiner.** Assign each agent an identity, the same way birthright rules assign one to a
  new employee.
- **Mover.** Monitor for behaviour and intent change. This is the part with no human
  equivalent, because agents change what they do far faster than people change roles.
- **Leaver.** When an agent is no longer relevant or has no owner, reassign ownership or
  deprecate it.

One accountability rule makes the model enforceable: every agent must have a human owner,
and that human is responsible for what the agent does.

The gap between this model and reality is the 21% figure. Most organisations have some
version of joiner. Almost nobody has leaver.

## 9. Why the human Cadence does not transfer

The recurring objection to simply extending existing IGA processes to agents was speed, and
it came up in almost every interview.

"The cadence that we've used for human identities just doesn't apply in the same way with
agents. They're so fast." The same point came up about access reviews, where the
most-requested feature from customers is bulk approve, because reviewing individual
entitlements has become performative.

One argument went further: the tooling never scaled in the first place.

> "The classic IGA and PAM actually didn't scale even to the explosion of identities in
> cloud ... so for sure they're not going to support agents' explosion."

Two structural answers emerged. The first is to use AI to shrink the review funnel, on the
argument that 98 to 99% of decisions are unambiguous and the value is in routing the rest to
a human. The second, which lines up with the zero-standing-privileges argument, is to remove
the need for review entirely by issuing one-time entitlements, so there is no standing
privilege left to certify.

There is also a budget dimension that nobody plans for. Some organisations allocated 60% of
budget to AI and then overspent by another 20 to 30% on prompt and token costs, leaving
roughly 10% for everything else. The advice from the consulting side was to carry a
deliberate 20 to 30% buffer, because consumption is genuinely unpredictable.

## 10. What Consumer Identity Teams should take from this

Most of this is workforce territory. Three things carry over to anyone running consumer
authentication at scale.

**Discovery is a telemetry problem, and you already have the analogue.** The reason 68% of
teams believe they have visibility while 82% keep finding unknown agents is that they are
inferring from configuration instead of measuring behaviour. The same gap exists in consumer
login stacks: teams believe they know how users authenticate, then discover the real
distribution across devices, browsers and fallback methods looks nothing like the design
document. That is the case for
[authentication observability](https://www.corbado.com/blog/authentication-observability) rather than dashboards
built on assumptions.

**Lifecycle discipline is the transferable skill.** Discovery, ownership and a defined path
to retirement is the same muscle that decides whether a
[passkey rollout](https://www.corbado.com/blog/passkey-adoption-business-case) succeeds. Credentials accumulate,
enrollment states drift and fallback paths quietly stay open long after they were supposed
to close.

**The foundation agents inherit is the one you build now.** Agents act on top of whatever
authentication your users have. Standing secrets on endpoints are increasing again, which
means shared and phishable credentials are proliferating
at exactly the moment the industry is trying to make actions attributable.
[Passkeys](https://www.corbado.com/glossary/passkey) do not govern agents. What they do is remove the class of
credential that makes attribution impossible in the first place.

## 11. How Corbado can help

The visibility paradox in this article has a direct equivalent in consumer authentication:
teams believe they know how their users log in, and the measured distribution says something
else. [Corbado Observe](https://www.corbado.com/observe) removes the guesswork by instrumenting the existing login
and signup flows and recording every step as structured events, without replacing the auth
stack behind them.

[Watch video](https://www.corbado.com/videos/features/user-search-debugging.mp4)

- **Measured instead of assumed.** Method distribution, success rates and drop-off per step,
  broken down by device, browser, OS and market, so the real behaviour replaces the
  architecture diagram.
- **Error and anomaly detection.** WebAuthn errors, cancels and timeouts are classified by
  cause, and unusual spikes surface as anomalies instead of being reported by support weeks
  later.
- **Per-user reconstruction.** Search a single user and replay the exact sequence of steps
  behind an incident, which is the same evidence trail agent governance depends on.
- **A retirement path for the old credential.** [Corbado Connect](https://www.corbado.com/connect) rolls out
  passkeys gradually with A/B tests and rollout rules, so the phishable fallback can actually
  be closed rather than left running the way an unowned agent is.

## 12. Conclusion

The story Identiverse 2026 told with numbers is simple. Agent creation has been
democratised, agent retirement has not, and the gap is filling with unowned software that
holds real permissions against real systems.

82% have found agents they did not know about. 65% have already had an incident. 21% can
retire an agent through a defined process. Those three figures describe an industry that is
still at the discovery stage of a problem it is simultaneously scaling.

The unglamorous advice from the practitioners on stage was consistent: find them, give each
one an owner, decide at what point a tool becomes an employee and build the off-boarding
path before you need it. None of that is new identity thinking. It is the same discipline,
applied to a population that grows faster than the people responsible for it.

## Frequently Asked Questions

### What is shadow AI?

Shadow AI is any AI system, tool, agent or workflow running inside an organisation without
the knowledge or governance of the security and IT teams responsible for managing risk. In
the Cloud Security Alliance survey sponsored by Token Security (418 respondents, January
2026), 82% of enterprises reported discovering previously unknown AI agents in their
environment, and 41% had discovered them more than once.

### How many enterprises have unknown AI agents in their environment?

82%, according to the Cloud Security Alliance and Token Security survey of 418 IT and
security professionals. The same survey found 68% of respondents believed they had strong
visibility into their AI agents, which is the visibility paradox that was widely quoted at
Identiverse 2026.

### Where do shadow AI agents typically appear?

According to the CSA and Token Security data, shadow agents most commonly emerge in internal
automation and scripting environments (51%), LLM platforms (47%), SaaS tools with built-in
automation (40%) and developer-created workflows (40%). Speakers at Identiverse 2026
grouped them into three discovery layers: local agents on employee
endpoints, agents inside managed SaaS applications and agents running in production.

### What is agent debt?

Agent debt is the accumulation of AI agents that are still running but no longer owned,
reviewed or needed, typically because the person who created them moved on or forgot about
them. It was described at Identiverse 2026 as technical debt with a running cost, since an
unowned agent keeps consuming tokens. Only 21% of organisations report having a formal
decommissioning process for AI agents.

### What are ownerless agents?

Ownerless agents are AI agents whose creator has left the organisation or changed roles,
leaving the agent running with stale permissions and no accountable owner. Microsoft now
surfaces ownerless agents as a dedicated view in the Microsoft 365 admin center, with filters
and rules to reassign or block them, which was read at Identiverse 2026 as confirmation that orphaned agents are already widespread.

### When does an AI agent need to be governed as an identity?

The threshold proposed at Identiverse 2026 is
autonomous action. If an agent drafts an email and a human sends it, it is a tool. If it can
draft the email, send it or transfer money without a human confirming, it has become an
employee that was never interviewed and needs an owner, an inventory entry and a review
cadence.

### How should AI agents be off-boarded?

The model described at Identiverse 2026 mirrors the joiner-mover-leaver process used for
staff: continuous discovery, an inventory, an identity issued per agent, monitoring for
behaviour and intent change and a defined path to reassign ownership or deprecate the agent
when it is no longer needed. One session added the enforcement rule that every agent
must have a named human owner who is accountable for its actions.