Least-Privilege by Construction 

Which agent may call which is a security boundary. Most systems leave it implicit — and an agent that learns an address can simply dial it 

Here’s an experiment worth running on your own architecture. Take any two agents in your estate with no business talking to each other. Now imagine one obtains the other’s network address — from a config file, a log line, an error message, or a document it was asked to summarize. What stops the call? 

For most deployments, the honest answer is nothing, or something that wasn’t designed to. The agents share a network and a protocol; one has the address. The call goes through. 

We spent fifteen years learning this lesson with microservices, at considerable expense. It’s being quietly re-learned across multi-agent system security — and the stakes are higher, because agents can be persuaded, which turns an ordinary reachability gap into prompt injection lateral movement. 

THE 90-SECOND VERSION 

• “Which agent may call which” is a security boundary. In most multi-agent systems it’s implicit — a function of network reachability and address knowledge — which means it isn’t a boundary at all. 
• The alternative is an explicit, tenant-scoped graph of who may reach whom. If no edge is drawn, there’s no route, and refusal is the default rather than an exception. 
• The route and the permission are written as one operation, making two broken states unrepresentable: an agent you can see but can’t use, and an agent nobody listed that answers anyone who guesses its address. 
• Discovery is dynamic. Draw an edge and the agent becomes usable on the next turn — no redeployment, no restart. 
• This is the direct structural answer to prompt injection and lateral movement, because it constrains reach from outside the agent, where no amount of clever text can reach it. 

What an implicit boundary costs 

Return to Priya’s invoice agent from Part 2. It sits alongside a dozen others: a vendor lookup agent, a contract analysis agent, a payroll agent, a customer support agent — sharing infrastructure, because that’s what infrastructure is for. 

Now suppose the invoice agent processes a supplier document containing text crafted to look like an instruction — a technique that needs no privileged access, only the ability to send the company a PDF, and one OWASP ranks as the top risk facing LLM applications. The text tells the agent to fetch payroll details and include them in its summary. 

Whether the agent complies is a question about a model, and the answer isn’t reliably no. But compliance isn’t the interesting part — what happens after it decides to comply is. In an implicit system, it composes the call, sends it, and payroll answers, because payroll’s job is to answer calls, and this one arrived properly formed from inside the trusted network. Every control in that story worked as specified. Nothing was misconfigured. The system did what it was built to do, and the data still moved. 

A boundary that depends on nobody discovering an address is not a boundary. It’s an assumption about attacker knowledge, and those assumptions expire. 

Drawing the graph 

The fix is to stop treating reachability as a property of the network and start treating it as governed data — the same move zero trust architecture makes for humans, applied to agent to agent communication security. 

Every tenant has a directed graph. The nodes are agents; an edge from A to B means A is permitted to call B. If there’s no edge, there’s no route — not an error to be handled, but the normal state of the world for the overwhelming majority of pairs. 

Three consequences follow, and they matter more than the mechanism. 

• Refusal is free and permission is deliberate. In the implicit model, every pair is connected by default and you’re trying to subtract — which never finishes. In the explicit model you add the small number of routes the business needs. The invoice agent’s route to payroll was never drawn, because nobody had a reason to draw it. 
• The graph is a document. It can be read, reviewed, and diffed — a better artifact than a network diagram, because it describes intent rather than topology. 
• Reach is constrained from outside the agent. This is what makes it robust against prompt injection specifically. Every in-agent mitigation — better system prompts, input sanitizing — is a control living in the same place as the attack. The graph is different in kind: the agent may be fully persuaded and compose the call with complete conviction, and it still doesn’t connect. You can’t talk your way past a route that doesn’t exist. 

Two states that should be impossible 

Two facts have to be true for a call to work: the caller must be able to find the target, and the caller must be permitted to invoke it. Store those separately, update them separately, and you’ll eventually have them disagree. 

• Reachable but denied. The agent sees the target in discovery, routes work to it, and every call is refused — intermittent failures that look like bugs, engineers debugging a permissions problem while believing it’s a networking one. 
• Denied but reachable. Nobody listed the agent, so no review notices it — but the gate was never wired, so it answers anyone who knows where it is. A shadow service with no owner, worse than an obvious misconfiguration precisely because it’s invisible: the multi-agent equivalent of Broken Function Level Authorization, one of OWASP’s most-cited API risks. 

The structural answer: refuse to make it possible. Connecting two agents is a single operation that writes both the visible route and the invoke permission together — no interface that writes one, no screen that sets the other, nothing to reconcile. 

Worth stating on its own: the most reliable way to prevent a class of inconsistency is to make the inconsistent state unrepresentable. Validation catches bad states after they exist; making them impossible is cheaper, and doesn’t degrade under load or during an incident. 

Dynamic, so governance doesn’t mean friction 

A fair objection: doesn’t this turn every new agent connection into a deployment? It shouldn’t — governance that imposes a release cycle on every routing change gets quietly subverted, someone widens a permission “temporarily,” and temporary becomes permanent. 

So discovery is rebuilt continuously rather than baked in at startup. An orchestrator asks, at the start of each piece of work, what it can currently reach. Draw an edge and the next request can use it; remove one and it cannot. No restart, no redeploy. 

One deliberate softness: if the control plane hiccups, an orchestrator falls back to what it already knew rather than halting all work. That sounds like fail-open, but discovery only decides what the orchestrator attempts — the invoke gate at the target is separately enforced and doesn’t degrade. Availability degrades gracefully; authorization doesn’t degrade at all. 

Getting from a flat estate to a graph 

Most organizations already run agents on a flat network, and “draw the graph” is more tractable than it sounds if the sequence is right. 

• Observe before enforcing: Record which agents actually call which, long enough to cover monthly and quarterly processes — the picture is almost always surprising both ways. 
• Draw edges from the business process, not the observed traffic: Codify what’s currently happening and you’ve handed your accidental topology the authority of a security control. Draw an edge only when someone can name the process that needs it. 
• Enforce per agent, not estate-wide: One agent’s refused calls are diagnosable in an afternoon; an entire estate flipping at once produces a wall of failures nobody can triage. 

An estate with an explicit graph can be reasoned about by people who didn’t build it — a new architect, an auditor, an incident responder at three in the morning. 

Where the graph is not enough 

Two honest limits, worth naming precisely because thorough AI governance — the kind NIST’s AI Risk Management Framework calls for — means being explicit about what a control does and doesn’t cover. The graph governs agent-to-agent reach; it says nothing about what an agent does with tools, connectors, and data — separate boundaries with their own gates, covered later in this series. 

And an edge is permission to call, not permission to do anything the target offers. The target still applies its own checks — the delegated authority from Part 2 arrives with the call, and the target re-derives what this principal, acting for this person, may actually do. Reachability is the outer boundary; it makes inner checks tractable by ensuring most calls never arrive, but doesn’t replace them. 

WHAT TO TAKE AWAY 

• Reachability between agents is a security boundary. Left implicit, it’s defined by network topology and address knowledge — not defined at all. 
• Draw the graph explicitly. Absence of an edge is a refusal, the default for almost every pair. 
• Write the route and the permission together so reachable-but-denied and denied-but-reachable cannot exist. 
• Keep discovery dynamic, so tightening reach never requires a deployment and therefore never gets bypassed. 
• Constraining reach from outside the agent is the one prompt-injection defense that doesn’t live in the same place as the attack. 

NEXT IN THE GOVERNED AGENT 

Part 4 — Durable Work, Human Judgment. Reachability decides what an agent can attempt. But some actions should never proceed on an agent’s judgment alone. Next: approvals that survive a server restart, and one rulebook for both business-built and developer-built automation. 

New to the series? Start with Part 1 — The Trust Gap or catch up on Part 2 — Every Agent Needs a Name.