The Problem of Passing Context Between Agents (And Why It's So Dangerous)

TL;DR

A context-sharing pipeline can pass every hop-level security check and still leak, because the leak lives in the combination, not in any single hop. Two agents can each hand over data that's genuinely clean and exactly as authorized as it claims to be, and the recipient can still end up holding something neither one was cleared to reveal.

Take a vendor-facing agent reporting aggregate spend by department, and a second agent, in a different tool, reporting headcount for the same department. Neither number identifies anyone. Divide one by the other for a five-person team and an individual's approximate compensation falls out.

We think most work on securing agent-to-agent context targets a narrower threat: a hostile instruction riding inside data, disguised as content. That's real and worth defending against, but it assumes the danger is something in the content that shouldn't be there. Here, every piece of content is exactly what it claims to be.

Redaction and provenance don't fix this, because they operate hop by hop and this problem only exists in the join. Catching it means asking what a recipient can infer from what they already hold plus what you're about to add, not just whether the addition is clean.

Overview

Multi-agent pipelines get built one hop at a time: an agent that reports one thing, a second agent that reports something adjacent, a system downstream that receives both. Each hop is usually reviewed on its own terms. Does this agent expose more than it should. Is this response scoped to what the caller needs. Is the data it returns accurate and properly labeled. Answer yes to all three, for every hop, and the pipeline still isn't necessarily safe, because none of those questions ever gets asked about the combination.

That gap is easy to miss because it doesn't look like a security bug in the usual sense. Nothing was mislabeled. Nobody smuggled an instruction into a document. Every individual disclosure was correctly scoped to what its own agent was allowed to share. The problem shows up only once a recipient, human or agent, holds two or more of those correct disclosures together and does the arithmetic none of the individual systems was ever positioned to see.

Two Different Risks That Get Treated as One

It's worth separating these explicitly, because the fixes don't overlap. One risk is that a piece of context carries something that shouldn't be trusted at all: a hidden instruction, a forged claim, data that's stale or poisoned. That's the injected-content problem, and it's the one most agent-security writing, including a companion piece on this site about passing context safely, is built to solve. Redact before ingestion, tag what's trusted, fence anything that could be read as an instruction, carry a provenance record across every hop. All of that is necessary. None of it touches the risk this piece is actually about.

The second risk is that a piece of context is exactly what it claims to be, correctly sourced, correctly scoped, and still becomes sensitive the moment it sits next to another piece of context that's also exactly what it claims to be. We think this is the harder problem precisely because there's no bad object to catch. A scanner built to find hidden instructions or unverified claims will pass this data every time, because there's nothing wrong with any single piece of it.

The Aggregation Problem

This has a name outside of AI systems. Data-governance teams have called it the mosaic effect for years: individually low-sensitivity facts that reconstruct something high-sensitivity once enough of them land in the same place. What's new is that agent pipelines assemble mosaics automatically, at machine speed, across systems that were never designed to know about each other's disclosures.

The department spend-and-headcount example is the clean version, but the shape recurs constantly. A support agent shares a customer's order history with a fulfillment agent. A separate loyalty agent shares that same customer's browsing pattern with a marketing tool. Neither disclosure is unusual on its own. Combined, they can reconstruct a shopping profile detailed enough to violate a privacy commitment that neither agent's own authorization check was ever written to consider, because that check only ever evaluated its own release against its own scope.

Recipient Agent B (dept headcount, authorized, clean) --> Recipient Recipient combines both --> individual compensation inferred Neither hop's own authorization check ever saw the combination. -->

Figure 1 — Two authorized, correctly scoped disclosures land at the same recipient and combine into something neither was cleared to reveal. Each hop's own check passes, because each hop only ever evaluates its own release.

Cross-organization pipelines make this sharper, not softer. An agent inside one company and an agent inside a partner company each operate under their own scope, reviewed by their own team, against their own policy. The recipient sitting downstream of both may be the only party in a position to combine them, and that party is frequently the one with the least visibility into how sensitive either individual piece was considered to be by the system that produced it.

Why Attribution Breaks Down

A single-agent injection has a culprit: the agent that got fooled, or the document that fooled it. An aggregation leak has no equivalent, and that's the property that makes it structurally harder to govern, not just harder to notice.

Walk it back after the fact and every hop looks correct in isolation. The spend agent did exactly what it was built to do. The headcount agent did exactly what it was built to do. Nobody violated their own scope. The violation exists only at the join, and the join isn't owned by any of the systems that produced the pieces being joined. That's a genuinely different failure than "an agent trusted something it shouldn't have," and treating it with the same tools, mainly by asking each hop to be more careful about what it discloses, doesn't address where the leak actually happens.

Designing Against Composition, Not Just Injection

Fixing the injected-content problem means hardening every hop. Fixing this one means putting something above the hops that can see more than one disclosure at a time, because that's the only vantage point the combination is visible from.

The most direct version is an aggregation-aware checkpoint that a recipient's data passes through before combination, not just before ingestion: something authorized to ask "what does this recipient already hold, and does adding this piece cross a line the individual releases didn't." That's a different question than either individual agent's own authorization check is built to answer, and it has to sit at a point in the architecture that actually sees both releases, which by construction is not inside either originating agent.

A second, cheaper move is treating repeated access across a relationship as a running total instead of a series of independent events. A recipient that has already received departmental spend should have that fact recorded somewhere a subsequent headcount request can be checked against, rather than evaluated fresh each time as though the earlier release never happened. Most authorization checks today are stateless in exactly this way, and statelessness is what lets the mosaic assemble one authorized piece at a time.

The last move is the least technical and the most often skipped: naming what a role should never be able to reconstruct, not just what it should never be able to request directly. "This role cannot see individual compensation" is a real constraint. Enforcing it means checking the combinations a role's access could produce, not only the individual fields a role's access grants.

Conclusion

Redaction, trust tagging, and provenance solve the problem of context that shouldn't be believed. They don't solve the problem of context that should be believed, and is, and still adds up to something none of its sources was cleared to hand over. Both problems are real, and a pipeline that only defends against the first one will pass every hop-level check on the way to leaking through the second.

We'd treat the two as separate line items on a security review, because a team that's hardened every hop against injection can walk away thinking the context-sharing problem is solved, and the mosaic assembles anyway, one clean disclosure at a time, at the one point in the system built to see them side by side.