See which agents can reach which MCPs

"Who can reach what, and what stands between them?" is hard to answer from a list of rules. Policies are first-match-wins over an ordered list, so the honest answer for any one agent is whatever falls out of evaluating the whole list against every tool on every server. Agent Topology does that evaluation for your whole org and draws the result: groups, agents, policy gates, and MCPs on one canvas, with the last 30 days of real traffic flowing over it.

It's the first item under Agent Security in the sidebar. You need permission to view agent instances, resources, and policies to see it at all — it's the union of those three views, so it shows nothing you couldn't already reach individually.

How to read the map

The canvas reads left to right, in four columns:

GROUPS — who the traffic starts from. Each node is sized by how many users it holds.
AGENTS — the agent types in your org (Claude Code, Cursor, …), each sized by how many instances are currently connected.
POLICY MEMBRANE — one gate per policy, colored by its effect: green for allow, amber for conditional, red for deny. A gate picks up a dashed amber outline when at least one path through it is CEL-gated.
MCPs — the resources being reached.

The left column adapts to what your directory actually gives the gateway. With real groups, you get your groups plus an Ungrouped bucket for anyone who has an agent instance but no group membership. With no groups at all, it falls back to users directly: one node per user, or a single Users bucket once there are more than twenty of them.

Grey rails are what policy allows

The static grey lines are reachability, not traffic — they're the answer to "is this allowed right now?" A rail runs agent → policy gate → MCP, and it's the same evaluation behind the Effective Access tab on an agent's Registry detail page, rolled up per server: if any tool on that MCP is allowed, the rail reads allow; otherwise conditional if any tool is CEL-gated; otherwise deny. Conditional rails are drawn dashed, and a deny rail stops at the gate rather than continuing to the MCP.

An absence is meaningful here. If no rule matches any tool on a server for a given agent, there is no rail at all — that's the default-deny fall-through, showing up as empty space rather than a red line. Toggle Hide allowed paths in the top right to drop the rails entirely and watch only live traffic.

Comets are what actually happened

Moving dots are executed traffic from the last 30 days, attributed back to the subject it came from:

allowed traffic — a round green comet running all the way through the gate to the MCP: successful tool calls.
blocked — a red diamond that stops at the gate it bounced off, which pulses: tool calls a policy actually refused.

Busier paths emit more comets. The two shapes differ as well as the colors, so the verdict stays readable without relying on hue, and the whole animation stands still if you've asked your system for reduced motion.

Put together, that's the point of the page: the grey rails are what you permitted, the comets are what's being used. A rail with no comets on it is access nobody needed — a good candidate to remove. A cluster of red diamonds is a policy doing its job, or a team fighting a rule that's too tight.

Hovering and banding

Hover any node to trace it. The gateway lights every path through it in both directions — upstream to the groups that reach it, downstream to the MCPs it reaches — and dims everything else, which is the fastest way to answer "what does this one group actually touch?"

Once the agent or MCP column passes twenty nodes, it collapses into bands by tag, each labeled with its tag name and a count. Click a band to expand it; one band per column stays open at a time. Nodes carrying no tags land in an Untagged band, and a node with several tags appears under each of them.

If the map is empty, there's nothing to draw yet — you need at least one MCP connected and a policy in place before there are paths to map.

When to use it

Reach for Topology when the question is about relationships across the org:

Which teams can reach our production database MCP, and through which policy?
Is anything reaching this server that shouldn't be?
We have a rule that denies X — is it actually catching traffic, or is nothing hitting it?
Where are we granting access nobody uses?

Reach for Agent Registry instead when the question is about one agent type ("which tools can any Cursor instance call?"), and Agent Instances when it's about one connected client ("why did this session get denied?"). Topology tells you the shape of access; those two tell you the detail behind one node in it.

Next steps

Policies — the rules behind every gate on the canvas, and the ordering that decides which one wins.
Agent Registry — per-agent effective access, one column of this map in full detail.
Audit log — the individual tool calls the comets are aggregated from.
Tags — how the agent and MCP columns band once your org outgrows a flat map.