Shadow AI Agents: The 60–80% of AI Inventory Your Security Team Cannot See

The Microsoft Agent 365 GA announcement in May 2026 named a problem that every CISO already suspected but could not quantify: most enterprises have 60–80% more AI agents operating in their environment than their official inventory records. The difference between the visible inventory and the actual population is the shadow AI agent population — agents deployed by business units, created through low-code platforms, integrated through SaaS tools, or built by developers who did not go through the official onboarding path.

The shadow population is not malicious. The agents were built for legitimate purposes: automating customer service triage, generating marketing copy, processing invoices, summarizing meeting notes. The developers who built them had real problems to solve and used the tools at hand. The shadow classification is not a judgment about the agents' intent; it is a statement about the organization's lack of visibility and governance over the agents' existence.

The lack of visibility is the security risk. A shadow agent operates with credentials, accesses data, makes decisions, and produces outputs. None of these activities are monitored by the security team. None of the agents' actions are logged in the central audit trail. None of the agents' decisions are subject to the organization's policy. The shadow agent is an unmonitored execution environment running with production access to the organization's systems and data.

The organizations that will operate AI agents securely in 2026 are the ones that recognize shadow AI agents as the largest ungoverned AI surface in their environment, invest in Agent Discovery and Governance (ADG) as a first-class security discipline, and build the onboarding workflow that converts shadow agents to governed agents at scale. The alternative is the next incident — the next "we did not know we had that agent" headline — and the next audit finding that names the unmonitored agent as the breach vector.

The Scale of the Shadow AI Agent Population

The 60–80% figure is consistent across multiple 2026 industry surveys. The shadow AI agent population is typically 2–5x the size of the managed agent population. The drivers are consistent:

Low-code and no-code agent platforms. Microsoft's Power Platform, ServiceNow's Now Assist, Salesforce's Agentforce, and dozens of specialized platforms allow business users to build AI agents without engaging IT. The agents are functional, deployed, and used by their builders — but they are invisible to the security team's inventory because they were not deployed through the organization's standard software development lifecycle.

Embedded agents in SaaS applications. Modern SaaS applications (CRM, ERP, helpdesk, marketing automation) include AI agents as built-in features. The agents operate within the SaaS vendor's infrastructure, but they act on the organization's data. The agents are not separately inventoried because they are part of the SaaS application's functionality. The security team may know the application is in use; they may not know the application includes an agent.

Departmental agent projects. Business units with real automation needs deploy AI agents to solve them. Marketing teams deploy agents for content generation; sales teams deploy agents for lead scoring; finance teams deploy agents for invoice processing; HR teams deploy agents for candidate screening. Each deployment is a separate project with its own credentials, its own data access, and its own operational footprint.

Developer-built agents. Individual developers build AI agents to solve their own problems, then share the agents with colleagues. The agents are not deployed through the formal SDLC; they are shared through internal documentation, chat channels, or open-source repositories. The agents may have access to production systems because their developers had production access.

MCP server sprawl. The Model Context Protocol ecosystem has accelerated agent tool creation. Each new MCP server is a potential agent capability. Developers integrate MCP servers into their local agent setups; the agents gain new capabilities without going through a centralized approval process. The MCP integration may be a developer experiment; it may also be a production deployment.

These five drivers create the shadow population. The population grows organically; the visibility does not keep pace.

Why Traditional Asset Inventory Cannot Find Shadow Agents

Traditional IT asset inventory tools — Configuration Management Databases (CMDBs), software asset management (SAM) platforms, endpoint detection and response (EDR) systems — were built for software applications, not AI agents. The tools can find the software that runs agents, but they cannot find the agents themselves.

Agents are not separate software. An AI agent is not a distinct application installed on a server. The agent may be a configuration in a cloud platform, a workflow in a SaaS application, a script in a developer's environment, or a prompt template shared through documentation. The agent is not a process that the CMDB tracks; it is a logical construct that exists in many places at once.

Agents operate across multiple systems. An agent's logic may live in Microsoft Copilot Studio; the agent's data access may be in Snowflake; the agent's actions may be in Salesforce; the agent's notifications may be in Slack. The traditional asset inventory tracks each system separately; the agent as a logical entity is invisible.

Agents are deployed without IT involvement. The deployment mechanism — a low-code platform, a SaaS configuration, a developer's script — does not produce the artifacts (change tickets, deployment records, approval workflows) that the CMDB expects. The agent exists in the environment, but the CMDB has no record of its deployment.

Agents evolve rapidly. The agent's behavior changes through prompt engineering, tool updates, and configuration tweaks. The change management process that the CMDB expects is not applied. The asset inventory records the agent's initial deployment; the agent has since evolved significantly. The inventory is stale; the security team's visibility is incomplete.

The traditional asset inventory is necessary but not sufficient. A new discipline — Agent Discovery and Governance — is required.

The Agent Discovery and Governance Discipline

Agent Discovery and Governance (ADG) is the discipline of finding every AI agent operating in the organization's environment, classifying each agent by risk, and onboarding the agents that warrant governance into the organization's managed inventory. ADG has three operational phases.

Phase 1: Discovery. The ADG platform scans the organization's environment for AI agent signatures. The signatures include: known agent platforms (Microsoft Copilot Studio, ServiceNow Now Assist, Salesforce Agentforce, custom agent frameworks), MCP server connections, agent-adjacent network traffic, prompt template repositories, and behavioral patterns consistent with agent activity. The discovery is comprehensive but imperfect; the platform detects what it can recognize, and the unrecognized agents remain in the shadow population.

Phase 2: Classification. Discovered agents are classified by risk. The classification considers: the agent's data access, the agent's action set, the agent's blast radius, the agent's relationship to the organization's critical systems, and the agent's compliance exposure. The classification produces a risk score; the score determines the priority for onboarding.

Phase 3: Onboarding. The shadow agents are brought into the organization's managed agent inventory through a structured onboarding workflow. The workflow includes: registration (the agent's identity, owner, purpose), credential scoping (the agent's permissions aligned with least privilege), policy attachment (the agent's behavior subject to the organization's policy), and audit trail integration (the agent's actions logged in the central audit trail).

The three phases form a continuous loop. Discovery is ongoing (new shadow agents appear continuously); classification is updated as agent risk profiles change; onboarding is performed as resources allow, prioritized by risk.

The Microsoft Agent 365 Reference Implementation

Microsoft Agent 365, generally available as of May 2026, is the first major platform to address the ADG problem at enterprise scale. The platform's approach is worth understanding as a reference implementation.

Discovery. Agent 365 integrates with the Microsoft 365 admin center, Defender, and Intune to discover agents across cloud and endpoint environments. The discovery includes local agents (running on endpoints), cloud agents (running in Azure), and embedded agents (running within Microsoft 365 applications). The discovery is comprehensive within the Microsoft ecosystem; agents outside the Microsoft ecosystem require additional discovery tooling.

Classification. Discovered agents are classified by capabilities (what tools the agent has), data access (what data the agent can reach), and risk (the combination of capabilities and access). The classification is presented in a unified inventory view that allows administrators to see all agents, their classifications, and their risk scores.

Onboarding. Agent 365 provides onboarding workflows that register discovered agents in the central inventory, apply policies through Intune, and monitor the agents through Defender. The workflow handles the common agent categories (Microsoft-native and major SaaS platforms); custom agents require more elaborate onboarding.

Continuous monitoring. Agent 365 monitors agents for behavior changes, policy violations, and security events. The monitoring is integrated with the broader Microsoft security ecosystem; alerts flow into the same SIEM that handles other security events.

The Agent 365 reference implementation is a starting point, not a complete solution. The platform's discovery is comprehensive within the Microsoft ecosystem but limited outside it; agents built with non-Microsoft frameworks or hosted in non-Azure environments require additional discovery. The classification and onboarding workflows handle common cases but require extension for specialized environments.

The Multi-Platform Discovery Challenge

Most enterprises do not operate exclusively within the Microsoft ecosystem. The agent population spans:

• Microsoft Copilot Studio, Azure AI Foundry, and Agent 365
• AWS Bedrock Agents and SageMaker
• Google Vertex AI Agents and Agent Builder
• Anthropic Claude-powered agents
• OpenAI Assistants API and Custom GPTs
• Salesforce Agentforce
• ServiceNow Now Assist
• Workday Illuminate
• Custom agents built on LangChain, AutoGen, CrewAI, or other frameworks
• Agents built on no-code platforms (Zapier, n8n, Make)
• MCP-connected agents operating through Claude Desktop, Cursor, or custom runtimes

Each platform and framework has its own agent signature, its own deployment model, and its own visibility surface. Comprehensive discovery requires agent discovery tooling that recognizes all of these signatures and correlates them with the organization's identity and network infrastructure.

The discovery tooling is a separate market segment. Several vendors (Superblocks, Straiker, Permiso, Reco, Zscaler AI Guard, and others) have emerged in 2025–2026 to address the multi-platform discovery challenge. The vendors compete on coverage (how many agent platforms and frameworks are recognized), accuracy (how well the recognition works), and integration (how well the discovery results flow into the organization's existing security operations).

The discovery tooling is necessary but not sufficient. Discovery without onboarding is an audit report that gathers dust. The shadow agents remain ungoverned; the security team's risk is unchanged. The onboarding workflow is what converts discovery into security improvement.

The Onboarding Workflow

The onboarding workflow for a discovered shadow agent has seven steps. The workflow is structured to minimize friction while establishing the governance required for production deployment.

Step 1: Registration. The agent is registered in the managed inventory with: the agent's identity, the agent's purpose, the agent's owner (the person accountable for the agent's behavior), the agent's deployment date, and the agent's business unit. The registration produces an entry in the inventory that the security team can query and the operations team can manage.

Step 2: Identity assignment. The agent is assigned a cryptographic identity (workload identity, mTLS certificate, OAuth client credential). The identity is distinct from any individual human's identity; the identity is the agent's own. The identity is the basis for all subsequent authorization decisions.

Step 3: Credential scoping. The agent's credentials are scoped to the minimum permissions required for its purpose. The scoping is enforced through the runtime's policy engine; the credentials are issued with the appropriate scope and expire when the scope ends.

Step 4: Policy attachment. The agent is attached to the organization's policy framework. The policies are evaluated at the runtime layer (covered in the Facio analysis from June 2026): tool call argument validation, destination allowlisting, sensitive content detection, circuit breakers. The policies are configured based on the agent's classification and the agent's risk profile.

Step 5: Audit trail integration. The agent's actions are integrated into the organization's tamper-evident audit trail (covered in the Facio analysis from June 2026). The audit trail captures every tool call, every policy decision, every model interaction, and every output. The audit trail is the evidence for compliance, the forensic record for incidents, and the basis for trust in the agent's behavior.

Step 6: HITL integration. High-blast-radius actions are routed to human review through Placet.io (the HITL inbox and messenger). The HITL integration is configured based on the agent's risk profile: low-risk agents may have minimal HITL requirements; high-risk agents may require human approval for any action above a defined threshold.

Step 7: Monitoring and baselining. The agent's behavior is monitored and baselined. The baseline establishes the agent's normal patterns; deviations trigger alerts. The monitoring is continuous; the baseline is updated as the agent's behavior evolves.

These seven steps convert a shadow agent to a governed agent. The steps are structured to be efficient; the friction is intentional and proportional to the agent's risk.

The Cultural Challenges

The technical challenges of ADG are solvable. The cultural challenges are harder.

Builder resistance. The developers who built the shadow agents may resist the onboarding process. They may see the process as bureaucratic, the policies as restrictive, the audit trail as surveillance. The resistance is understandable; the developers were solving real problems and the process may seem like additional work for the same outcome. The response is to make the onboarding process proportionate and the governance supportive, not punitive.

Business unit priorities. The business units that deployed the agents have priorities. The agents are solving problems; the onboarding is taking time. The business units may resist the onboarding as a distraction. The response is to demonstrate the value of governance — the audit trail that satisfies regulators, the policy that prevents incidents, the HITL integration that catches errors before they cost money.

Vendor relationships. Some shadow agents are built on platforms with which the organization has enterprise agreements. The onboarding process may require engagement with the vendor's enterprise team, which is slower than the original self-service deployment. The response is to plan the onboarding as a project with explicit vendor engagement.

Compensating controls. Until onboarding completes, the shadow agents operate without governance. The interim period — which may be weeks or months — requires compensating controls: network restrictions, credential rotation, output review, or temporary suspension. The compensating controls are not a substitute for governance; they are a bridge until governance is in place.

The cultural challenges are real but manageable. The organizations that have addressed them have done so by positioning the ADG program as an enabler, not a gatekeeper. The program helps developers deploy agents safely; the program satisfies the compliance obligations that the developers would otherwise face alone.

Facio's Role in the Shadow AI Agent Problem

Facio (the HITL-first agent runtime) is the governance target for shadow agent onboarding. When an organization discovers a shadow agent, the onboarding workflow brings the agent onto Facio — where the agent's actions are subject to the runtime's policy engine, the audit trail, and the HITL integration with Placet.io (the HITL inbox and messenger).

Facio's role is not to perform discovery. Discovery is the role of the Agent Discovery and Governance platforms. Facio's role is to be the runtime that the discovered agents are onboarded to. Facio provides the execution environment with the policy enforcement, the audit trail, and the HITL integration that the organization's governance framework requires.

The onboarding path: Discovery finds the shadow agent → Classification assigns the risk score → Onboarding registers the agent on Facio with the appropriate identity, credentials, and policies → The agent continues to operate, but now under governance. The discoverer's output becomes Facio's input.

The architectural separation is intentional: discovery tooling is the eye; Facio is the hand. The discovery tooling finds the agents; Facio governs them. The combination is the ADG pattern.

The Bottom Line

Shadow AI agents are the largest ungoverned AI surface in most enterprises. The 60–80% figure from Microsoft's May 2026 GA announcement is consistent across industry surveys. The shadow agents operate with production access, make decisions on real data, and produce outputs that affect real outcomes. None of these activities are monitored by the security team.

Agent Discovery and Governance is the discipline that addresses the problem. Discovery finds the agents; classification assigns risk; onboarding brings them under governance. The Microsoft Agent 365 reference implementation, the multi-platform discovery tooling market, and the seven-step onboarding workflow together form the ADG pattern that production deployments need.

Facio (the HITL-first agent runtime) is the governance target. Placet.io (the HITL inbox and messenger) is the human review workflow. Together, they are what the shadow agents are onboarded to. The organizations that will operate AI agents securely in 2026 are the ones that invest in ADG, integrate discovery with Facio's governance runtime, and convert the shadow population to a governed population at scale.

The alternative is the next "we did not know we had that agent" incident — and the next audit finding that names the unmonitored agent as the breach vector. The discovery tooling exists; the onboarding workflow exists; the governance runtime exists. The only variable is whether the organization has decided to use them.

---

Further reading:

• Microsoft Security Blog: Microsoft Agent 365 Now Generally Available
• Enterprise DNA: Microsoft Agent 365 Is Live and Hunting Shadow AI
• Superblocks: 9 Best AI Agent Governance Platforms in 2026
• Futurum: Microsoft Agent 365 Turns Shadow AI Into a Governed Asset Class
• Shadow AI Agents: The Non-Human Identity Crisis Nobody Is Governing
• AI Agent Runtime Guardrails: Why Policy at the Model Layer Fails