Your System Prompt Says 'Never.' Your Agent Heard 'Maybe.'

Day 2 — Authority Boundaries: Why the Reverse Proxy Beats the Prompt

If a multi-agent system has a rule that must never be broken, the layer you put it in decides whether that rule is a guarantee or a suggestion. Get this one decision wrong and every other safeguard you build on top of it is decoration.

I watched a team spend two weeks hardening a system prompt for an agent that could call a payment API — layered instructions, few-shot refusals, explicit 'never call refund without approval' warnings in bold caps. The agent still called the forbidden endpoint. Not because the prompt was sloppy. Because the guardrail lived in a place that could be talked out of itself.

What a reverse proxy actually is

For anyone who skipped Day 1's framing of it as 'legacy' infrastructure: a reverse proxy is a program that sits between a caller and a service and decides what gets through — before either side even knows a decision was made. That's it. Nginx, Envoy, an API gateway — same idea. It's boring, decades-old, and that's exactly the point.

The core distinction: persuasion vs. physics

• ▹A prompt is a suggestion made TO the agent — it lives in the same channel the agent reasons in, so anything that can shift reasoning (a jailbreak, a crafted tool description, a confusing user message) can shift the rule too.
• ▹A proxy rule is a constraint made ON the agent — it lives outside the reasoning loop entirely. The agent doesn't get a vote.
• ▹One is persuasion. The other is physics. You can argue with a system prompt. You cannot argue with a closed port.

Concretize: the payment-API rule, two implementations

Same rule — 'this agent may never issue a refund without human approval' — implemented two ways.

# Implementation A: buried in the system prompt
SYSTEM: You are a support agent. You have access to a `call_tool`
function. IMPORTANT: never call the refund endpoint
(POST /payments/refund) without explicit human approval in
the conversation. This is a strict rule you must always follow.

# Implementation B: a route rule at the proxy in front of the
# tool-call endpoint
route:
  match: { path: "/payments/refund", method: "POST" }
  require_header: { name: "x-human-approved", value: "true" }
  on_missing: { action: "deny", log: true }

Implementation A survives exactly as long as nothing perturbs the model's reasoning: no jailbreak, no misleading tool description, no model upgrade that quietly changes how the instruction gets weighted. Implementation B doesn't care what the model 'believes' — the request either carries the header or it doesn't. Only one of these survives contact with an adversarial or simply careless input.

Why this matters more for multi-agent systems

With one agent, a bad prompt is one bad prompt. With N agents — planner, researcher, executor, whatever your topology is — you now have N prompts that all need to encode the same rule identically, and N places for that rule to quietly drift as each prompt gets tuned independently. A single proxy config in front of the shared tool-call surface is the one source of truth all N agents inherit automatically, whether or not whoever wrote agent #7's prompt remembered the rule exists.

The audit payoff

Proxy logs give you a diffable, replayable record of every tool call every agent attempted. 'Which agent tried to do what, and was it blocked' becomes a grep against structured logs — not a forensic reconstruction of chat transcripts across N agents' context windows, hoping the relevant turn wasn't summarized away.

The honest limit

A proxy can't stop an agent from writing a bad summary, drawing a wrong conclusion, or reasoning badly about data it already has. It only governs what crosses a network boundary. That makes it an authority boundary, not a correctness boundary — and you still need other tools (evals, review, monitoring) for the reasoning half of the problem. Don't mistake 'the agent can't call the forbidden API' for 'the agent is right.'

Most of the multi-agent coordination failures I look at in my RMIT research aren't reasoning failures — they're authority failures. And authority failures get fixed by moving the rule to the one layer that was never persuadable to begin with.

Extend your knowledge

• ▹Look at how API gateways like Envoy, Kong, or NGINX express allow/deny rules and rate limits — the same policy patterns map directly onto gating agent tool calls.
• ▹Read OWASP's Top 10 for LLM Applications material on prompt injection to see why prompt-only defenses are treated as insufficient by design, not just in practice.
• ▹Revisit Day 1's framing of the reverse proxy as 'legacy' infrastructure and connect it to today's authority-vs-correctness split.
• ▹If you run a multi-agent stack today, pick one high-stakes tool-call endpoint and put a route rule in front of it this week — then grep the logs for the first blocked call.