What an MCP server does to your guardrails

Does an MCP server bypass the restrictions we set on a credential?

An MCP server can bypass a restriction you set on a credential, but only in a precise sense: it adds an execution path, and a control configured on one path does not apply to a path that never reads it. In n8n before 2.27.4 and 2.28.1, the AI Agents feature did not enforce the Allowed HTTP Request Domains restriction configured on a credential when an MCP tool was pointed at an arbitrary URL, so a member-level user with use-only access to a shared credential could send that credential's secret to a server they controlled.⁰¹ The restriction was set. It was visible in the interface. It was not in force on the new path, and that gap, not MCP by itself, is the subject of this post.

What does it mean for a guardrail to be in force?

A guardrail is in force only at a chokepoint that every execution path passes through, and coverage is decided by how many paths reach that chokepoint. A rule written on the console, the credential, or the vendor's settings screen is a claim about behavior until you can point to the line of code that reads it and name every path that calls that line. When you add an agent, an MCP gateway, a scheduled job, or a second API, you add a path, and each new path either passes through the chokepoint or quietly does not. A control governs only the paths that read it. On a path that skips it, the control is inert while the interface still reports it as active.

How do you test whether yours are in force?

Three probes settle the question for the common failure modes, and each one runs in about an hour against a system you already have. The shape of every probe is the same: send a request that must be refused, then confirm two things, that the request was actually refused and that the refusal appears in the log as a decision. A control you cannot make fail on demand is a control you are taking on faith.

A fabricated Authorization header

Send a request carrying a fabricated Authorization header and require the broker to reject it. The failure this catches is the broker that converts a failed authentication into an empty identity instead of a refusal. In LiteLLM before 1.84.0, the MCP Streamable HTTP endpoint let an unauthenticated caller use a fabricated Authorization header to trigger an OAuth2 passthrough fallback that replaced failed key validation with an empty UserAPIKeyAuth object, so the request reached MCP tooling with no valid key.⁰² The fix added the gate that was missing, which means before the fix the fallback was ungated. Pass condition: the request is refused and the refusal names why.

A tool pointed outside the credential's declared domains

Point a tool at a host outside the credential's declared domains and require a refusal that lands in the log. This is the n8n failure above, run as a test. Pass condition: the outbound call to the undeclared host does not happen, and the attempt is recorded. If the call succeeds, the domain restriction does not govern that path even though it is configured.

A low-privilege user with a shared credential

Hand a low-privilege principal a shared credential and require that it cannot be used outside its declared scope. The n8n advisory is again the worked example: the party who could abuse the missing check was a member with use-only access, not an administrator and not an intruder.⁰¹ Pass condition: the shared credential's scope holds no matter who holds it. The failure class here starts with an authenticated insider who has an over-broad grant, so the perimeter defenses never see it.

What did the 2026 advisories actually say, and under what preconditions?

Three first-party advisories from 2026, across three layers of one stack, describe the same shape at different depths, and each carries preconditions that keep the story precise. Read the preconditions before the severity: two of the three are gated on non-default configuration or on MCP routes being exposed at all, and the third is conditional on the host's network routing. None of the three supports a claim about how many deployments were affected. The shared shape below is our reading of the record, not a population count.

Which layer failed in each case?

The three advisories fail at three different layers, and naming the layer is more useful than ranking the severity, because it tells you where your own architecture is exposed. At the agent layer, n8n's control existed and the new tool path never read it: the control not read on a new path. At the broker layer, LiteLLM converted a failed authentication into an anonymous identity: the fail-open broker. At the distribution layer, the official MCP Registry shipped an unauthenticated server-side request forgery in its namespace-verification endpoint, the one function the registry itself owns, and patched it in 1.7.7.⁰³ Locate your workflow in that list and you know which probe to run first.

Is being in the official registry a control?

Being in the official registry is not a control, and the registry's own documentation says so. The MCP Registry relies on npm, PyPI, Docker Hub and other upstream registries for deeper moderation, tells consumers to assume minimal-to-no moderation, and lists servers with security vulnerabilities under what it does not remove.⁰⁴ That policy governs third-party servers listed in the registry, and it is separate from the registry's own patched SSRF above, which is the registry's own code. A public registry entry tells you a name was verified, not that the code behind it was reviewed.

What belongs in a pinned server register, and where does it live?

A pinned server register lists the small number of MCP servers a workflow actually needs, and it lives inside the client's own tenant rather than being resolved from a public registry at run time. Each row names the server, its transport, the negotiated protocol revision, the auth mode, the tools it exposes, the owning team, the date of the last conformance run, and the next review date. A register you maintain tells you what your workflow can reach, and it exists before an incident rather than being assembled during one.

What has to be in the log for a refusal to count as evidence?

A refusal counts as evidence only when the log records the policy decision and its reason, not merely the tool call, because a missing entry and an allowed entry look identical once the request has run. The common failure is a log of what the agent did with no record of why it was permitted or refused. When something goes wrong the question is whether a rule allowed the action or whether no rule covered the case, and a log of tool calls alone cannot answer it. Write down the decision, the rule that produced it, and the identity it applied to, or the audit trail records history without accountability.

What changes in the 2026-07-28 revision, and what is only deprecated?

The MCP specification revision published on 28 July 2026 removes several protocol features outright and deprecates several others, and the difference decides whether your integration faces a migration or merely a clock. Removed are protocol-level sessions and the Mcp-Session-Id header, the initialize handshake, ping, logging/setLevel, and SSE stream resumability; the missing-resource error code also changes from the MCP-custom -32002 to the JSON-RPC standard -32602.⁰⁵ Deprecated, and still fully working, are Roots, Sampling and Logging, which the same release protects with a minimum twelve-month window before any removal.⁰⁶ Nothing you run stopped on 28 July, because MCP revisions are version-negotiated and a client keeps speaking the revision it was built for; what changes is that anything built on an older revision now carries a migration.

The same release introduced the twelve-month deprecation policy, and its own deprecated registry records that no features have been removed under that policy yet.⁰⁶ That is the honest way to read the table: the removed rows sit outside the guarantee the release created, and the deprecated row is the first to sit inside it.

Why is an error code change the quietest breaking change?

An error code change is the quietest breaking change there is, because nothing raises, nothing pages, and a branch that matched on the old value simply stops running unless someone wrote a test for the error path. When a missing resource starts returning -32602 instead of -32002, a client that recognized -32002 no longer recognizes the case, and the failure surfaces as wrong behavior with nothing thrown.⁰⁵ Evals that exercise the failure path catch this; happy-path tests never reach it. A changelog is not a monitoring strategy here: the change was announced, and the announcement is not what breaks you.

Who owns the upgrade window?

Someone has to own the upgrade window, and it is never the vendor. The three probes in this post are free, and you can run them alone this week. You will probably fail at least one, and a failure there tells you which path skips the control. What you cannot do alone is inventory every execution path, because the paths nobody wrote down are the ones the people inside the team do not know exist, and those are exactly the paths a new control fails to cover. That inventory, run against your real system with the owners in the room, is the readiness check. Keeping the register current and owning each scheduled upgrade afterward is ongoing operational work. For the checks a new agent passes before go-live, see the agent preflight checklist; this post is how you test the controls on a system that predates the agent.

Frequently asked questions

Does an MCP server bypass the permission restrictions we set on a credential?

It can, when a restriction configured on one path is not read on the path the MCP tool takes. In n8n before 2.27.4 and 2.28.1, the AI Agents feature did not enforce the Allowed HTTP Request Domains restriction set on a credential when an MCP tool was pointed at an arbitrary URL. The control was set and visible; it was not in force on the new path.

How do I test whether a guardrail is actually enforced?

Send a request that must be refused, confirm the refusal, then find it in the log as a policy decision. Three probes cover the common cases: a fabricated Authorization header, a tool pointed at a host outside a credential's declared domains, and a low-privilege user borrowing a shared credential. Each runs in about an hour and does not depend on any advisory staying current.

Does the 2026-07-28 MCP revision break my existing integration?

Not on the day it publishes, because MCP revisions are version-negotiated and a client keeps speaking the revision it was built for. What it creates is a migration: sessions, the initialize handshake, ping, logging/setLevel and stream resumability are removed, and the missing-resource error code changes from -32002 to -32602. Anything built on an older revision carries that migration whether or not anyone has been named to do it.

Is a server being in the official MCP registry a safety guarantee?

No, and the registry says so in its own documentation. It relies on npm, PyPI and Docker Hub for deeper moderation, tells consumers to assume minimal-to-no moderation, and lists servers with security vulnerabilities under what it does not remove. A pinned allowlist of the few servers a workflow needs, held in your own tenant, is the defensible setup.