Catch Unsanctioned MCP Servers

To catch unsanctioned MCP servers, you first have to agree on what makes one unsanctioned, and the answer is not technical. An MCP server is unsanctioned when it runs in your environment without security review, without an approval record, and without a named owner. It might sit on a developer laptop, inside Cursor, attached to a Copilot Studio agent, or wired into an n8n workflow. The binary is identical either way. What changes is the governance state around it.

Three practical signals put a server on the wrong side of the line:

• No entry in your MCP server inventory or approval workflow.
• No named owner accountable for the credentials it holds.
• A connection to production data or a business app that never passed a change review.

Two byte-for-byte identical servers can land on opposite sides of that line, one because a human reviewed it and one because nobody did. So detection has to be tied to your approval record, not a signature list.

Sanctioned versus unsanctioned, side by side

A sanctioned server has an owner, an approval record, a known tool set, a documented data scope, and a place in your inventory. An unsanctioned one has some or none of that.

The same server can read as sanctioned in one platform and unsanctioned in another. Governance state is per environment, not per binary. That is why a static allowlist of "approved" servers falls apart the moment the same tool shows up in a tenant you do not manage.

Developers add MCP servers the way they used to add packages. It takes minutes. Approval takes weeks. That gap is the whole story.

The volume behind the gap is real. Agents move roughly 16 times more data than the humans they work alongside, and studies of agent estates put around 90 percent of them in an over-permissioned state. Every new agent needs tools, every tool needs a connector, and MCP is the standard developers reach for. Counts climb quietly, per team, without a central record.

Each new server is a new bearer-token holder, a new set of embedded credentials, and a new potential path from an agent to sensitive data. Change control assumes weeks of lead time. Agent teams ship in an afternoon. Review as a gate has already lost that race. Detection at runtime is what replaces it.

How they get added

Usually a developer or a business user adds a server to give an agent one more capability. Inside most agent builders it is a few clicks, and no admin approval is required by default. The person adding it is solving a delivery problem, not making a security decision, which is exactly why the server never reaches a reviewer.

Discovery has to be cross-platform, or you are grading your own homework. A server registered in Copilot Studio, another in Cursor, and a third in a Bedrock agent are three separate problems unless one place sees all of them.

A working discovery process:

1. Ingest from every platform where agents live. Copilot Studio, Salesforce Agentforce, Amazon Bedrock, Google Vertex, ServiceNow, Snowflake Cortex, Moveworks, n8n, ChatGPT Enterprise.
2. Capture registrations at runtime. Each time an agent invokes a tool, record the server, the tool, the calling identity, and the app entitlement the call resolves against.
3. Add browser telemetry for developer tools. Cursor, Claude Desktop, and similar tools expose MCP usage that never touches enterprise APIs. A browser signal closes that gap inside enterprise app contexts.
4. Match every server against the approval record. Anything absent from the record is unsanctioned by default.
5. Assign an owner or quarantine. An unowned server should trigger ownership assignment or lose access.

The output is not a list. It is a graph that connects agents, identities, servers, tools, and the downstream app reach behind each one.

Why the network is the wrong place to look

Security teams often ask how to detect unauthorized MCP servers on the network. You do not. Network detection fails for concrete reasons:

• MCP traffic rides inside authenticated app API calls that look identical to legitimate integration traffic.
• Many servers run inside developer tools that never cross your egress in a distinguishable way.
• The tools inside a server are enumerable only at runtime, when an agent calls them. A static scan sees the door, not the rooms behind it.

Runtime truth comes from the platforms themselves, through native APIs and webhooks, not from a packet capture.

Two servers can sit next to each other in inventory and carry completely different exposure. Rank by effective access, not theoretical configuration. Effective access is what the server can actually do once every entitlement resolves inside the apps it touches: which service account it runs as, and which specific tables, objects, and actions that account can read or write. Theoretical configuration is what the setup file claims. The two disagree constantly, and only the runtime view catches the difference. That correlation, from an agent's activity to its real reach inside the third-party app, is the moat. A vendor's config page cannot tell you a low-privilege agent is one tool call away from your entire customer object.

A useful ranking signal set:

• Downstream reach. Which apps does the server touch? A CRM holding customer records, or a public weather API?
• Sensitive data scope. Does the resolved permission set include labeled sensitive files, PII, or financial records?
• Credential model. Does the server run with fixed creator credentials that every invoker inherits? That pattern, sometimes described as a maker-style setup, turns any low-privilege user into an admin-level extractor.
• Owner status. Is the creator account still active, or is this an orphaned agent still holding live credentials?
• Exposure surface. Is the connected agent org-wide or publicly reachable?
• Toxic combinations. Shadow server, plus org-wide access, plus sensitive data is a critical finding even when each factor alone reads as medium.

The point of ranking is triage. Security teams do not need 500 tickets. They need the three servers that could move customer records this afternoon.

Can an unsanctioned server actually exfiltrate data

Yes. By definition it holds tokens or credentials nobody in security has reviewed. If those credentials touch production data, the server can move that data anywhere its tool calls allow. Realistic paths look mundane: a developer wires a server to a CRM with their own admin session, and every invoker inherits admin reach; a community-shared server quietly forwards prompts and results to an outside endpoint; an orphaned server keeps running after its creator leaves, credentials still valid. None of these need a novel exploit. The 2025 UNC6395 campaign against the Salesloft Drift integration reached roughly 700 organizations by abusing exactly this class of connected access, not a zero-day. The missing controls are an inventory and runtime observation, and both are common gaps.

Split dashboards create split accountability. Every server, sanctioned or not, needs to appear in one inventory next to the agents that use it and the identities behind those agents.

One view here means a single screen shows:

• Every server discovered across every platform.
• Sanctioned status, owner, and approval record.
• The agents attached to each server.
• The identities, human and non-human, that invoke those agents.
• Effective access: what each server can actually reach in connected apps.
• A risk score that reflects blast radius, not presence.

Without that, servers live in the seam between teams: IT owns the platforms, security owns the risk, developers own the servers, and the unsanctioned ones fall through the middle. A unified inventory is what lets an owner answer "what would this reach if it went rogue" in one look instead of a week of correlation.

Discovery without enforcement is expensive logging. The operational goal is stopping an unauthorized tool call before it completes, and doing it without inserting an inline proxy that adds latency and a new failure mode in the traffic path.

Obsidian works as a decision engine, an Intel Inside model rather than a hop in the network. Runtime signals feed a policy engine; when a call violates policy, the decision fires back through the platform's own native hook, which cancels the action. No packet interception, no new choke point.

Here is the honest state of that capability today. Discovery, inventory, and blast-radius ranking are available now across the platforms listed above. Autonomous blocking is live today for Microsoft Copilot and Claude. For Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Bedrock, Vertex, and n8n, the same enforcement is on the roadmap, delivered as each platform's hooks mature. Until then, those platforms are covered by discovery and governance, and enforcement is where the roadmap is headed, not where it is today.

What to do the moment you find one

Act in order:

1. Identify the owner or last creator. If the account is disabled, treat the server as orphaned and quarantine it.
2. Enumerate downstream reach. Which apps, which data, which identities have invoked it.
3. Check for credential inheritance. If invokers can pull data beyond their own permissions, this is a priority-one finding.
4. Revoke or scope down credentials. Do not delete the server before you understand what it touched.
5. Add it to inventory with a sanctioned or blocked status. Every server ends up on one side of the line.
6. Post-mortem the pathway. Trace how it got created without review, then fix the approval flow so the next one cannot.