In my previous post I outlined the highest-leverage controls for MCP in 2026: OAuth 2.1 with audience binding, tool-level least privilege, supply-chain attestation plus definition pinning, and runtime inspection with human gates for high-impact actions. Dean asked the natural next question: How do we actually determine whether the MCP servers running in a client’s environment are following that guidance?
The short answer is that you treat MCP servers the same way you treat any other high-privilege integration layer. You inventory them, measure them against the controls, and continuously verify that the approved state still holds. Here is a practical approach that works in real client environments.
I was up at 2am when Dean asked the question, due to flooding in our area and dealing with a flooded basement, so I had all night to dig in and build this post. So, you can thank Dean and acts of God.
You cannot assess what you cannot see. Start by discovering every MCP server that agents can reach.
Endpoint and client configuration discovery: Scan known configuration locations used by Claude Desktop, Cursor, VS Code, Windsurf, and similar tools. Microsoft Defender for Endpoint now surfaces local AI agents and their associated MCP server configurations (both local and remote) on onboarded devices and makes them available in the portal and advanced hunting.
Network and gateway visibility: Use secure web gateways or MCP-aware proxies that can identify MCP traffic patterns, destinations, and whether connections go through approved portals or bypass them.
Central registries and platforms: Check Azure API Center, internal MCP registries, or organization-managed catalogs for registered servers. Shadow or ad-hoc servers will not appear here, which is useful signal.
Automated scanners: Tools such as mcp-scan (and related variants) can walk client configs, enumerate tools, and flag obvious issues across stdio, HTTP, and SSE transports.
The goal is a single inventory that lists server name or endpoint, transport type, tools exposed, authentication method, and ownership. Without this baseline, every later check is incomplete.
For every remote MCP server, confirm it behaves as a proper OAuth 2.1 resource server.
Confirm the server requires authentication and rejects unauthenticated requests.
Verify tokens are audience-bound (resource indicators per RFC 8707). The server must validate that the token was issued specifically for it and reject anything else.
Check that tokens are not simply forwarded or passed through. Proper token exchange for narrowly scoped credentials should be in place.
Review token lifetime, PKCE usage, and whether long-lived or ambient credentials still exist.
Practical checks include reviewing authorization server configuration, inspecting token claims in test flows, examining server logs for audience validation failures, and testing with tokens issued for other resources. Missing audience validation or token passthrough is a clear failure against the guidance.
Server-level permissions are no longer sufficient. Examine the actual tools.
Enumerate every tool the server advertises (name, description, parameter schema, and capabilities).
Verify that permissions are scoped to individual tools rather than the entire server, and that argument constraints exist where possible.
Confirm a deny-by-default allowlist is in place. Admitting a server should not automatically trust every tool it offers.
Prefer read-only defaults. Any tool that mutates state or reaches sensitive data should require explicit elevation and, for high-impact actions, human approval.
Scanners that inspect tool schemas and over-privileged combinations (shell + filesystem, unrestricted network, sensitive path access) accelerate this work. Manual review of allowlists and elevation policies fills the gaps that automation misses.
A clean server at approval time is not enough. Confirm the organization can detect later change.
Require cryptographic attestation or signed clearance before a server is admitted to production agents.
Pin tool definitions and schemas (hashes of name + description + parameter schema). Alert or block on drift.
Treat registry packages and remote servers with the same rigor applied to critical open-source dependencies: signed artifacts, immutability where possible, continuous monitoring for ownership or behavioral changes, and a governed allowlist.
Tools that perform tool pinning and rug-pull detection by comparing current tool lists against stored fingerprints are useful here. Any server whose tool definitions change without a controlled change process fails this control.
Static approval is only the starting point. Runtime behavior must be observable and controllable.
Inspect tool calls, arguments, and returned data against policy before execution where possible.
Hash-pin tool descriptions so changes become visible at runtime.
Log every invocation with enough context for investigation (who, what tool, arguments, outcome).
Sandbox local servers (containers with restricted filesystem and network access).
Gate destructive or high-privilege tools behind human confirmation.
In Microsoft environments, Defender’s real-time protection for Agent 365 tooling servers (including custom MCP servers) provides one concrete implementation of evaluation and blocking. Elsewhere, proxies that sit in the tool-call path or SIEM rules that surface anomalous invocation patterns serve the same purpose. Absence of meaningful logs or the ability to insert human approval for high-impact tools is a failure.
A workable assessment process looks like this:
Inventory all MCP servers (endpoint configs, network traffic, registries, scanners).
Map each server against the four controls and record pass/fail evidence.
Prioritize remediation for remote servers with broad scopes, missing audience validation, unpinned tools, or no runtime visibility.
Establish continuous monitoring: drift detection on tool definitions, repeated inventory scans, and alerting on new or changed servers.
Treat the approved inventory as a governed allowlist. Anything outside it is either blocked or escalated.
This is not a one-time audit. MCP servers change, new tools appear, and ownership can shift. The same controls that reduce risk also make verification repeatable.
MCP is the connective tissue between agents and the rest of the world. The only reliable way to know whether the servers in a client environment follow the guidance is to measure them against it systematically and keep measuring. Inventory, validate the four controls, and monitor for drift. That is how you move from theoretical guidance to demonstrated security.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.