Shadow AI Moved Inside the Perimeter and Your Detection Playbook Did Not Follow

TV
Thiago Victorino
8 min read
Shadow AI Moved Inside the Perimeter and Your Detection Playbook Did Not Follow

Cloudflare had to build protocol-layer detection for MCP because MCP traffic has no reliable URL shape. There is no /mcp convention that holds, no vendor domain list that stays current, no port that separates it from ordinary HTTPS. If your MCP inventory came from a hostname search, it is a list of the servers whose names you already knew.

In August 2026, Cloudflare and Webflow published on the same underlying problem from opposite ends of the stack. Cloudflare wrote about detecting MCP traffic leaving the network. Webflow wrote about cloud infrastructure that engineers built with coding agents inside the company’s own AWS accounts. Both pieces skip enforcement and land on the layer before it: you cannot govern what you cannot see, and the thing you used to look for is gone.

We have argued before that shadow AI is a symptom of a missing sanctioned path, and that vibe-coding platforms shift governance to whoever owns the platform. This piece is about the mechanics underneath: what the discovery signal actually is, and which controls sit where once you have it.

The Protocol Header Is a Hint, Not a Test

MCP’s own specification gives you the strongest available signal. The 2025-11-25 revision requires an MCP-Protocol-Version header on every HTTP request after initialization. The 2026-07-28 revision requires it on every POST and adds Mcp-Method and Mcp-Name, which carry the method being invoked and the tool or resource name. That is remarkable telemetry to get from a header. It tells you which tool a client reached for, not merely that MCP happened.

Then the constraint. Revisions before 2025-06-18 did not define the header at all. Cloudflare’s Kenny Johnson states the limit plainly: “Its presence is a strong positive indicator of MCP; its absence does not prove that a request is not MCP.” An old client, a custom implementation, or a deliberately quiet one produces traffic with no marker at all.

So the signal is asymmetric. High precision, unknown recall. That is a usable property if you treat it as a floor, and a dangerous one if you report it upward as coverage. A dashboard that reports how many MCP servers you see is reporting a lower bound, and the count of invisible ones will never appear on it.

The vendor names its own blind spots, which is worth more than the feature list. Stdio transports stay invisible because they never touch the network. Off-network clients, meaning laptops outside the tunnel, stay invisible. Anything routed under a Do Not Inspect rule stays invisible, and Do Not Inspect lists are exactly where sensitive-looking domains accumulate over years of exception requests. Go read yours before you buy any MCP visibility product. That list is your real recall ceiling.

Unapproved Servers and Bypasses Are Different Problems

The single most useful line in the Cloudflare piece is a taxonomy: “unapproved servers and bypasses of approved servers are different problems.”

Most teams conflate them, and the conflation shows up as one policy rule doing double duty. Cloudflare’s baseline is a Gateway expression:

experimental.is_mcp == true and not traffic.onramp in ("mcp_portal") → Block

Read what that actually says. It blocks MCP that arrived by any route other than the sanctioned entry point. An approved server reached directly, bypassing the portal that does the logging and the auth, gets treated the same as a server nobody vetted.

Those two failures have different owners and different fixes. An unapproved server is a procurement question: who is this vendor, what data does the tool touch, what happens when it goes down. A bypass is a paved-road question. The server is fine, the path is wrong, and the reason is almost always that the sanctioned path was slower or required a ticket. The first needs a review process. The second needs the approved route to be the fastest route, because engineers route around friction and will keep doing it.

If your policy produces a single alert type for both, your remediation queue mixes a vendor-risk decision with a developer-experience defect, and the developer-experience defect will sit there for months.

The Same Blindness, Inside Your Own Account

Webflow’s Andy Gombar describes the second face of it: “we’ve moved from SaaS sprawl to code sprawl. The detection playbook for one doesn’t translate to the other.”

The old shadow-IT signal was a financial one. Unapproved SaaS showed up as a charge on an expense report or a new domain in DNS. Agent-built infrastructure produces neither. It is provisioned inside accounts you already own, with credentials you already issued, by engineers who are doing their jobs. What exists is a new IAM role and an S3 bucket that look exactly like the legitimate ones created that month.

Webflow’s answer is behavioral rather than name-based. Three signals they watch:

  • IAM role creation outside normal pipeline activity, meaning a human or an agent made the role directly rather than Terraform making it.
  • New public-facing resources with no corresponding change record.
  • API calls from developer machines directly into production accounts.

All three work without knowing which tool was used, which is the point of picking them. They describe the shape of provisioning that skipped the pipeline, and they survive whatever the agent-tooling market does next year.

His sharper line is about review. Gombar calls the baseline check “a comprehension gate” as much as a quality gate. Code an agent wrote and a human merged without understanding is a liability the moment it breaks at 3am. The reviewer’s question shifts from “is this correct” to “can somebody here explain this under pressure.”

Be honest about what Webflow is reporting. The author describes “the baseline we’re building toward” and publishes no results, no incident counts, no before-and-after. Treat it as a well-reasoned design awaiting evidence. Cloudflare’s post carries no quantitative data at all, so cite it for mechanism and never for scale.

Split the Controls: Platform Owns Some, Process Owns the Rest

The structural move worth stealing is the division. Webflow separates controls that are enforced centrally from controls that are distributed to teams.

Platform controls, owned by whoever runs the account:

  • IAM least-privilege guardrails, so the blast radius of a bad provisioning decision is bounded before anyone reviews it.
  • Secrets manager enforcement, so credentials never land in agent-generated code in the first place.
  • VPN-gated deployment targets, so a laptop cannot push straight to production.

Process controls, distributed to teams:

  • An automated baseline check that runs on the change, not in a meeting.
  • Security-informed review with risk-tiered escalation, so a static marketing page and a service touching customer records do not get the same scrutiny.

The asymmetry matters for organizations without a dedicated AppSec team, which is most of them. Platform controls scale without headcount because the account enforces them. Process controls cost human attention every time they fire, which is why the tiering carries the weight. Uniform review across all changes fails silently, in the form of approvals nobody read.

Do This Now

Two things this week, both small.

Open your Do Not Inspect list and read every entry. For each one, answer whether an agent client could be reaching an MCP server through it. That list defines the ceiling on any MCP visibility you are about to buy, and it costs an hour to read.

Then run a single query against your cloud audit log: IAM roles created in the last 90 days that were not created by your pipeline identity. Sort by creator. You are counting how many exist and checking whether the number surprises you. If it does, your work starts at the discovery layer, and any policy engine you buy before that will be governing a fraction it cannot name.

Gombar’s closing advice is the right sequencing: “Build the baseline before the CSPM finds it for you.” A tool that inventories your drift produces a list nobody can act on, long and with unclear ownership. The baseline is what makes the list finite. For the blast-radius side of this, we wrote an executable version of the containment question, and for what your provider does not log at all, the session audit problem is the companion piece.


This analysis synthesizes How Cloudflare detects MCP traffic and helps secure it (Cloudflare, August 2026) and Vibe coded apps are the new shadow IT (Webflow, August 2026). Both are vendor publications, and neither reports measured outcomes.

Victorino Group helps engineering organizations build the discovery layer for agent traffic and agent-provisioned infrastructure, then split the controls between platform and process. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation