A routine endpoint deployment at a mid-market company turned up a shadow AI agent with write access to source control, running from a sales laptop. Here's what that setup looked like, why it slipped past every existing security tool, and what we'd tell a security team to do about it.
We deployed our endpoint agent at a mid-market company a few weeks ago. Standard rollout. The security team expected to find what everyone expects to find: a handful of engineers using AI coding tools, some ChatGPT usage on personal accounts, maybe a Gemini desktop app nobody had approved.
The most interesting thing we found was on a sales laptop.
Someone on the revenue team, not an engineer, had installed Claude Code. Not as a curiosity. He was actively using it. He had connected a local GitHub MCP (Model Context Protocol) server so the agent could read and write to repositories, and installed Playwright so the agent could drive a browser on his behalf. Nobody in security knew. Nobody in engineering knew. He had not broken a single policy, because no policy covered any of it.
What the Setup Actually Looked Like
Three things stacked on top of each other.
- A GitHub personal access token, sitting in a config file in plaintext. This is worth being precise about: it was not a mistake or carelessness. It's what the setup instructions tell you to do: generate a token, paste it into a config file, the agent picks it up. The documented happy path for connecting an MCP server ends with a long-lived credential in plaintext on a laptop, and the person following those instructions has no reason to think anything is wrong. Security awareness training doesn't fix a problem that lives in the vendor's own quickstart guide.
- A browser automation framework, installed without a mental model of what it can reach. He wanted the agent to click through some things for him. What he installed was a headless browser that inherits sessions, authenticates as him, and can navigate to anything he has access to. He couldn't have told you what that meant if asked, because nothing in the install process asks you to think about it.
- An agent with a general-purpose loop connecting the two. Read from a repo. Drive a browser. Write to a repo. All of it running as him, on a machine with his credentials, outside the browser and outside any network path that was being monitored.
Separately, each of these is a known quantity with a known answer. Together they are a write-scoped credential to source control, a browser that can authenticate as an employee, and an autonomous process with the ability to chain them, running on a laptop that isn't in anyone's developer tooling inventory. No single step in that setup asks who is running it or what the other two steps are.
Why This Profile Is Harder Than the Engineer Version
Security teams have largely accepted that developers use AI coding agents. That risk is understood, if not fully controlled. Engineers, on the whole, know what a token is, know a headless browser has a session, and have some instinct for blast radius even when they ignore it.
This is the other case: engineer-grade tooling in the hands of an operator who has none of that context, and no reason to acquire it. The tools are one npm command away, and the instructions are written to remove friction, not to make you think. That combination is going to become normal much faster than most security teams have planned for.
The exposure here isn't that a salesperson used AI. It's that a valid, write-scoped credential to source control now lives in plaintext on an endpoint outside the developer tooling inventory, handed to an autonomous loop that can also authenticate to internal web apps.
Look at what is now one step away. The same person, the same laptop, the same pattern of following a quickstart: connect the HubSpot MCP server, and the agent can pull account records into a repo under a personal GitHub account, authorized by a token in plaintext that no one issued, on infrastructure that doesn't appear in any inventory. Nothing about that next step is harder than what he already did. It's the same three commands.
Why Nothing Else Caught It
It is estimated that 89% of enterprise AI usage is invisible to the organization and this case is an illustration of why. It wasn't a coverage gap in the sense of a missing rule. It was a category that existing tooling doesn't observe at all.
- DLP and CASB watch network traffic. This traffic was an agent speaking MCP over stdio to a local process. There was nothing on the wire to inspect.
- Browser security tools watch the browser. This happened at the OS layer, and the browser involved was one the agent itself had spawned.
- Endpoint tools watch for malware. Everything here was a legitimately signed, legitimately installed developer tool.
- Procurement and IT asset inventories watch purchases. All of it was free.
Four categories of tooling, all working correctly, none of them able to see the risks let alone control for them.
What We'd Tell a Security Team to Do About It
Some of this is product-agnostic and worth doing regardless of what you buy.
- Inventory the agent surface, not just the AI vendor list. Knowing that people use Claude and ChatGPT tells you a part of the story. Knowing which MCP servers are installed.
- Assume the operator is not an engineer. Any control that depends on the user understanding what a token or a browser session is will fail. Design for the person who followed the quickstart.
- Treat credentials in agent configs as standing grants, not secrets. A personal access token in a config file isn't a secret that might leak. It's a permanent, delegated authorization to an autonomous process. Scope and rotate accordingly.
- Watch the tool calls, not the install. The install is one event with no context. The tool calls are where intent shows up: what the agent asked for, what came back, and whether it drifted from what it was originally asked to do.
How MagicMirror Helps
That last point, watching the tool calls, is where MagicMirror sits.
- On-device tool-call classification: Our MCP proxy wraps the MCP servers an agent talks to and classifies every tool call before it executes, running on-device so nothing is sent to a cloud service for analysis.
- Full agent-surface visibility: See which MCP servers, credentials, and agent tools are actually in use across the organization, not just which AI vendors are approved.
- Policy that follows the tool call, not just the install: Enforce allow / protect / block decisions at the moment a tool is invoked, so intent and drift are visible in real time rather than after the fact.
Ready to See Your Full Agent Surface?
The AI security question is no longer "which tools are our employees using." It's "what are those tools authorized to do, and who set that up." Book a demo to see how MagicMirror gives you visibility into the agent surface (MCP servers, credentials, and tool calls) that traditional AI governance tools can't see.
.jpg)
