Shadow AI Agents and the Sanctioned Path Avatier Provides

A shadow AI agent is an AI agent built or connected outside your governed channels, so it acts with borrowed credentials and has no registered owner. The AI is not the problem. The access is: the agent calls real systems under a person's token or a shared service account, and your identity program has no record that it exists.

The pattern is familiar. Shadow IT Provisioning covers access granted to people outside the governance platform. Shadow agents are the same gap with one difference: the thing holding the access can act on its own.

What makes an AI agent a shadow agent

Three properties define it:

• Built outside governed channels. Nobody registered it, requested access for it, or approved its scope.
• Borrowed credentials. It authenticates as someone or something else: a person, a shared key, a service account.
• No owner. No named human is accountable for what it does or for retiring it.

A sanctioned agent is the opposite on all three. It has its own governed identity, access scoped to its task, and an owner, the model laid out in our agentic identity guide. An agent can also start sanctioned and drift into shadow: its owner leaves, or someone copies its key into a second tool.

AI agent sprawl is what happens when these accumulate. Each one may have been a reasonable shortcut on the day it was built. Together they are a population of actors nobody can list.

How shadow agents get access

A shadow agent does not need an exploit. It uses access that already exists. Three paths stand out.

Path	What it looks like	Why governance misses it
Borrowed credentials	A person connects an agent with their own login, session, or OAuth grant	Actions log as the person, not the agent
Personal tokens	An API key or personal access token sits in the agent's config file or environment	The token was issued to a human, for a human's use
Over-broad service accounts	The agent is pointed at an existing service account with standing access	The account is already approved, so nothing new is requested

Local tooling makes the second path easy. Authorization is optional in the Model Context Protocol specification, and its OAuth-based flow is defined for HTTP transports. Where authorization is supported, the spec says implementations using an STDIO transport should not follow that flow and should "instead retrieve credentials from the environment." Whatever keys sit in that environment are what a local agent can use.

The third path maps to what OWASP calls excessive agency. Its LLM06:2025 entry says the root cause is typically one or more of three: excessive functionality, excessive permissions, and excessive autonomy. One of its examples is an extension that "accesses downstream systems with a generic high-privileged identity." An over-broad shared service account is that kind of identity.

Shadow agents don't break in. They borrow a person's login, a personal token, or a service account that was already approved.

The risk: actions nobody owns

Shadow AI risk comes down to three failures.

Attribution breaks. When an agent acts under a borrowed identity, the log shows the person or the service account. "Which agent did this, and why?" has no answer.

Scope is inherited, not granted. The agent can do whatever its borrowed credential can do. Nobody chose that scope for the agent's task; it came with the credential.

Revocation has no trigger. A sanctioned agent is retired when its purpose ends. A shadow agent has no registered purpose and no owner to notice, so it keeps running. Disabling the service account it uses may also break everything else that depends on that account.

How to find shadow agents

Don't expect public breach data to show you the problem. Avatier's Identity Attack Ledger reads 2,161 breach notifications filed with the California Attorney General from January 2023 through August 14, 2026, and service-account or non-human identity abuse appears in none of them. The ledger reads that as a limit of what notification letters disclose, not a sign the attack is rare.

Discovery is general security work, done with your own tooling. Five places to look:

1. OAuth grants and app consents. Review which applications and clients users have authorized against your identity provider, and flag the ones nobody registered.
2. Secrets in code and config. Scan repositories, configuration files, and agent settings for API keys and tokens, especially ones issued to individual people.
3. Service account behavior. Look for service accounts whose activity no longer matches their documented purpose.
4. MCP client configurations. On managed devices, inventory which MCP servers are configured and which credentials they load.
5. Ask. Run a no-blame declaration window: anyone who built an agent registers it, names an owner, and lists its credentials. People may know about agents that no scanner finds.

Every finding goes into one inventory: the agent, what it touches, which credential it uses, and who, if anyone, claims it.

Govern or retire: the decision for each agent

Every discovered agent gets one of two outcomes, and two questions decide which.

Does it serve a purpose someone will own? If no named person accepts accountability, retire it. Revoke its credentials, remove its access, and keep the record, following the runbook in Deprovisioning AI Agents.

Can it run through sanctioned capabilities with its own identity? If yes, bring it under governance:

1. Register it, with the owner as its accountable human.
2. Give it its own identity, then revoke the borrowed credential.
3. Scope its access to the task, capped at the owner's authority, using the steps in Least-Privilege Access for AI Agents.
4. Move its identity actions onto approved capabilities, so each one is policy-checked and recorded.

If the purpose is real but the agent cannot be made to fit, suspend it and rebuild the need on the sanctioned path.

Two questions settle every agent you find: will someone own it, and can it run through sanctioned capabilities under its own identity?

Make the sanctioned path the easy one

When the governed route is slower than the shortcut, people have a reason to take the shortcut. Discovery without an alternative can push the next agent somewhere harder to see. One answer is a sanctioned path that is quicker than pasting a token: approved capabilities people can call from the assistants they already use, access that follows their own permissions, and evidence produced without extra work.

What Avatier ships toward this pattern

Avatier's role is the sanctioned path, not discovery. Avatier Identity Anywhere 2027™ is built to govern people, applications, machines, credentials, and AI agents. IT teams can spin up an agent that requests access, checks entitlements, or pulls identity analytics with Claude Code, OpenAI Codex, GitHub Copilot, or any MCP client.

Avatier Actions exposes more than 50 identity outcomes as MCP tools across eight modules, including Lifecycle Management, User Management, Group Management, and Access Governance. An employee or manager asks in Teams, Outlook, Claude, or Copilot, and the outcome runs through the customer's existing policies, approvals, and roles, because the assistant is the interface, never the authority. AI assistants do not receive unrestricted access: every request must invoke an approved Avatier capability. Setup is one administrator connection, with permissions inherited from Microsoft Entra ID, Active Directory, Okta, and Ping.

Avatier Ledger turns every outcome into evidence. Each Secure Outcome records the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result. The security team's Persona Briefing is built around exposure, dormant and orphaned access, and privileged activity. Under Pay Per Identity Action™, customers pay only for completed, verified, policy-compliant outcomes.

On the credential side, Credential Governance™ manages passwords, keys, tokens, and service accounts from birth to retirement across Active Directory, Entra ID, and legacy systems.

For the invitation-only preview, see the Avatier Identity Anywhere 2027™ site. For credential lifecycle, see Credential Governance. For the company, see avatier.com. For compliance, see the Avatier Trust Center: SOC 2 Type II audited with no exceptions noted, and ISO/IEC 27001:2022 certified.