CTEM covers your whole attack surface. Except the part your AI agents use.

Gustavo — Wed, 03 Jun 2026 22:46:31 +0000

If you run a CTEM program, you have a map of your attack surface. Endpoints, identities, cloud configuration, exposed services — all scoped, ranked, and worked on a cadence.
I'd put money on the MCP servers your agents call all day not being on it.
Not because someone decided they didn't matter. Because nobody scoped them in — the tooling that draws your map doesn't know they exist. That blind spot is the whole subject of this post.

A new exposure class, not a new category of risk

MCP is how an AI agent reaches into your systems — the wiring that lets it read a ticket, query a database, or call an internal API on someone's behalf. Each server you stand up adds capability, and every capability is reachable by whatever drives the agent. Stack enough of them and you've built a second attack surface that nothing in your current toolchain was ever pointed at.

The reason this fits CTEM rather than demanding a program of its own is that the failure modes are familiar. A poisoned dependency buried in a server's package tree. A credential pasted into a tool definition. A tool that executes with broader privilege than the caller ever had. None of that is exotic — it's the catalog you already know, moved to a layer your SAST pipeline doesn't parse and your CSPM doesn't enumerate. The pipeline doesn't see a hosted MCP server at all. The CSPM has no idea which tools an agent is allowed to call.

It's the shadow-IT story again, one layer up the stack: capability arriving faster than anyone's ability to see it.

Mapping MCP onto the five CTEM phases

The useful thing about CTEM is that you don't need a new program to handle MCP. You need to extend the one you have. Each phase has a clear MCP equivalent:

Scoping. Add MCP servers to the surfaces you care about — public-facing endpoints and the private, internal servers behind your firewall, which is where most real exposure lives.
Discovery. Inventory the servers, the tools each one exposes, and the data those tools can surface. You can't assess what you haven't enumerated.
Prioritization. Rank findings by what an attacker could actually reach, not by raw count. A toxic flow that exfiltrates data outweighs a cosmetic schema warning.
Validation. Confirm that a finding is exploitable, with a reproduction an engineer can run — the difference between a theoretical issue and one worth a sprint.
Mobilization. Hand engineering remediation they can act on without a second meeting, and hand audit and compliance a record they can stand behind.

The phases that usually get skipped for MCP are discovery and validation. Discovery, because no one owns the inventory. Validation, because a list of maybes doesn't survive contact with an engineering backlog.

What discovery actually requires for MCP

A list of server hostnames isn't an inventory. The exposure lives a layer down — in the tool definitions, the parameter schemas, the authorization model, and the data each tool will hand back when an agent asks for it.

Industry research on exposure management is blunt about the cost of getting this wrong: most identified exposures turn out to be dead ends, and most remediation effort has historically gone to issues that never threatened a critical asset. Discovery that stops at the hostname guarantees you spend that effort in the wrong place. Reach the tool and schema level, and prioritization finally has something real to sort.

Where Gated fits

Gated is the audit layer for the MCP servers your agents already reach into. It scans deployed, hosted servers — not developer-machine configs — across security, quality, conformance, reliability, and cost, and returns ranked findings with reproductions for every one.
Two things make that fit a CTEM program rather than sit beside one.
One is that discovery and validation happen in the same pass. Gated enumerates the tools and schemas a server exposes, runs its checks against them, and produces a reproduction for each finding — so the output drops straight into prioritization and mobilization instead of stalling at "needs triage."

The other is that the scanning suits a regulated environment. Private and internal servers are reached through a proxy; the checks run on Gated infrastructure, and no metadata leaves your network. For teams under LGPD, SOC 2, or similar obligations, the audit record — reproducible findings, provenance on every suppression — is itself a deliverable.
Gated doesn't make you compliant. It closes the MCP gap in the program you already run, and gives you the evidence to show it's closed.
Scan your first Server

DEV Community: Gustavo

CTEM covers your whole attack surface. Except the part your AI agents use.

A new exposure class, not a new category of risk

Mapping MCP onto the five CTEM phases

What discovery actually requires for MCP

Where Gated fits