Why Multi-Agent Systems Need Guardrails

Late 2024 saw a wave of multi-agent frameworks arrive within months of each other — CrewAI among the most talked-about, alongside a string of competitors all promising the same basic pitch: stop running one AI assistant and start running a coordinated team of them. The appeal was obvious. The risk, less so, and it is the risk that is worth spending time on, because the frameworks themselves will keep changing.

Multi-agent tooling maturing solved one problem and exposed another. Coordination got easier — agents could hand work to each other, challenge each other's output, and chain tasks that used to need manual stitching together. Risk got easier too, in the sense that it became easier to create by accident. A system that can research, draft, test, and propose changes is useful. The same system, without a clear approval path, is a liability wearing a productivity tool's clothes.

The basic shape

Agent orchestration
-> local inference
-> secret handling
-> human approval

That sequence looks obvious written down. It did not feel obvious while building it, because every framework's quick-start guide skips straight from "agents talking to each other" to "agents doing things," with the approval and secret-handling steps treated as an afterthought to bolt on later. Later is too late.

The first production uses, in my own work and in client environments, were deliberately unglamorous: security reviews, repetitive compliance checks, and first-pass content drafting. The output was good enough to save real time — but only for as long as the guardrails stayed in place. Remove any one of them and the time saved on the good days gets eaten several times over on the bad ones.

Minimum access, properly enforced

Give each agent the minimum access it actually needs for its specific task, not the access that is most convenient to configure once. In practice this means:

• A research agent gets read access to the sources it needs, not write access to anything.
• A drafting agent gets access to a scratch workspace, not to the live document store.
• Any agent that can take an action with real-world consequences — sending an email, committing code, modifying a record — gets that capability scoped to exactly that action, and nothing broader "while we're setting permissions anyway."

The failure mode here is predictable: an agent configured with broad access "to save time setting it up twice" eventually uses that access for something nobody intended, because nothing in its instructions or its permissions stopped it.

Logging before anything changes state

Log agent outputs and the reasoning behind them before any action is taken that changes a system's state. This is not optional nicety — it is the only way to reconstruct what happened when something goes wrong, and something eventually will. A chain of agents that hands off silently, with no record of what each one decided and why, turns every incident into forensic guesswork.

The useful logging discipline is simple: record the input, the decision, and the output at every handoff point, not just at the final result. If an agent crew produces a bad outcome, you want to know which link in the chain introduced it, not just that the chain, as a whole, got something wrong.

Testing for prompt injection early, not after launch

Multi-agent systems that pull in external content — web pages, documents, emails, anything not written by you — are exposed to prompt injection the moment that content reaches an agent with any ability to act. Test for this deliberately and early: feed the system content designed to instruct it to ignore its rules, leak data, or take an unauthorised action, and confirm it does not comply.

This is not a one-off test before launch. Injection techniques evolve, and a system that resisted a known attack six months ago is not guaranteed to resist a new variant today. Build the test into the same review cycle as any other security control, not as a box ticked once and forgotten.

Human checkpoints, kept where they matter

The habits that did the most for reliability were not framework-specific or clever. They were boring:

• Give each agent the minimum access it needs.
• Log outputs before anything changes state.
• Test for prompt injection and bad assumptions early, and keep testing.

Those three did more for reliability than any naming convention or framework choice — and that holds regardless of which multi-agent framework ends up winning the current round of competition.

Treating Agents as Junior Team Members

The real shift was not technical. It was treating agents as junior team members rather than clever helpers. Useful, yes. Trusted by default, no. A junior teammate can ask questions, flag uncertainty, and escalate when something looks wrong. An unchecked automation chain just keeps moving, confidently, in whatever direction its last instruction pointed it.

That distinction is the whole guardrail philosophy in one sentence. The safest multi-agent systems are boring in the right ways. They make decisions visible. They make mistakes recoverable. And they let a human step in before the wrong thing becomes the permanent thing.

If you are evaluating multi-agent AI tooling for your own organisation and want the guardrails designed in from day one rather than retrofitted after an incident, that is exactly the sort of architecture work on my services page — get in touch before you wire the first agent up to anything that matters.