Authority paths, not prompt filters

The question that breaks production agent systems is what this agent may call, as which identity, into which data path, down to native binaries that ship without source.

We call that chain an authority path, and Atlas maps those paths. Findings are routes on the map.

The four crossings that matter

On agent and MCP work we keep returning to the same four crossings, each one step from the agent toward the data it can reach: Agent to Tool, Tool to MCP server, MCP server to Identity, and Identity to Data path. The agent and MCP chain lets you set each one.

Each crossing is Open, Checked, or Gated. Checked means the call is logged, then allowed. Treating the three states as one is how teams ship a dashboard that looks green while an agent still holds a token that can write production data.

Native binaries sit past source. If your review stops at the TypeScript tool wrapper, you miss the code the agent can still call. Atlas treats Native binary as a surface in its own right, next to Agent, Tool, MCP server, Identity, and Data path, with User and LLM on the map as well: eight surfaces in one vocabulary.

Why a prompt filter is the wrong primary control

Text filters answer: did this string look like an injection?

Authority mapping answers: can this agent reach that data path as that service account after that MCP call?

Those are different jobs. A filter classifies text, and a cloud posture tool inventories infrastructure. Recording who may do what, across the agents, tools, and identities in the system under review, is a third job.

Atlas does that third job. It records authority paths, including binaries past source, and the client keeps it after the engagement closes.

What a secure design review produces

The lightest start is a read of your architecture and code against the threat model of the system you run. Surfaces in scope usually include User, Agent, Identity, and MCP Server. There is no public rate card.

Every paid engagement produces an Atlas map of the reviewed system, which you keep. It is machine-readable and versioned, and it stays useful after the report is delivered.

Coverage on that map moves in states: unmapped, then mapped, then tested, then hardened, then retested. We do not report a percentage, because a percentage implies the map is complete.

Alongside the map you get a findings report and an executive summary. The map lets the next review start from a known surface.

What we do not claim

We publish no client names or engagement counts.

Every offer is listed on Services. Our delivery tooling is internal and not for sale.

Where to start

If your agents can reach tools, identities, and data, map those paths before you argue about prompts. The first paid review builds that map for your system.

When you are ready, read what a secure design review covers and book a call from there.