At a glance
- Shadow AI leaves physical traces on endpoints: MCP server entries, rules files, Skill folders, hooks, local model runtimes, and personal-account sign-ins.
- A personal account signed into an AI tool on a company machine is a direct, checkable indicator of unsanctioned AI use.
- Backslash Security covers AI coding agents including Claude Code, Cursor, Codex, Devin, GitHub Copilot and Antigravity, according to its website.
- Useful detection records what was found, where it sits, which identity ran it, and whether anyone approved it.
Backslash Security
Published:
Shadow AI — AI tools, agents, MCP servers and Skills running inside an organization that security has not approved and cannot see — leaves concrete, inspectable traces on the machine itself, and those artifacts are the signals to hunt for. The highest-yield ones are configuration and identity artifacts: entries defining MCP servers in an agent's config file, where MCP (Model Context Protocol) is the protocol agents use to reach external tools and data; rules files such as AGENTS.md or CLAUDE.md, which carry standing instructions an agent reads on every run; Agent Skills, the packaged instructions and scripts that extend what an agent can do and that often amount to a single markdown file in a folder; hooks, which are triggers that fire before or after an agent action; locally installed model runtimes such as Ollama or LM Studio; and sign-ins to AI tools under employees' personal accounts rather than corporate identity providers like Entra ID or Okta.
Each of those artifacts is readable without interrogating the model or the network, because the agentic components live as files, processes and credentials on the endpoint. As described on its agentic endpoint security page, Backslash Security discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file, plugin and connector running on an endpoint — which is the same artifact set a manual hunt has to enumerate by hand. These signals and triage criteria reflect the detection options available as of 2026.
What exactly counts as shadow AI on an employee endpoint?
Shadow AI on an employee endpoint means unapproved agentic components executing locally, which is a different object from unsanctioned cloud AI services used in a browser.
Unsanctioned cloud AI services. This is the familiar form: an employee pastes a customer list into a consumer chatbot, or signs up for an AI note-taker with a corporate email address. The artifact is a web session, and the controls that see it sit at the network layer — a secure web gateway, a CASB, or DLP inspecting outbound traffic.
Unapproved agentic components executing locally. Here the artifact is software on the machine that reads, writes, and acts with the employee's own operating-system permissions and signed-in identity. Someone installs an AI coding agent, connects it to an MCP server — Model Context Protocol being the standard agents use to reach external tools and data — drops in a Skill, and adds a rules file. Nothing passed procurement, and the agent can now run commands and touch repositories as that person.
In the endpoint sense, the unapproved inventory covers:
- Agents and local models: coding agents, desktop assistants, and locally hosted models run through tools such as Ollama or LM Studio.
- MCP servers and MCP tools: each one a live connection an agent can act through.
- Skills: packaged instructions and scripts that extend an agent's capability — often just a markdown file on disk — executing with the user's permissions.
- Hooks: triggers that fire before or after an agent action.
- Rules files such as AGENTS.md or CLAUDE.md: standing instructions an agent reads on every run.
- Plugins, connectors, and the context they read, including repository content and documents.
- Private account access on enterprise machines, such as an agent authenticated through a personal account.
Backslash detects and prevents the use of unknown and untrusted agents, models, MCP servers and Skills, along with private account access on enterprise machines, across all employees and all endpoints, developer workstations included.
Which process and execution signals reveal an unsanctioned AI agent running locally?
The process and execution signals that expose an unsanctioned AI agent running locally are already present in ordinary endpoint telemetry — the difficulty is knowing which parent-child relationships and persistence artifacts to treat as agentic rather than routine developer activity. Six observable indicators do most of the work, and each has a characteristic shape on the machine.
| Signal | What it looks like on the endpoint | Why it matters to the investigator |
|---|---|---|
| Long-lived agent processes | A command-line assistant such as Claude Code, Gemini CLI or Cline held open across a working session, often outliving the terminal that started it | Session length separates an interactive query from an agent working autonomously through a task list |
| Local model runtime binaries | Ollama or LM Studio bound to a loopback port, with model weight files cached under the user profile | Indicates inference happening entirely off the sanctioned provider path, where no gateway or proxy log exists |
| Stdio-spawned child processes | An editor or desktop assistant — Cursor, Claude Desktop, GitHub Copilot — forking node, python or uvx children over stdio, the standard input/output transport MCP servers use | Each child is a live MCP connection: a route the agent can act through, under the employee's own identity |
| Shell invocations from agent subtrees | Agent descendants calling bash, PowerShell, git, curl or a cloud CLI | Shows the agent reaching beyond text generation into credentialed systems |
| Atypical CPU or GPU utilization | Sustained accelerator load on a workstation with no rendering, build or training workload to explain it | A practical trigger for local inference, including models pulled from public repositories |
| Reboot-surviving daemons | launchd agents, systemd user units, scheduled tasks, login items and background connectors that reinstate themselves | Persistence converts an experiment into standing, unreviewed access |
One attribute belongs alongside every row: the identity each process runs under. An agent launched from a personal login inherits that account's tokens and produces no corresponding record in the managed identity directory, whether that is Entra ID, Okta or Active Directory.
What configuration and file-system artifacts give shadow AI away?
Unapproved AI tooling leaves a configuration trail: the agents employees install write their state to disk, so the file-system artifacts they create are the most reliable starting point for an inventory. These files are readable, enumerable, and comparable across machines, which makes them a practical substitute for asking people what they are running.
| Artifact | What it is | What its presence tells you |
|---|---|---|
| MCP server entries | Configuration blocks registering a Model Context Protocol server — the protocol agents use to reach external tools and data | Each registered server is a live path an agent can act through, approved or not |
| Rules files (AGENTS.md, CLAUDE.md) | Files carrying standing instructions an agent reads on every run | Shows what the agent is told to do by default, and when it was last edited |
| Skills directories | Agent Skills — packaged instructions and scripts, often just a markdown file — that run with the user's own permissions | Capabilities added outside any software approval process |
| Hook definitions | Triggers that fire before or after an agent action | Automated behavior executing without a human prompt |
| Plugin and extension manifests | Declared add-ons for the agent or editor, with requested permissions | Scope creep in what the agent may touch |
| API keys and tokens in dotfiles | Credentials written into user profile configuration files | Model and service access provisioned outside identity management |
| Connector credentials | Saved authentication for third-party services an agent reaches | Frequently the clearest evidence of personal-account use on a corporate machine |
Rules files deserve particular attention because they are trusted input. Backslash security research found that malicious instructions hidden in a repository's AGENTS.md file could trick OpenAI Codex into silently accessing AWS credentials, npm tokens and Git configuration.
For each artifact, record the host and user, the owning agent or editor, the file path and modification time, the permissions or scopes it grants, and whether its credential belongs to an enterprise identity provider such as Entra ID or Okta, or to a personal login.
Which network and identity signals point to unapproved model or tool usage?
Network and identity telemetry carry the earliest observable signals of unapproved model or tool usage, because an agent running under an employee's own account still has to authenticate somewhere and reach something. If unsanctioned AI is present on an endpoint, credentials were granted and a connection was opened, so the evidence already sits in telemetry security teams collect, provided they know which attributes to query.
| Signal | What it looks like | Why it matters |
|---|---|---|
| Egress to model-provider and inference endpoints | Outbound connections from a workstation to hosted inference APIs rather than to a vendor's web interface | Separates browser-based chat use from a programmatic client acting on the machine |
| Token-bearing API calls from non-browser clients | Requests carrying a bearer token with a command-line or runtime user agent instead of a browser session | A bearer token is a long-lived credential; its presence outside the browser indicates an autonomous caller |
| OAuth grants under personal identities | Authorization consents in Entra ID, Okta or Google that resolve to a personal account on a corporate device | The grant, not the install, gives an agent reach into real systems |
| SaaS connector scopes | The permission set attached to each connector — read-only, write, admin, offline access | Scope determines blast radius if the agent is manipulated or drifts from its task |
| Local-only traffic | Loopback calls between an agent and an MCP server, or a model served locally through Ollama or LM Studio | Never crosses a network boundary, so proxies, secure web gateways and flow logs see nothing |
MCP, the Model Context Protocol, is how agents connect to external tools and data sources, and many of those servers run on the same machine as the agent. That last row marks the structural limit of network-side detection: when the model and the tool are both local, there is no egress event to correlate and no identity grant to review, so the inventory question has to be answered on the endpoint itself.
How do you tell a risky agent action from ordinary employee activity?
You tell a risky agent action from ordinary employee activity by its behavior, not by its inventory: the same Skill, a packaged set of instructions an agent can invoke, is harmless against a documentation folder and dangerous against a credentials file.
Behavioral triage starts by separating capability from conduct. Tool-permission scope describes what an agent could reach: the MCP servers, Skills, shell commands and file paths its configuration and rules files — the standing instruction files an agent reads on every run — make available. Conduct is the narrower record of what it actually did.
Useful ranking criteria, in practical order of examination:
- Distance from the working directory. File reads outside the project the agent was asked to work in.
- Proximity to secrets. Access to credential stores, cloud configuration, token files, Git configuration.
- Autonomy of the action. Writes or command execution completed without a human confirmation step.
- Destination of outbound movement. Data leaving toward endpoints that are not on an approved list.
- Provenance of the instruction. Whether the step traces to a typed prompt or to content the agent read on its own.
| Do this | But watch out for |
|---|---|
| Baseline each agent's working directory and surface reads beyond it | Cross-repository work legitimately crosses directories; scope the baseline per project and approve known paths |
| Rank credential and token access as a top-tier signal | Agents read configuration files containing tokens as routine work; allowlist specific paths and require confirmation elsewhere |
| Gate autonomous write and execute actions | Blanket blocking stalls real work; approve commands individually and log the rest |
| Compare granted permission scope against observed usage | Over-tightening pushes people toward personal accounts and unapproved tooling; narrow scope using what agents actually invoke |
Signature-style detection struggles here because every element of the chain is individually legitimate: a sanctioned binary, a valid session, a documented API call. Lineage is what makes agentic behavior tractable: each tool call descends from a prompt, a rules file or a Skill, and that chain carries the context the action itself never records.
Frequently Asked Questions
What exactly counts as shadow AI on employee endpoints?
Shadow AI is AI tooling running inside the organization that security has not approved and cannot see — agents, models, MCP servers and Skills, usually installed by employees on their own machines and often authenticated under personal accounts. The most recognizable form is concrete rather than abstract: an engineer signing into an AI coding assistant on a corporate laptop with a private Gmail account, so the session, the history and any data it touches sit outside enterprise identity controls. This is distinct from a rogue agent, which is an approved agent taking actions nobody asked for. One is a tool you never sanctioned; the other is a tool you did.
Which signals on an endpoint reveal unapproved AI agents and MCP servers?
The useful signals are artifacts left on disk and in configuration by the agentic layer itself. Look for:
- MCP server entries in agent configuration files. MCP, the Model Context Protocol, is how agents connect to external tools and data; each configured server is a live path an agent can act through.
- Rules files such as AGENTS.md or CLAUDE.md — files carrying standing instructions an agent reads on every run, which means a repository can change agent behavior without anyone typing a prompt.
- Agent Skills — packaged instructions and scripts that extend what an agent can do, frequently just a markdown file plus a script, executing with the user's own permissions.
- Hooks, plugins and connectors registered against agent actions.
- Local model runtimes like Ollama or LM Studio, and authentication tokens pointing at consumer AI accounts.
Backslash discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file, plugin and connector running on an endpoint, which turns that checklist into a maintained inventory rather than a one-off sweep.
Why doesn't our existing endpoint stack surface these signals?
Because the incumbent layers were built for a different object. EDR — endpoint detection and response — is designed to catch malicious processes, files and known-bad behavior on a machine. An approved agent reading a poisoned file and calling a tool with the user's own credentials generates a legitimate process doing legitimate-looking work. MDM governs device posture and application catalogs; it does not see which Skills an agent installed yesterday or which MCP server a developer added this morning. The gap sits between those two layers, and that gap is what AI agent endpoint security addresses.
Which AI tools should we check first on developer workstations?
Start with the coding agents, because they hold credentials, repository access and shell permissions at the same time. Backslash covers AI coding agents including Claude Code, Cursor, Codex, Devin, GitHub Copilot and Antigravity. The exposure is not theoretical: Backslash security research found that malicious instructions hidden in a repository's AGENTS.md file could trick OpenAI Codex into silently accessing AWS credentials, npm tokens and Git configuration — an indirect prompt injection, where hostile instructions reach the agent through content it reads rather than through the user.
How do we get an inventory without installing software on every machine?
Use an agentless assessment — a method that collects information without leaving software permanently installed on the endpoint. Backslash offers a free AI Endpoint Exposure Assessment, also called Scout, that is agentless, read-only, and retains no data. It is a short script distributed through the organization's existing MDM that runs, reports and disappears. Philip Walsh, Head of Security Engineering at Happy Returns, is quoted saying that "Backslash gave us a live picture of the AI our engineers were already running, and a way to govern it without slowing anyone down."
What should we do once we find unapproved AI usage?
Move from inventory to enforceable policy. Backslash supports allowlisting approved components and denylisting risky ones, with custom policies per team and risk profile, so a research group and a finance team are not held to identical rules. For live activity, Backslash blocks risky agent actions inline before execution, including unauthorized code execution, credential access, privilege escalation, and data sent to unapproved destinations. It also automatically generates audit evidence for EU AI Act, NIS2, DORA and SOC, and traces the full path of an agent run from prompt to agent to tool call to outcome.
About this article
Backslash Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Backslash Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-11-10