Mapping Trust Boundaries in an Agentic System

Mapping Trust Boundaries in an Agentic System is the exercise that turns a vague sense of risk into a list of places where a control is missing. It takes an afternoon, needs no tooling, and it is the artifact every later chapter attaches to.

Key takeaways

• A trust boundary is any crossing between parties with different trust. Agentic systems have more crossings than their architecture diagrams show, because the model reads data from places nobody counted as an interface.
• Draw every principal, every tool, every data source, every other agent and every entry point for text an outsider can write, on one page.
• Mark what enforces each crossing. The crossings marked nothing are the work, and they are usually the majority on a first pass.
• The model is inside the boundary, never on it. Anything you are relying on the model to enforce is unenforced.
• Redraw the map when the tool surface changes, because a single new tool can connect two zones that were previously separate.

Read this beside Chapter 1, which named the principals, and Chapter 4, which is the first control the map will show you are missing. Chapter 8 handles the crossing most maps omit entirely, which is outbound network access.

A team draws its architecture on a whiteboard: user, application, model provider, three tools, a database. Six boxes and five arrows. Everyone agrees it is accurate.

Then somebody asks where the support tickets come in. They arrive through a tool, from a system where customers write free text, and that arrow was never drawn because tickets are data rather than an interface. It is the most important arrow on the board.

What counts as a boundary here

A trust boundary sits wherever data or control crosses between parties whose trust differs. In a conventional application those are familiar: the browser, the API edge, the database connection, the third-party integration.

Agentic systems add four that people miss.

The context assembly, where text from many sources with different trust levels is concatenated into one prompt. That is a boundary being erased rather than crossed, which is why Chapter 3 treats it as the central problem.

Each tool call, where the agent's intention becomes an action in another system with its own authorisation model.

Each retrieval, where content authored by somebody else enters the agent's reasoning. OWASP's 2025 vector and embedding entry treats the store itself as an attack surface, including cross-context leakage in multi-tenant systems and poisoning of the corpus.

And each inter-agent message, where one agent's output becomes another's instruction, which Chapter 10 covers because it compounds every other risk.

Draw it on one page, in an afternoon

The map is deliberately low-tech. A sheet of paper or a single diagram file, not a modelling tool.

Start with principals. Every human role, every service, every agent, each with a name. Chapter 1's four properties apply to each: if you cannot name its identity, mark it.

Then draw every tool the agent can call, with the system it reaches and the credentials it uses. Include the ones added for debugging, because those are the ones with the widest permissions.

Then every data source the agent reads: databases, vector stores, file systems, web fetches, the conversation itself, its own memory.

Then every destination it can send data to, which is a different list from the tools it calls and is almost always longer than expected.

Finally, mark each crossing with what enforces it. Authentication, authorisation, a policy check, a sandbox boundary, an egress rule, or nothing. The word nothing appearing five times on a first map is normal. That is the point.

Follow the untrusted text, specifically

The single most useful pass over the map is to trace where text an outsider can write ends up.

Mark every entry point in a distinct colour: user messages, retrieved documents, tool outputs, web content, file contents, other agents' messages, and the agent's own memory from a previous session where a user influenced what was written.

Then trace each one forward to see where it lands. It lands in the context, which is inside the model, which decides what tools to call. That path is the attack path. Drawing it makes the argument in Chapter 3 concrete rather than theoretical.

Two crossings deserve particular attention because they are routinely mislabelled. Tool output is untrusted, since it can contain content the tool fetched from elsewhere. And the agent's own previous output is untrusted once it has been through a store that a user could influence.

The model sits inside the boundary, not on it

The most consequential line on the map separates enforcement from behaviour.

Draw the model inside a box labelled untrusted-by-design, alongside the context that feeds it. Everything inside that box is behaviour. Everything outside it, at the tool layer, the gateway, the network and the destination systems, is where enforcement can live.

This is not a claim that models are unreliable in general. It is that a control which depends on the model choosing to comply is not a control, because OWASP's own prompt injection guidance says fool-proof prevention is not currently apparent given how these systems work.

A quick test for any proposed mitigation: if the mitigation would fail when the model is following an attacker's instructions, it is not a boundary control. It may still be worth having as a layer, and it belongs in a different column on the map.

Name the zones, then state what may cross

Boundaries are easier to reason about once the regions between them have names.

A workable zoning for most systems has four. The untrusted zone, holding all input and retrieved content. The agent zone, holding the model, context and orchestration. The tool zone, holding the code that executes actions under policy. And the system zone, holding the databases, APIs and third parties that hold real state.

Then write the crossing rules as sentences. Untrusted content may enter the agent zone as data and may never be treated as instruction. The agent zone may request actions in the tool zone and may never bypass it. The tool zone may act in the system zone only within the identity and scope from Chapters 5 and 6.

Those three sentences are a security model. They fit on a slide. They are checkable in code review, which is more than most agentic architectures have.

Multi-tenancy multiplies the map

If your product serves more than one customer, every boundary on the map has a second question attached: does it hold between tenants as well as between zones.

Retrieval is where this usually fails first. OWASP's vector and embedding entry names cross-context information leaks in multi-tenant systems as a primary risk, and recommends permission-aware vector stores rather than filtering after retrieval.

Memory is the second failure point. A store keyed carelessly will surface one customer's facts in another's session.

Tool credentials are the third. An agent that holds a single API key with access to all tenants is one prompt away from a cross-tenant action, whatever the prompt says about staying in scope.

Mark tenancy on the map explicitly, as a property of each store and each credential. The alternative is discovering the boundary during an incident, when the question is being asked by a customer.

MCP and third-party tool servers widen it again

Connecting an agent to tool servers you did not write moves a boundary outside your organisation, and it deserves its own marks on the map.

The Model Context Protocol's specification, currently at version 2025-11-25, is explicit about the trust implications: hosts must obtain explicit user consent before invoking a tool, and tool behaviour descriptions such as annotations should be considered untrusted unless they come from a trusted server.

Read that second clause carefully, because it is easy to skim. A tool description is text that reaches the model and influences its behaviour, so a third-party tool server is an injection surface as well as an execution surface.

On the map, draw each external tool server as its own zone, with two crossings: the descriptions it supplies into your agent zone, and the actions it performs on your behalf. Both need a control, and the second is the one people remember.

Rank the unenforced crossings before fixing any of them

A first map typically returns more gaps than a quarter can absorb, and treating them as a flat list is how the important ones get postponed.

Three properties decide the order. Reversibility, meaning whether an action taken across that crossing can be undone, since an irreversible write outranks a read every time. Reach, meaning how much data or how many systems sit behind it, which is the blast-radius question from Chapter 1 asked one crossing at a time. And exposure, meaning whether text an outsider can write reaches the decision to use that crossing.

A crossing scoring badly on all three is an incident waiting for a date. An unenforced read of a low-value store, reachable only by an authenticated internal user, can sit on the list for a while without dishonesty.

The ranking has a second use, which is that it makes the map arguable. Somebody will disagree about whether a particular tool is really irreversible, and that argument is worth having in a room rather than in a postmortem.

Record the ranking on the map itself, as a number beside each crossing marked nothing. The map then stops being a diagram and becomes a plan, which is the difference between an exercise a team does once and an artifact it maintains.

Keep the map current, and use it as the review artifact

A map drawn once and filed is worth little. Two habits keep it alive.

Update it whenever the tool surface changes. A single new tool can connect two zones that were previously separate, which is a security change disguised as a feature, and it is the most common way a bounded agent becomes an unbounded one.

Use it as the artifact for security reviews. A reviewer with a current map asks better questions in ten minutes than they will extract from an hour of description, and the crossings marked nothing give the conversation a natural agenda.

Then use it as the index for this book. Each remaining chapter fills in one class of crossing: tools in Chapter 4, identity in 5, authorisation in 6, execution in 7, egress in 8, memory in 9, other agents in 10, supply chain in 11, and evidence in 12.

Chapter summary

A trust boundary is any crossing between parties with different trust, and agentic systems add four that conventional diagrams omit: the context assembly where trust levels are erased by concatenation, each tool call into another system's authorisation model, each retrieval that brings in content somebody else authored, and each inter-agent message. Draw all of it on one page in an afternoon, starting with named principals, then every tool with its credentials including the debugging ones, then every data source, then every destination, marking each crossing with what enforces it and accepting that nothing will appear several times on a first pass. Trace the untrusted text specifically, marking user messages, retrieved documents, tool outputs, web content, other agents and influenced memory, and follow each to the context, which is the attack path. Put the model inside the boundary rather than on it, since a mitigation that fails while the model follows an attacker's instructions is a layer rather than a control. Name four zones, untrusted, agent, tool and system, and write the crossing rules as three sentences that fit on a slide and can be checked in review. Multiply the map by tenancy, since retrieval, memory and shared credentials all fail there first and OWASP names cross-context leakage in multi-tenant vector stores as a primary risk. Add external tool servers as their own zones with two crossings each, because the Model Context Protocol treats third-party tool descriptions as untrusted and requires explicit consent before invocation. And keep the map current as the tool surface changes, using it as the standing artifact for security review and as the index for the rest of this book.

The map will show untrusted text reaching the model in several places, and no control on that arrow. Chapter 3 is Indirect Prompt Injection as the Default Condition, which is where this book stops trying to prevent that and starts designing for it.