Configuration as Reconnaissance

What reconnaissance costs, and what a tool manifest replaces.

Price the attacker's work honestly, because the whole argument turns on the comparison. To build a useful internal map by hand, an intruder has to discover hosts, probe services, guess which of two hundred endpoints is load-bearing, work out the auth scheme for each, and do it while generating exactly the traffic your detection is tuned for. Most of that effort is not about access — they already have a foothold — it is about relevance. Scanning tells you what exists. It does not tell you what is important.

A tool manifest answers the expensive question directly. It is a short list rather than a long one, which is itself the signal: somebody on your team decided these particular systems were worth the integration work. Each entry names a transport and an endpoint, usually documents the authentication scheme, and often describes in prose what the system is for — because that description exists to help a model choose, and a model needs the same orientation an intruder does.

• It is curated. Ranked by business relevance, by construction, because nobody writes an MCP server for a system nobody uses.
• It is current. A stale config breaks the agent, so it gets fixed. Your network diagram has no such forcing function.
• It is pre-authenticated in structure. Even with secrets removed, the header names and env-var names disclose the auth model, which is most of what a credential-stuffing or token-replay attempt needs to know.
• It is machine-readable. No parsing of screenshots or docs. The format was designed for a program to consume, and the program consuming it does not have to be yours.

The index exists in six places, and each copy has different controls.

Teams who accept the premise usually still get the scope wrong, because they picture one file. The enumeration is replicated across the lifecycle, and the weakest copy sets your exposure.

• Workstation configs. MCP server definitions in developers' home directories, with inline credentials more often than not. Commodity infostealers added these paths to their collection rules during 2026; see agent artifacts on the endpoint for the specific families and paths.
• The registry or catalog. The authoritative list, usually with the best controls and the broadest read access inside the company — which is a strange combination once you say it out loud. Tool catalog lifecycle treats it as an availability asset; it is also a confidentiality asset.
• Published discovery documents. Agent cards and well-known endpoints exist to be fetched by parties you have not met. That is the point of them, and it is a deliberate disclosure — see agent cards and discovery.
• Traces. Every span records a tool name, frequently an endpoint, and arguments that leak identifier formats, tenant names and schema shapes. Trace stores are read by more people than any production database, and retained longer than anyone intends — trace sampling and retention.
• CI and runtime environments. Environment variables and job definitions that reconstruct the same list, visible to anyone who can read a workflow file or a build log.
• Eval fixtures and recorded sessions. The copy nobody remembers. Replay corpora and golden transcripts contain real endpoints and real arguments, live in repositories with ordinary developer access, and are rarely in scope for any data classification exercise.

Write those six down with a read-access column and the finding is usually immediate: the system of record for your internal attack surface is readable by substantially more principals than the systems it describes. Not because anyone decided that — because each copy was created by a different team solving a different problem.

Traces are the copy that grows, and arguments are the part that hurts.

Configs are a snapshot; traces are a stream, and they accumulate the one thing a config cannot give an attacker: observed usage. A config says a billing MCP server exists. A week of traces says which of its tools are called, in what order, with what identifier formats, by which agents, at what times of day, and which calls fail with what messages. That is not an inventory any more. It is a working model of your operations.

Two mechanisms make this worse than it looks. The first is that tool arguments are the richest field in the span and the least likely to be redacted, because redacting them is what makes a trace useless for debugging — the honest tension behind PII redaction in agent traces. The second is that error strings are written to be helpful. A well-designed tool error tells the model what it got wrong and how to fix it, which is the same sentence an attacker needs to turn a rejected request into an accepted one.

And the stream does not stay where you put it. Transluce's September 2026 examination of a public URL-scanning service found 6,467 of 37,649 reports carrying strong evidence of agent activity, with targets, timestamps and payloads — because agents routing around a block had submitted their own attempts to an intermediary whose product is publication. The general case is simple to state and easy to miss: every third party your agent reports to holds a partial copy of your index, under their retention policy and their breach disclosure timeline, not yours.

Published discovery is a trade, and the trade is only bad when it is unpriced.

Not all of this is accidental. Agent-to-agent interoperability requires that an agent be findable and that its capabilities be legible before any relationship exists — that is the premise of capability discovery and of the well-known-URI conventions in agents.json and OpenAPI for agents. You cannot have interop without disclosure. Pretending otherwise produces the worst outcome: a published card that nobody treats as published.

What distinguishes a priced trade from an unpriced one is tiering. A single card that serves anonymous discovery, partner integration and internal orchestration will be written for the hardest of those audiences and read by the easiest.

• Separate the anonymous tier from the authenticated one. Anonymous callers get existence, protocol version and contact. Capability detail, tool schemas and endpoints come after authentication. This costs one extra round trip and removes most of the free intelligence.
• Describe capabilities without describing topology. "Can retrieve invoice status" is what a counterparty needs. "Calls billing-internal.corp on port 8443" is what an intruder needs, and it is in the card because it was easier to generate from config.
• Treat the card as an external interface with a change process. It is a published API surface. Generating it automatically from internal config is how topology leaks without a decision — and it is exactly the mistake MCP security anti-patterns catalogues on the server side.
• Log who fetched it. Discovery traffic is a signal and almost nobody collects it. A sudden sweep of your well-known endpoints is the cheapest early warning available on this surface.

Break the join between the name and the route.

The structural fix is narrower than it first appears. You do not need to hide what your agents can do; you need to stop every copy of the catalog from also being a routing table. Most of the value an attacker extracts comes from the join — this capability, that host, this auth scheme, in one record.

• Reference secrets, never inline them. A config that names a secret rather than containing one is one artifact instead of two, and the practice is already written down in secrets management for agents. This is the single highest-return change on the list.
• Put a gateway between the catalog and the topology. If agents address tools through a broker by logical name, the config holds names and the routes live in one controlled place. It also gives you a chokepoint for policy, which is the usual justification; the reconnaissance benefit is the one nobody counts.
• Use opaque handles in arguments where you can. Identifiers that reveal tenant, region or schema turn every trace into a data dictionary. Opaque handles are also the fix for designation attacks — the confused deputy argument arrives at the same recommendation from the other direction.
• Classify the registry as crown-jewel data, and narrow its read access accordingly. Most organisations grant catalog read to everyone because it feels like documentation. Decide whether it is documentation or a map, then set the ACL to match the answer.
• Redact endpoints at the exporter, not at the application. One collector-side rule that strips host and path from spans is enforceable and uniform; asking a hundred call sites to be careful is neither.
• Expire the copies you forgot. Eval fixtures, recorded sessions and old trace buckets outlive the systems they describe, which makes them worse than current ones — they name hosts nobody is watching any more.

Measure it by running the attacker's query against yourself.

This whole topic stays rhetorical until somebody produces the artifact, which is why the last step is a drill rather than a control. The drill is cheap, it takes an afternoon, and it converts an argument into a document your leadership can act on.

Take one artifact at a time — a developer's MCP config, one week of traces, your published agent card, one eval fixture directory — and answer a single question from that artifact alone, with no other access: list the internal systems this organisation considers important, with the route and auth scheme for each. Write the answer out. The length of that list is your exposure for that artifact, and the exercise consistently surprises people in two ways: the list is longer than expected, and the best single source is rarely the one that was locked down.

• Score per artifact, not per environment. You want to know which copy to fix first, and the answer is usually the one with the broadest read access rather than the richest contents.
• Repeat after each catalog change. Adding a tool adds a row to the attacker's list too; tool catalog lifecycle already has a review gate you can hang this on.
• Pair it with the reachable-set exercise. Task scope asks what a run could touch; this asks what a reader could learn. Both produce lists, and the difference between them tells you where disclosure outruns access.
• Report it as one number. "From this file alone, an attacker learns the name, route and auth scheme of fourteen internal systems" lands in a way that no architectural argument does.