Your endpoints are running AI agents you can't see

What is shadow AI on the endpoint?

Shadow AI on the endpoint refers to local AI software, LLM, and Model Context Protocol (MCP) server integrations deployed directly on employee hardware without procurement, security review, or identity governance. While browser-based AI poses data leakage risks, endpoint AI agents interact directly with local file systems and SaaS systems through MCP servers in the background.

The risk is no longer just about agents connecting through browsers. Now every employee can spin up multiple AI agents on their laptop. It's so easy that it's no longer only for technical roles. Anyone can do it. 

These agents supercharge velocity, but they create a messy identity problem: no central identity enforcement, no scopes, no audit trail, no access review. 

How MCP servers expand the endpoint attack surface

AI agents don't act alone. To do anything useful, an agent needs a way to reach different systems, and today that almost always means the MCP server. It’s the connective tissue between an agent and everything it can touch.

It takes only a few clicks to connect these agents to your organization's most sensitive applications through an MCP server. The agent lives on the device, but it makes calls that directly reach your CRM, SaaS apps, cloud infrastructure, and more.

The OWASP Foundation documents "MCP tool poisoning" as a critical attack vector, noting that because tool descriptions are typically reviewed only at initial connection, an attacker-controlled or compromised MCP server can alter tool metadata at runtime. Once connected, modified tool definitions are loaded into the model's context window to hijack execution and exfiltrate data.

If there's an incident, can your security team name these agents, who owns them, and which apps and data they can reach? Many can't.

And if you can’t answer that, you also can’t answer the first question in the blueprint for the secure agentic enterprise: Where are my agents?

Multiply that across every device, and the exposure compounds fast.

How do unmonitored AI agents bypass enterprise security controls?

Local AI agents bypass enterprise security controls by using unreviewed MCP connections, inheriting human user permissions without discrete agent identities, maintaining persistent standing access, and executing runtime tool modifications - all without generating central IT audit logs.

Behind these vulnerabilities sits a single root cause: a lack of endpoint visibility. When security teams can’t see AI agents or the MCP servers they connect to, standard identity and access management frameworks fail. 

Here are the five primary ways agents can bypass your controls.

1. MCP servers connect agents to business systems without your knowledge

Creating and connecting MCP servers that reach sensitive systems is fairly easy, and using them is a matter of running a single command in the terminal. Connecting an unapproved endpoint agent to your applications, for example, your Snowflake tenant, takes a matter of minutes. That AI agent now lives in your most sensitive system and can query every table it can see without you approving or knowing about it.

The promise of productivity pushes your employees to connect these servers to AI agents without thinking about the security implications.  

When security measures can’t keep up, critical connections remain unmonitored and unreviewed. That means a connection to your most sensitive data can sit there indefinitely, with no one accountable for what it touches and no record to check when something eventually goes wrong. That’s a breach waiting to happen.

2. Data moves between systems that were never centrally reviewed

An agent moves data based on its own judgment of what's useful for the task at hand. That judgment doesn't account for your data classification, residency rules, or who’s allowed to see what. Nobody approved that decision. There's no policy governing what the agent can access, so it ends up connected to multiple systems at once, and that combination is what creates the risk. 

For example, the same agent that can read customer data may also be able to email anyone. This is what broad permissions look like, giving your agents the ability to see more data than they need to complete a single action. The result: A single compromised prompt is all it takes to trigger a major breach.

3. Agents act through someone else's access, with no identity of their own

Agents typically authenticate to systems through an OAuth grant or an API key stored in the MCP server's configuration file. Once it's there, you don't have a reliable way to determine whether an action came from the person or the agent acting on their behalf. They are bound together under the same identity. So when something goes wrong, you can't answer the first question anyone will ask: Was that the person or the agent?

For example, an accounting employee’s agent updates a vendor payment record overnight. The log shows the change came from the employee's credentials, but there's no way to tell whether the employee made it or their agent did, and whether it was reviewed.

Answering the question of who acted means pulling logs from every system the agent touched and manually cross-referencing timestamps across formats that were never built to talk to each other. What should take minutes turns into days spent reconstructing a single action across disconnected systems.

4. Agents ask for permission only once and get standing access

Until a few months ago, most of us were still suspicious about what AI agents were doing. We stopped and checked whenever an agent needed additional permissions or wanted to call out to a system API. Now, we let them run autonomously. Agentic tools ship auto modes where the agent keeps working through tool calls on its own, with allow and deny rules you configure once.

Take this example: An employee assigns their agent a complex, long-running task and sets it to run automatically. Somewhere along the way, the agent decides on its own that changing records in Salesforce or Snowflake is the right way to complete the task, and it does so. The employee never approved that specific action and may not even realize it happened. Nobody reviews the change until something breaks or looks wrong.

5. The MCP server gives agents access that you don’t control

An MCP server provides your agent with a list of tools, each with a description explaining when and how to use it. Whoever wrote that server wrote those descriptions, not your IT and security teams. Your user saw a name in a menu and clicked “Approve,” without vetting who built the server or what it runs.

And the descriptions aren't fixed. If the MCP server owner edits a description, changes a permission, or adds a tool, your agent gets it automatically, no reapproval, no review. What ran on Monday isn't necessarily what runs on Friday.

Here’s an example: An employee adds a tool for their agent. The MCP server owner pushes an update that changes its behavior. The next time the agent connects, it inherits the new capability without an alert or a second approval.

How security teams can discover and secure endpoint shadow AI with Okta for AI Agents

You cannot scope, review, or revoke an agent you have never seen, and you cannot fully trust one you haven't brought under identity governance. 

Okta for AI Agents is built to close this gap.

1. Endpoint discovery: See each agent and MCP server running on the endpoint

Okta integrates with existing endpoint sensors, now available with CrowdStrike Falcon EDR, to discover AI agents and connected MCP servers. No extra endpoint agents required. This extends Okta’s discovery coverage to agents that run outside the browser and wouldn't otherwise surface through OAuth consent grants. Okta Verify is the next source we are bringing online, so endpoint discovery does not depend on any particular EDR, with support for additional EDR platforms planned afterward.

2. Register as first-class identities: Centralized directory enrollment

Agents are enrolled in Universal Directory alongside your other non-human identities, AI agents, and even human identities. Each agent is given a unique identity. With it, you can define what that agent can access and get a full audit trail.

3. Identity mapping and correlation: Binding agents to human owners

Discovered agents are linked to the specific authenticated human account, providing security teams with full visibility into human and non-human entities in one place. That mapping also holds up through change: As owners shift roles or leave, and as sub-agents are spun up in a delegation chain, the ownership context stays correlated rather than getting lost.

4. Runtime authorization: Policy enforcement at the point of action

Enforce the access policy each time a tool call executes, not just once at setup, with Agent Gateway. Agents hold only short-lived tokens rather than standing credentials, and access can be revoked instantly at the gateway, without waiting for the next access review to detect changes.

5. Ongoing access governance: Access reviews and access revocation

Run periodic access reviews that include agents alongside human identities, so security teams can prove to auditors that every agent's access was reviewed and approved. And when an agent deviates or is compromised, a kill switch deactivates it and terminates new access across every connected system it touches.

Gain control of your enterprise AI

Get the blueprint for the secure agentic enterprise to learn more about securely scaling your enterprise AI.

Availability: The Shadow AI Agent Discovery for Endpoints feature is now available in Early Access for Identity Security Posture Management and Okta for AI Agents customers through the CrowdStrike Falcon EDR integration. If you already run CrowdStrike, the sensor you have is the source, and nothing new goes onto the endpoint.

These materials are intended for general informational purposes only and are not intended to be legal, privacy, security, compliance, or business advice. You are responsible for obtaining security, privacy, compliance, or business advice from your own professional advisors. Any mention of future products, features, functionalities, or certifications in this blog is for informational purposes only. These items are not commitments to deliver and should not be relied upon to make purchasing decisions. © Okta, Inc. and/or its affiliates 2026.