Half of all enterprises run at least one shadow AI application.
Shadow AI is any use of AI tools, applications, or services that employees adopt without IT or security approval. The category includes consumer chatbots used on personal accounts, AI writing assistants installed as browser extensions, AI coding tools connected to development environments, and generative AI SaaS products that employees sign up for with a work email.
The defining characteristic is unauthorized adoption, not autonomous action. The employee is still the actor. The AI tool receives input and returns output. The risk is what the employee puts in: sensitive documents, customer records, proprietary code, or personally identifiable information sent to a model the organization does not control.
Shadow AI agents are a fundamentally different category. A shadow AI agent is an autonomous or semi-autonomous system that takes actions rather than simply receiving input. Shadow agents deploy without IT or security oversight, and they operate by connecting to SaaS applications, databases, APIs, and external services using inherited credentials or embedded tokens. They do not wait for a human to submit a prompt. They execute workflows, move data, modify records, and trigger downstream processes.
The human who built the agent may have left the organization. The agent continues running.
Security teams at one enterprise discovered 377 Copilot agents they did not know existed. Another enterprise had 2,500 agents already created before any inventory process was in place. These are not theoretical configurations. They are active, credentialed systems operating inside the SaaS fabric with no security oversight.
DimensionShadow AIShadow AI AgentsCore behaviorReceives input, returns outputTakes autonomous, multi-step actionsHuman in the loopYes, alwaysOften no, or minimalCredential footprintUser's session onlyInherited tokens, OAuth grants, embedded credentialsData movementWhat the user submitsWhat the agent can access across all connected systemsBlast radiusSingle session, single userCross-platform, compounding with every actionAccountabilityTraceable to the userOften orphaned, no active ownerPrimary risk classData leakageMachine insider risk, privilege escalationDetection methodBrowser monitoring, CASBRuntime agent inventory, identity graph
The shadow AI vs. shadow AI agents comparison is not a matter of degree. These are five structurally different risk properties.
Shadow AI tools receive what a human gives them. A shadow AI agent acts on what it can reach. An employee uploading a sensitive document to an unauthorized chatbot creates a data leakage event bounded by that upload. A shadow agent connected to a CRM, a file storage system, and an email platform can query records, extract attachments, and send outputs externally, all within a single triggered workflow. The agent is the actor. The human is not present for most of it.
Shadow AI risk is bounded by the user's session. Shadow agent risk is bounded by the agent's effective authority across every system it connects to. Agents move 16 times more data than human users. An agent with connections to Salesforce, SharePoint, and an external webhook creates a cross-platform exposure that scales with every new connector added to its configuration. The risks of over-permissioned AI agents are not linear. They compound.
Shadow AI tools operate under the user's browser session. Shadow agents carry their own credentials. An agent built in maker mode uses the creator's credentials for every action it takes, regardless of who invokes it. A user without Salesforce access can invoke a maker mode agent built by a Salesforce administrator. That user now operates at the administrator's effective authority inside Salesforce. No IAM control flagged the access. The agent did exactly what it was designed to do.
This is the machine insider problem: the agent holds a non-human identity that bypasses the access controls governing human users.
Shadow AI is a single-step interaction. Shadow agents chain multiple actions across multiple systems in sequence. Action chaining is the mechanism by which a shadow agent's blast radius compounds. The agent queries a database, extracts a record, writes it to a document, and posts it to an external endpoint. Each step uses the same inherited credentials. Each step moves further from what the original workflow intended. By the time an incident response team reconstructs what happened, the chain is complete.
Shadow AI use is traceable to a human. Shadow agents are frequently orphaned. When the employee who built an agent leaves the organization, the agent does not stop. It continues running with the creator's embedded credentials, accessing systems the former employee no longer has rights to access as a human. The agent's owner account is disabled. The agent's access is not.
This is the orphaned agent problem: a credentialed, autonomous system with no active owner and no one responsible for its behavior.
The multiplication effect in shadow AI agent risk comes from the combination of autonomous action, inherited identity, and the absence of any runtime visibility layer.
Consider the difference between an employee using an unauthorized ChatGPT account and an employee invoking a shadow agent built in maker mode. The ChatGPT user submits data they already have access to. The risk is bounded by what they chose to upload.
The maker mode agent scenario is structurally different. A business user without Salesforce access opens a Copilot agent that a Salesforce administrator built using their own credentials. The agent was never reviewed by security. It is org-wide accessible. The business user asks the agent to summarize recent opportunities. The agent queries Salesforce using the administrator's credentials, returns restricted pipeline data, and logs nothing the security team can see. The user accessed data they had no right to see. The IAM controls governing their Salesforce access were bypassed entirely. The agent operated exactly as designed.
This is not a vulnerability in the traditional sense. It is a toxic combination: a shadow agent, configured in maker mode, with org-wide access, holding sensitive CRM data. Each factor is a medium-severity risk. Together, they are critical.
A shadow AI tool's blast radius is a function of what one user submitted in one session. A shadow agent's blast radius is a function of every system it connects to, every credential it holds, and every action it can chain across those systems.
Agents move data at machine speeds: 16 times the volume of human users, across platforms that have no unified visibility layer. Security teams end up ghost chasing: reviewing theoretical configuration signals with no runtime evidence of what the agents actually did or accessed. The architecture gap in agent security is precisely this: the tools built to catch shadow AI are not built to see what shadow agents do after they are invoked.
Security teams that have solved the shadow AI problem often believe they have addressed the shadow agent problem. They have not.
Cloud Access Security Brokers and Data Loss Prevention tools detect data movement at the network or browser layer. They catch an employee uploading a sensitive document to an unauthorized chatbot. They flag a prompt containing a social security number sent to a consumer AI tool. These are the right controls for the shadow AI problem. They are structurally blind to the agentic behavior that follows.
A shadow agent does not upload a document through a browser. It queries a SaaS API using an OAuth token, extracts records, and writes them to a connected system. That traffic looks like normal SaaS API activity. CASB tools see authorized application traffic. DLP tools see no user-initiated upload. Neither tool has visibility into what the agent was authorized to do, what it actually did, or whether the invoker had any right to trigger that access.
The visibility gap in the shadow AI vs. shadow AI agents comparison is not a gap in detection sensitivity. It is a structural gap in what these tools were designed to observe. Network-based detection sees traffic. Browser-based detection sees user-initiated prompts. Neither sees the action layer: the sequence of tool calls an agent makes after it is invoked, using credentials the security team cannot see in existing tooling.
Most security teams have theoretical configuration visibility. They can see that an agent exists and what connectors it has listed. They cannot see the agent's effective authority inside each connected SaaS application. They cannot see whether the invoker had any right to trigger the access the agent performed. They cannot reconstruct the action chain after the fact from native platform logs, which are siloed, inconsistent, and require unscalable manual correlation.
This is ghost chasing: reviewing configuration signals that tell you what could happen, with no runtime evidence of what did happen.
An agent's actions traverse the same API endpoints as legitimate SaaS integrations. A shadow agent querying Salesforce looks identical to a sanctioned Salesforce integration at the network layer. The difference is not in the traffic pattern. The difference is in the identity context: who built the agent, whose credentials it carries, who invoked it, and whether that invoker had any right to the data the agent returned. Network-based detection has no access to that identity context. It sees packets. It does not see the relationship between the runner's identity, the maker's credentials, and the downstream SaaS entitlements those credentials resolve to.
Solving the shadow AI vs. shadow AI agents problem requires two distinct detection layers working together, because the risks operate at different layers of the stack.
Shadow AI detection starts at the browser. A browser extension that monitors AI tool usage captures which AI applications employees access, whether they use personal or enterprise accounts, and what categories of data appear in prompts. This layer catches the shadow AI problem: unauthorized tool adoption, sensitive data in prompts, personal account usage on enterprise devices. It does not require SaaS connectors. It operates at the point where the human interacts with the AI tool.
Obsidian's free GenAI and Shadow SaaS detection tool provides a starting point for teams that need immediate visibility into shadow AI usage without a full deployment.
Shadow agent detection requires a different layer entirely. Security teams need a centralized inventory of every agent in their environment: who built it, what connectors it holds, what credentials those connectors use, whether the creator's account is still active, and what the agent's effective authority is inside each connected SaaS application. This is runtime truth, not theoretical configuration.
The inventory must answer the questions that native platform tools cannot: Is this agent running in maker mode? Is it org-wide accessible? Does the invoker have the right to the data the agent can reach? Is the creator account disabled? Does the agent connect to any unsanctioned or unregistered domains?
From that inventory, security teams can apply deterministic guardrails to probabilistic agents. Probabilistic agents deviate from intended behavior by design. Deterministic guardrails enforce fixed rules regardless of what the agent decides to do. Restricting maker mode agents from org-wide access, flagging orphaned agents for immediate review, and enforcing least privilege on agent connectors are deterministic controls that do not depend on predicting what the agent will do next.
Security teams facing shadow AI sprawl and shadow agent proliferation simultaneously should sequence their response: