On May 21, 2026, Snyk announced two integrations with Anthropic's Claude on the same day, and together they mark a turning point for how much surface area MCP-connected AI assistants now occupy inside the enterprise. The first, an early-access integration between Snyk Evo and Claude Enterprise, pulls environment snapshots through Anthropic's Claude Compliance API using a "Compliance Access Key" scoped to three read-only permissions — read:compliance_activities, read:compliance_user_data, and read:compliance_org_data — and ingests an org's users, projects, chats, models, and, notably, its registered MCP servers, which Evo then scores 0–1000 across five risk categories including insecure code generation and attack reconnaissance. The second is a Snyk Security Desktop Extension for Claude Desktop on macOS and Windows, built directly on the Model Context Protocol, which embeds real-time vulnerability scanning into the coding workflow itself; because that extension also gives Snyk visibility into what's actually configured on developer machines, pairing it with the Compliance API integration lets Snyk detect drift between the MCP tool permissions admins approved in Claude Enterprise and what developers are actually running locally — something Snyk says neither integration can do alone. Neither announcement involves a CVE or an incident — this is a product launch, not a breach — but it is a clear signal that MCP has moved from an experimental agent-tooling spec to something compliance and desktop-security teams are now expected to instrument directly. That shift is what this post is about.
What is MCP tool-call governance, and why does a compliance snapshot need to see it?
MCP tool-call governance is the practice of deciding, logging, and enforcing which tools an AI agent is allowed to invoke, with what arguments, and under whose identity — treating each tools/call request the way a security team would treat an API call from an unfamiliar service account. Snyk building MCP-server visibility directly into its Claude Enterprise compliance snapshot is telling: a Compliance Access Key that can read org and user data but pulls in "MCP servers" as a first-class object means auditors now expect an inventory of which tool-providing backends an org's assistants can reach, not just which chats happened. That mirrors what Safeguard's own Guard product treats as a prerequisite rather than a nice-to-have — per Safeguard's guard-servers-agents documentation, Guard maintains MCP servers and agents as first-class registered records specifically so that policy has something concrete to target and so that alerts and audit trails can reference a named server or agent instead of a raw upstream URL or an ephemeral connection. Without that inventory, a "compliance snapshot" of an AI deployment is really just a snapshot of chat transcripts, blind to the tool-execution layer where the actual state-changing actions happen.
Why does credential scoping matter more for MCP servers than for ordinary API integrations?
Credential scoping matters more here because a single compromised or overly broad MCP credential can let an agent silently exfiltrate data or take actions across every tool that server exposes, often without a human reviewing each call. Anthropic's own design for the Compliance Access Key illustrates the right instinct: it's scoped to exactly three read-only permissions rather than a blanket admin token, which limits blast radius if the key leaks. Safeguard's Guard SDK documentation describes the equivalent pattern for MCP servers and agent processes themselves — a secret key tied to an organization, generated once from Settings → Developer and shown only a single time, meant to be injected via environment variable or a secrets manager rather than committed to source. The SDK then pulls the org's live policy in the background and enforces it in-process, so the credential that matters for runtime behavior is the org's Guard secret key, not a static bearer token baked into an MCP server's config file that every developer's desktop client also has a copy of — which is precisely the kind of drift Snyk's desktop extension says it now checks for.
What does "permission drift" between approved and local MCP configs actually look like in practice?
Permission drift is what happens when the MCP tool permissions a security or platform team approved for an agent diverge from what an individual developer's local client is actually configured to call, usually because a claude_desktop_config.json file was hand-edited, copied from an old project, or never rotated after a tool was deprecated. Snyk addresses this gap not with the desktop extension alone but by pairing it with the Evo/Compliance API integration: the extension gives Snyk visibility into what's actually configured on a developer's machine, and the compliance side compares that against the permission ceilings admins approved in Claude Enterprise — a check Snyk says neither piece can perform by itself, and one that runs on an ongoing basis rather than relying on a one-time onboarding review. Safeguard's MCP tool-gating model addresses a related but distinct half of this problem on the server side: Safeguard's own MCP server exposes more than 650 tools, but only a curated set of 10 is enabled by default per tenant, and every other tool stays registered yet inaccessible until an administrator explicitly turns it on through a per-tool feature flag of the form mcp:tool:<tool_name>. Because tool discovery and tool execution resolve from the same enabled-set, an assistant can never see a tool it isn't permitted to call — closing off one common source of drift, where a client discovers and calls a tool nobody meant to expose to it.
How should audit trails for MCP tool calls differ from ordinary application logs?
Audit trails for MCP tool calls need to capture not just that a request happened, but which agent identity made it, which policy rule matched, and what action was taken — allow, deny, or flag for monitoring — because a single MCP server may be called by dozens of differently-trusted agents with very different blast radii. Guard's policy engine, as described in Safeguard's guard-policies documentation, evaluates every MCP request against an ordered list of rules matched on JSON-RPC method, glob-matched tool name, or a specific agent ID, and the first matching rule wins; if nothing matches, Guard doesn't silently allow the call, it falls back to flagging the request for monitoring. That "fail toward visibility, not toward silent trust" default is the opposite of how a lot of internal tooling handles unrecognized requests today, and it's the property that makes a later audit query — "did our billing MCP server ever receive a delete call from an agent that wasn't supposed to have write access" — answerable at all instead of requiring a best-effort log grep.
Where does tool-poisoning fit into this threat model, and is it a real risk?
Tool poisoning is a real and increasingly discussed MCP-specific attack class in which a malicious or compromised MCP server advertises a tool with a manipulative name or description designed to trick an agent's reasoning into taking an unintended action, or crafts a tool response that tries to redirect the agent's next steps entirely — an attack surface that doesn't exist in traditional API integrations, where a human writes the client code and a machine doesn't "interpret" an endpoint's docstring at runtime. Safeguard's Guard SDK includes detection specifically aimed at this pattern, flagging manipulative tool names and descriptions as well as attempted response-redirects before an agent acts on them, which is a meaningfully different job than a conventional API gateway does, since a gateway typically authenticates and rate-limits a request without ever reasoning about whether the tool's own metadata is trying to manipulate the caller. As more enterprises give assistants like Claude direct desktop and compliance-layer access to internal tools, this is the class of risk that a permissions review alone — even a well-scoped one — won't catch, because the attack lives in the tool description an agent trusts, not in the credential it used to call it.
What should a security team actually change after this announcement?
A security team evaluating Claude's enterprise and desktop MCP expansion should treat it as a prompt to inventory their own MCP exposure rather than a reason to trust vendor scanning alone: know which MCP servers your organization's assistants can reach, know which credential each one uses and how narrowly that credential is scoped, and know whether tool availability is enforced server-side or only assumed from a compliance dashboard's read-only snapshot. Concretely, that means registering MCP servers and agents as inventoried objects rather than tribal knowledge, keeping tool-level access gated per tenant or team by default-off rather than default-on, and running policy enforcement in-process at the point of the tool call — not just after the fact in a monthly compliance export. Snyk's May 2026 launch shows the industry converging on this as baseline expectation for any AI assistant with real enterprise reach; the organizations that already treat MCP tool calls as a governed, audited surface will find that shift far less disruptive than the ones treating it as background plumbing.