Multi-Agent Security Has a Token Problem¶

Estimated time to read: 12 minutes

Most AI security conversations assume that more visibility is always better.

For multi-agent systems, that assumption breaks quickly.

If one agent is difficult to trace, hundreds or thousands of agents become a serious observability challenge. Each agent produces prompts, responses, summaries, tool calls, intermediate context, retrieval results, memory updates, and coordination messages. Very quickly, the system produces more telemetry than humans can review and more tokens than the architecture can economically justify.

This creates a direct tension.

To secure multi-agent systems, we need visibility. To scale them, we need restraint.

The problem is that many current agent frameworks move in the opposite direction. They generate too much context, pass too many messages, repeat too much state, and treat communication as cheap. In practice, many multi-agent systems become expensive message-passing machines rather than coordinated intelligence systems.

They move messages, not understanding.

The Security Problem And The Efficiency Problem Are Connected¶

In previous articles, I focused on why AI agents need proper threat detection. A live agent can hold valid credentials, pass IAM checks, and still do the wrong thing because its context is poisoned, its workflow drifts, or its reasoning is manipulated.

That means defenders need to observe what is happening across the workflow: the user request, retrieved context, memory, tool calls, tool responses, and final side effects.

But in a multi-agent architecture, this becomes much harder.

Every agent produces its own prompts, responses, summaries, retrieval calls, memory writes, tool traces, and coordination messages. If every agent sends everything to every other agent, the security layer is flooded with noise. If every interaction is logged and reprocessed in full, token usage explodes. If every agent carries the full history of the swarm, accuracy can degrade rather than improve.

So the challenge is not simple.

The question is not, how do we observe everything?

The better question is, how do we observe the right things, at the right boundary, with the least context required to make a safe decision?

That is where AI security and AI efficiency meet.

More Agents Do Not Automatically Create Intelligence¶

There is a common assumption that if one agent is useful, many agents must be more useful. Put enough agents together and somehow a "supermind" appears.

That is not how it works.

A collection of agents with isolated context windows passing messages back and forth is not collective intelligence. It is closer to a disorganised help desk. One agent asks another for information. That agent forwards something to another. Each one maintains its own partial state. The result is often duplication, shallow coordination, and wasted computation.

Real organisations do not work only through endless message forwarding. They depend on shared documents, collective memory, process boundaries, ownership, escalation paths, and implicit rules about what should and should not be shared.

Multi-agent systems need the same discipline.

Without structure, agents drown in shallow threads. They repeat work. They over-communicate. They pollute each other's context. They generate far more tokens than necessary and still fail to build a shared understanding.

Scale alone does not create swarm intelligence.

Structure does.

Airport Security Screening¶

A better way to think about multi-agent communication is airport security.

A passenger may have a valid ticket and passport, but that does not mean everything they carry is allowed through the checkpoint. Identity is checked, but so is the baggage. Some items pass. Some are restricted. Some need extra inspection. Some are blocked entirely. Weight matters.

AI agents need the same principle.

A valid agent identity should not mean unchecked context is allowed to move freely across the system.

Today, many agent frameworks behave as if every agent can bring unlimited baggage into every interaction. Raw web pages, retrieved documents, tool outputs, prior summaries, user messages, memory fragments, and coordination notes are passed around with too little inspection and too little discipline.

That is dangerous and expensive.

The question should not be only whether this agent is allowed to communicate.

It should also be what context the agent is carrying, where it came from, how trustworthy it is, how much of it is necessary, and what it can influence next.

That is the security checkpoint multi-agent systems are missing.

From Open Message Passing To Screened Context Movement¶

The key shift is to stop treating multi-agent coordination as a chain of open chat messages.

Agents should not dump raw context into each other's working memory. They should exchange structured, scoped, and inspected information through controlled boundaries.

In a better architecture, an agent does not simply forward an entire webpage, transcript, or tool response to another agent. It produces a smaller, labelled interpretation of the relevant information. That interpretation carries metadata, source, trust level, sensitivity, confidence, task relevance, token cost, and whether it is allowed to influence memory, tools, or downstream decisions.

Security Control Point: Instead of trying to inspect unlimited peer-to-peer chatter, the system enforces policy at the checkpoint where context crosses boundaries.

Efficiency Control Point: Instead of every agent receiving every raw detail, agents receive only the information they are allowed to see and only the amount of context required for the task.

This is how we reduce both security noise and token waste.

Context Screening¶

The first layer is context screening.

Before information crosses from one agent to another, or from a tool into shared memory, it should be inspected and classified. The default should not be "pass everything." The default should be "justify what crosses."

This means the system should inspect the content, source, destination, trust level, sensitivity, and purpose of the transfer.

A research agent should not be able to push arbitrary raw web content directly into a finance agent's context. A support agent should not be able to inject customer notes into a coding agent's working memory without a clear reason. A tool response from an untrusted website should not become high-trust shared context just because an agent retrieved it.

This matters for security because poisoned content often travels through over-permissive context sharing.

It also matters for cost because raw text is expensive. Structured, digested state is cheaper, easier to inspect, and easier to govern.

Checkpoint Question: What is being shared, who is allowed to consume it, where did it come from, what is its trust level, how much token budget does it consume, and can it influence memory, tools, or downstream actions?

That is not just efficiency.

That is security design.

Shared Memory With Chain Of Custody¶

The second layer is shared memory.

Not memory as a random pile of chat logs, but an immutable, queryable event log where the collective state of the system is stored with provenance and policy metadata.

In airport terms, this is the baggage tracking system. Items that pass through the checkpoint should be labelled, tracked, and auditable. You should know where they came from, who handled them, where they went, and whether they were cleared for further use.

Multi-agent systems need the same chain of custody for context.

A useful shared memory layer should record what was learned, where it came from, which agent produced it, which sources influenced it, what trust level it carries, and whether it can be reused in future decisions.

This directly connects to memory poisoning and persistence attacks.

If poisoned content enters shared memory without proper labelling, it can become durable. Future agents may retrieve it as trusted context and repeat the compromise. But if every memory record has provenance, sensitivity, and trust labels, the system can reason about whether that memory should be used at all.

Security and efficiency again converge.

A clean shared memory layer reduces repeated work and prevents every agent from reprocessing the same raw material. At the same time, it gives defenders a structured place to detect poisoning, drift, and suspicious influence.

Controlled Coordination¶

The third layer is coordination.

Multi-agent systems need a way to broadcast tasks, claim work, form temporary groups, and hand off responsibility without relying on uncontrolled chatter.

In a badly designed system, every agent sees too much and responds too often. That creates noise, token waste, and unnecessary security exposure. In a better system, tasks are scoped, routed, and claimed by the agents that actually need to participate.

From a security perspective, this layer is critical because many attacks emerge through sequence and workflow drift.

A single message may look safe. The coordination pattern may reveal the threat.

For example, a public-web research task should not suddenly recruit a finance-data agent, a file-search agent, and an external-network agent unless there is a valid reason. That unexpected coalition is a detection signal.

From an efficiency perspective, coordination prevents every agent from reacting to every task. Only the relevant agents should participate, and only within a defined token budget.

A multi-agent system does not become intelligent by maximising communication.

It becomes useful by minimising unnecessary communication while preserving enough shared state to coordinate correctly.

The Immune Layer¶

A multi-agent architecture also needs an immune layer.

This is the security layer that watches for poisoned data, abnormal coordination, privilege jumps, context contamination, and suspicious changes in shared memory.

The immune layer should not only scan prompts. It should monitor how context moves across boundaries.

It should detect when low-trust external content starts influencing high-trust internal decisions. It should detect when one agent tries to push excessive context into shared memory. It should detect when a workflow suddenly shifts from a public research task to internal data access. It should detect when token usage spikes because agents are repeating, looping, or broadcasting unnecessary information.

This is where AI security and AI efficiency become inseparable.

A token spike may be a cost problem.

It may also be a security signal.

Excessive communication can indicate confusion, runaway coordination, prompt injection loops, poisoned retrieval, or an agent trying to force influence into the shared substrate.

The immune layer should treat abnormal token flow as part of the threat model.

The Token Economy Is A Security Boundary¶

Agentic systems are expensive because they generate and consume large amounts of context. The exact multiplier depends on the architecture and workload, but the general pattern is clear: multi-step agents consume far more input and intermediate tokens than ordinary single-turn interactions.

That cost is not only financial.

Too much context creates security problems. It increases the amount of untrusted material entering the system. It makes detection harder. It creates larger memory surfaces. It increases the risk that irrelevant or malicious content becomes influential.

More context does not always mean better reasoning.

Past a certain point, more communication can make a system less accurate, less predictable, and harder to defend.

That means token budgets should be treated like security controls.

An agent should not be allowed to consume unlimited shared memory. A workflow should not be allowed to broadcast unlimited messages. A retrieval hook should not be allowed to inject unlimited external context. A tool response should not automatically become high-trust input.

The system needs budget-aware screening.

Every cross-agent interaction should justify both its security risk and its token cost.

What Today's Frameworks Often Get Wrong¶

Many current agent frameworks treat context as something to expand, not something to govern.

They make it easy to add more tools, more memory, more retrieval, more agents, and more messages. That is useful for demos, but dangerous in production.

The result is often an architecture that generates far more tokens than needed, creates too many implicit trust paths, and makes security teams observe an unmanageable volume of data.

That is bad engineering and bad security.

If a system needs one hundred times more tokens than necessary to coordinate basic work, it is not just inefficient. It is harder to secure. Every extra token is another piece of state to inspect, store, classify, summarise, trust, or reject.

This is why observability alone is not enough.

You cannot solve multi-agent security by logging everything forever. At scale, that becomes too expensive and too noisy. The better approach is to design the architecture so that less unnecessary information crosses boundaries in the first place.

Security should not only watch the swarm.

It should shape how the swarm communicates.

What A Better Architecture Looks Like¶

A better multi-agent architecture needs a few clear principles.

Screened Boundaries: Agents should operate behind screened boundaries. The default should be limited exposure, not open sharing.

Provenance-Aware Shared Memory: Shared memory should be immutable, queryable, and provenance-aware. The system should know where information came from, who created it, what trust level it carries, and whether it can influence future action.

Structured Coordination: Agents should not all react to everything. Tasks should be broadcast with scope, claimed by appropriate agents, and bounded by token budgets.

Security And Efficiency Signals: The immune layer should watch both security signals and efficiency signals. Poisoned data, abnormal tool chains, privilege shifts, and token explosions should all be visible.

Most importantly, the system should distinguish between raw content and digested knowledge.

Raw content is dangerous. It carries formatting, hidden instructions, adversarial text, irrelevant noise, and excessive token cost.

Digested knowledge is smaller, structured, labelled, and easier to validate.

That does not make it automatically safe. But it gives the system something it can reason about and enforce policy against.

The Broader Lesson¶

AI security and AI efficiency are often treated as separate conversations.

They are not.

In multi-agent systems, inefficient communication creates more attack surface. Excessive context sharing increases the chance of poisoning. Unbounded memory creates persistence risk. High-volume message passing makes detection harder. Poor coordination wastes computation and hides malicious behaviour inside noise.

The future of secure agentic systems will not be built by simply adding more agents, more logs, more prompts, and more guardrails.

It will require better architecture.

Context screening. Shared state. Provenance. Token discipline. Workflow observability. An immune layer that understands both security and system behaviour.

The real question is not how many agents we can connect.

The real question is whether the architecture can decide what should pass between them, what should be remembered, what should be ignored, and when the system itself is becoming unsafe.

Because without that discipline, multi-agent systems will not become collective intelligence.

They will become expensive, noisy, insecure message machines.