Why Firewalls and EDR Still Miss Shadow AI

Most security teams already have a firewall, an EDR platform, and some form of SaaS monitoring. So when the topic of shadow AI comes up, the first question is usually: 

“Shouldn’t one of those tools already see it?” 

The answer is: sort of.

Your firewall may see traffic going to an AI provider. Your EDR may see a process running on an employee’s laptop. But seeing individual signals is not the same as understanding which AI tools are installed, who is using them, and what risk they introduce.

That gap is where shadow AI lives.

Shadow AI is no longer just a browser tab

The first wave of shadow AI was relatively easy to picture. Someone opened ChatGPT in a browser and pasted company information into it.

That still happens, but the AI tooling landscape has expanded considerably.

Today, an employee might be using:

• An AI coding extension inside VS Code
• A standalone editor such as Cursor or Windsurf
• A command-line agent running through Node.js or Python
• A desktop chat application
• A local model served through Ollama or LM Studio
• An AI agent running inside a Docker container
• An MCP server connected to several other tools

Some of these tools communicate with well-known cloud services. Others use generic APIs, enterprise gateways, or local models that never leave the machine.

That changes the discovery problem. Shadow AI is increasingly an endpoint inventory problem, not simply a matter of identifying traffic to a list of AI websites.

Can a firewall detect shadow AI?

Firewalls and secure web gateways are useful for identifying network traffic headed toward known AI services.

If a device connects to a recognizable AI domain, that is a valuable signal. It may tell you that someone is using an AI service, and it can help enforce policies around services that are explicitly blocked.

But network visibility has limits.

A firewall might see an HTTPS connection to an AI provider, but it may not know:

• Which application initiated the connection
• Whether it came from a browser, extension, CLI, or desktop app
• Whether the application is approved
• Which version is installed
• Whether the same tool is installed but not currently running
• Whether the employee is using a local model with no external traffic
• Whether the application routes requests through another service

Encrypted traffic makes attribution harder. Shared APIs make it even harder. Multiple tools may communicate with the same model provider, while one tool may switch between several providers.

The firewall can often answer, “Did this device communicate with a known AI service?”

It usually cannot fully answer, “Which AI agents are present on this device?”

Yes, those are related questions, but they are not the same question.

Can EDR Identify AI Tools?

EDR gets us closer because it has visibility into the endpoint.

It can see processes, files, hashes, signatures, and other system activity. In many environments, all the raw evidence needed to identify an AI tool may already exist somewhere in the EDR telemetry.

The challenge is context.

Consider a command-line AI agent implemented in Node.js. The EDR may report that node is running. That is accurate, but not particularly useful by itself. There may be dozens of legitimate Node.js processes running on a developer’s machine.

The same problem appears with:

• Python-based agents
• IDE extensions loaded inside a shared editor process
• AI tools distributed as npm packages
• Docker containers
• Locally hosted model services
• Applications that users rename or move

An EDR sees the process. It does not necessarily know that the process represents an AI agent, which agent it is, or whether the organization has approved it.

This is not a failure of EDR since they are designed to detect and investigate endpoint threats across an enormous range of software. Maintaining a constantly changing catalog of AI tools, extensions, package names, local artifacts, ports, and signing identities is a different problem.

The missing layer is AI-specific classification.

This is where an AI-specific discovery layer is important

Straiker Discover AI bridges this gap by inventorying the AI applications, agents, extensions, and MCP servers across your environment. Rather than treating processes or file artifacts as isolated events, it synthesizes disparate signals to identify active AI tooling and assess the confidence of each finding.

Rapid tool evolution, shared runtimes, and complex agent connections mean traditional mapping tools fail to capture the full picture. That’s why, instead of treating a Node process, an application bundle, an IDE extension, or a local configuration directory as isolated events, Discover AI can bring those signals together to determine what AI tooling is actually present and how confident the system should be in each finding.

The result is an actionable view of your environment—revealing what is running, how it connects, and what warrants attention. With this visibility, security teams can finally assess risk and apply appropriate controls.

Why shadow AI detection requires multiple signals

It is tempting to look for one perfect indicator of AI software. In practice, there usually is not one.

A process name may be too generic. A file path may remain after an application is removed. An installed extension does not prove that someone has an active license. An open port may belong to another service.

Reliable discovery comes from combining evidence.

For example, An AI tool might leave behind several of the following:

• An application bundle or executable
• A configuration directory in the user’s home folder
• An IDE extension with a known extension ID
• A globally installed package
• A running process
• A local service listening on a known port
• A registry entry on Windows
• A Docker image
• A code-signing identity
• Local conversation or usage records

Not all evidence should be treated equally.

A generic process such as node is weak evidence. A known application bundle with the expected signing identity is much stronger. A leftover configuration directory suggests that a tool was present at some point, but it does not prove that it is actively being used.

A useful inventory system needs to preserve that uncertainty rather than turning every match into a confident finding.

Security teams do not need another dashboard full of false positives. They need to know both what was detected and why it was detected.

Why aren’t application names enough? 

Basic discovery often relies on filenames and installation paths. That works until an application is moved, renamed, repackaged, or installed somewhere unexpected.

A deeper scan can inspect properties that are harder to change accidentally.

On macOS, that can include the application’s bundle identifier and code-signing Team ID. On Windows, it can include Authenticode signer information and version resources embedded in an executable.

This does not make detection impossible to evade, and it should not be presented that way. A determined attacker can modify or replace software.

But that is not the most common shadow AI scenario.

Most shadow AI is not malware trying to hide from a forensic investigation. It is an employee installing a useful tool without going through the organization’s approval process. In that environment, signing and version metadata provide much more durable identification than a filename alone.

Can you tell if an AI tool is actually being used? 

Finding an installed AI tool answers an important question, but not the whole question.

An organization may also want to understand:

• Is the tool actively being used?
• How frequently is it used?
• Is sensitive information being entered into it?
• Are credentials, API keys, or other sensitive information appearing in conversations?

This is where monitoring can quickly become uncomfortable.

Reading and centralizing employee prompts may technically answer some of these questions, but it creates a new set of privacy and security risks. Prompts can contain source code, internal discussions, customer information, credentials, and personal data.

A better approach is to process sensitive information locally whenever possible.

For example, an endpoint scanner can count conversations or token usage without collecting the conversation text. It can detect a credential pattern locally and report that a credential was found without sending the credential itself.

The resulting alert might contain:

• The type of secret
• Whether it appeared in a question or response
• Its approximate length
• A one-way fingerprint for correlation

That provides a useful security signal without turning the monitoring platform into a database of employee prompts and leaked credentials.

The telemetry exists, but the context is incomplete

Firewalls and EDR platforms remain essential. Shadow AI discovery is not a replacement for either one.

The problem is that each tool sees a different slice of the activity:

• The firewall sees network destinations.
• EDR sees endpoint events.
• The MDM platform knows which device and user are involved.
• An AI-specific scanner identifies the applications, extensions, runtimes, and local artifacts.
• Local analysis can add usage and risk signals without exporting sensitive content.

The useful result comes from connecting those signals.

The goal is not simply to produce a longer list of installed software. Security and IT teams need enough context to make decisions:

• Which AI tools are present?
• How confident are we in each detection?
• Which tools are approved?
• Which devices are affected?
• Which findings indicate installation versus active use?
• Which controls can be applied through the EDR, editor policy, or MDM platform?

That is the visibility gap shadow AI discovery needs to close.

So what is the best way security teams can find shadow AI?

The missing piece is an AI-specific view of the endpoint.

That's what Straiker's Discover AI is built to provide. It looks across applications, extensions, runtimes, packages, local models, MCP servers, and other artifacts to identify the AI tools and agents running in an environment. Instead of treating each artifact as an isolated event, it brings the evidence together so security teams can understand what they are actually looking at.

That inventory becomes the foundation for the rest of the security process. Ascend AI can test agents for vulnerabilities, while Defend AI protects them at runtime. For autonomous agents, Defend AI also includes an Agentic Kill Switch that can stop an agent when it needs to be taken out of action.

The existing security stack still matters. Firewalls, EDR, and MDM provide important pieces of the picture. Straiker adds the AI-specific layer that connects those pieces to the tools and agents actually running in your environment.

You Can't Govern What You Can't Identify

Shadow AI is growing because AI tools are useful, easy to install, and increasingly embedded in developers’ everyday workflows.

Blocking a list of websites will not reveal a local model. Looking for a process called Node will not identify the coding agent running inside it. An extension installed in an editor may never create an obvious standalone process.

Firewalls and EDR still provide important pieces of the puzzle. They just do not assemble those pieces into an AI inventory on their own.

Doing that requires an AI-specific discovery layer that understands the evidence these tools leave behind, treats uncertain findings honestly, and respects the privacy of the people using them.

If you want to see what that looks like in practice, talk to the Straiker team. We can walk through your environment, show you what Straiker can find, and demonstrate the protections running on systems and agents similar to the ones your team is using today.

In the next post, I will go into how we are building that layer using manifest-driven detection, confidence-weighted evidence, and separate quick and deep scanning modes.

Frequently Asked Questions About Shadow AI Detection

Can a firewall detect shadow AI?

A firewall can identify traffic to known AI services, but it usually cannot identify every AI application running on an endpoint. Local models, desktop applications, coding agents, extensions, and tools that route traffic through shared APIs can all fall outside traditional network visibility.

Can EDR detect shadow AI?

EDR can provide valuable evidence for finding AI tools, including processes, files, hashes, and other endpoint activity. The challenge is identifying what that activity represents. A generic Node.js or Python process, for example, does not tell you whether an AI agent is running inside it.

How do you detect shadow AI on endpoints?

Reliable shadow AI detection combines multiple signals, including applications, extensions, packages, processes, configuration files, local services, Docker images, and signing information. Those signals can then be correlated to identify the AI tool and determine how confident the finding is.

This is the approach Straiker takes with Discover AI, which is designed to give security teams visibility into AI agents, tools, MCP servers, and other AI components across their environment.

Does shadow AI include local AI models?

Yes. Shadow AI can include locally hosted models that never communicate with an external AI provider. Tools such as Ollama and LM Studio can run models directly on an endpoint, which makes them difficult to identify through network monitoring alone.

Can you monitor AI usage without collecting employee prompts?

Yes. Some usage and security signals can be analyzed locally without sending conversation content to a central system. For example, an endpoint scanner can identify credential patterns or measure usage while reporting the security signal rather than the sensitive content itself.

Why isn't traditional software inventory enough for shadow AI?

Traditional software inventory can tell you what applications are installed, but AI tooling often lives inside extensions, packages, runtimes, containers, local services, and other components that do not look like conventional applications. Shadow AI discovery requires understanding those artifacts in their AI-specific context.

For organizations that need to move from discovery into broader AI security, Straiker extends that visibility into AI security testing with Ascend AI and runtime protection with Defend AI.