Securing the AI Workforce: MCP & Shadow AI Detection for a Lean Security Team
As internal teams wired copilots, MCP servers, and autonomous workflows directly into production systems, the security function - two people, no AI specialists - had no inventory of what agents could reach, let alone what they were doing with it.
What we were solving
Mid-market SaaS company, roughly 400 employees, lean security team with no dedicated AI/agent security specialist, adopting Microsoft 365 Copilot and several internally built agent workflows in parallel.
- Engineering and ops teams had connected AI agents to internal APIs and data stores faster than security could track them - a classic shadow AI pattern.
- Existing endpoint and SIEM tooling had no visibility into MCP sessions, tool calls, or agent-to-agent handoffs - the traffic simply didn't register as anything.
- The security team could not credibly tell leadership what agents could access, which made every new AI initiative a governance argument instead of a rollout.
What we built
- Ran a discovery sweep across network egress, API gateways, and CI/CD configs to build a full inventory of MCP servers, agent frameworks, and copilot integrations already in use.
- Classified every discovered agent by data sensitivity and blast radius, then applied a zero-standing-trust policy so agents authenticate per tool call rather than holding long-lived credentials.
- Instrumented prompt, tool-call, and response telemetry into the client's existing log pipeline so agent activity became just another correlated data source - not a bolt-on dashboard the team had to context-switch into.
Architecture notes for your engineers
- Deployed as a sidecar/proxy in front of MCP endpoints so instrumentation required no changes to the agents or tools themselves.
- Policy engine denies-by-default on any newly discovered MCP server until it is triaged - preventing silent sprawl going forward.
Key results
- 40+ MCP servers and agent integrations inventoried in the first discovery sweep
- Zero-standing-trust enforced on every agent-to-tool call within the quarter
- Agent activity correlated into the team's existing SIEM - no new console to babysit
- AI rollouts became a security-approved checklist instead of a standing argument
What it was built on
Representative tools and patterns — exact vendors vary per client environment.
Agent visibility
Governance
Integration
What we'd tell the next team
- Shadow AI shows up as normal-looking API traffic - you have to go looking for it, it will not show up in an alert queue on its own.
- A two-person security team can govern AI agents at scale if the tooling folds into what they already monitor - a bolt-on console guarantees it gets ignored.
- Deny-by-default on newly discovered agents is the only way to stop sprawl from outrunning governance a second time.
Questions this engagement anticipated
What is 'shadow AI' and why is it hard to detect?
Shadow AI is employees or teams wiring AI agents, copilots, or MCP servers into company systems without security review - it looks like ordinary API traffic to conventional tooling, so it goes undetected until someone specifically instruments for agent and tool-call telemetry.
Can a small security team realistically govern AI agents without hiring specialists?
Yes, if agent telemetry is folded into the monitoring the team already does rather than added as a separate console - the governance model here was sized for a two-person team from day one, not retrofitted from an enterprise playbook.
This is one of several case studies on ai agent security & autonomous operations.
See the rest of the cluster →Compare your situation to this case.
Bring your constraints - environment, timeline, and budget. We scope before we quote.