Your agents plug into servers nobody watches. The trust layer is catching up

What slips in

Knostic researchers found two npm packages, @ifasn/mmdd-doc-mcp and @ifasn/ms-doc-mcp, both published on November 3, 2026, that collect data when launched as AI agent tools. The first gathers process information, including command lines that may contain secrets, checks the cloud metadata service and tries to send a report over plain HTTP to an external address. It captures command lines containing password, secret or jasypt. Its file header claims results are written to stderr and an artifact file with no network reporting — a claim the code contradicts. The second records the full values of environment variables with secret-like names and writes them to stderr and a local file. Knostic found no code that transmits the second package's haul to an external server, and no victims have been confirmed. Knostic's AgentMesh scanner rated the first package Dangerous, which prompted the review. m:…0543

You cannot see what you have

The packages are the sharp end of a wider problem: most teams cannot say which MCP servers their agents are actually using. Snowflake has no column in query history that says which MCP server a query came through, so Ondřej Blaha, writing on Snowflake's Medium publication, worked out a join between query history and login history, using the authentication event ID to filter by the authorizing integration name. The workaround only works when each MCP server has its own OAuth security integration, and it misses logins made with programmatic access tokens or key pairs, which carry no integration name. A built-in skills query that Snowflake runs before MCP calls can roughly double the count if it is not excluded, and the history itself lags — about 45 minutes for queries and up to two hours for logins. For the people on the author's account who use MCP, it carries only 6 to 14% of their queries in a typical week; the rest still goes through Snowsight. The author's recommendation is to create one integration per MCP server from day one. m:…7885

Snyk's numbers show how far the sprawl has gone. Across 10,000 developer environments, the company found 4,524 unique MCP servers in active use, and 1 in 12 developers with an MCP server installed had a confirmed high or critical security finding. The servers surface in code repositories, on developer machines and in one-off local installs that never touched a repo, the company says — which is why discovery, not just policy, is the first step. m:…2770

The fixes: score it, watch it, broker it

Snyk's answer, now generally available in its Evo Agentic Development Security platform, is to govern MCP servers by risk. The platform gives each server a risk score from 0 to 1000, combining server behavior — the instructions and tool descriptions it sends to agents — with trust in its URLs and maintainers, and, where source is available, implementation, maintenance and dependencies. Enforcement runs on the endpoint through lightweight hooks with no proxy, and blocks servers that are not on the allowlist and are rated high or critical risk. A monitor mode shows what a policy would block before it blocks anything, and the hooks enforce on Claude Code, Cursor, Codex and GitHub Copilot. One limit the company states: servers without a signature cannot be confidently identified and do not get a score. m:…2770

Aembit attacks the credential side. Google's Antigravity agents decide at runtime which MCP servers to call, which tools to invoke and which systems to touch, the company says, and Antigravity configurations often leave long-lived Google application-default sessions, OAuth tokens cached to disk and hardcoded bearer tokens in a JSON file. Aembit replaces those with a blended identity model — the human's identity from an identity provider combined with the agent's own identity, evaluated as one access decision — and brokers short-lived, scoped credentials after evaluating each request against policy in real time. The platform uses OAuth 2.1 with PKCE and dynamic client registration, and Aembit says one policy plane covers Antigravity, Claude and Copilot Studio agents. m:…0265

What to do first

The three threads converge on the same order of operations. First, find the servers: give each MCP server its own integration or identity so its traffic can be seen, and scan the machines where developers install them. Second, score them and block the dangerous ones rather than debating each install by hand. Third, stop giving agents long-lived credentials to spend however they choose, and broker short-lived ones instead. None of the vendors claims the problem is solved — Snyk cannot score unsigned servers, and the malicious packages may have victims nobody has found yet. But the shape of the fix is now visible, and it starts with treating MCP servers as untrusted code, not as helpful plugins. m:…7885 m:…2770 m:…0265