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

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 accurate and properly labelled. Answer yes to all three for every hop and the pipeline still is not necessarily safe, because none of those questions ever gets asked about the combination.

The gap is easy to miss because it does not look like a security bug in the usual sense. Nothing was mislabelled. 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 once a recipient, human or agent, holds two of those correct disclosures together and does arithmetic none of the individual systems was positioned to see.

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. That example runs through the rest of this article, because it is the smallest case that cannot be fixed at either hop.

Two Different Risks That Get Treated as One

Worth separating explicitly, because the fixes do not overlap.

One risk is that a piece of context carries something that should not be trusted at all: a hidden instruction, a forged claim, data that is stale or poisoned. That is the injected-content problem, and it is what most agent-security writing, including a companion piece on this site about passing context safely, is built to solve. Redact before ingestion, tag what is trusted, fence anything that could read as an instruction, carry a provenance record across every hop. All of it necessary. None of it touching the risk this piece is about.

OWASP's Top 10 for Agentic Applications 2026 splits roughly along the same line. ASI06 covers memory and context poisoning, and ASI07 covers insecure inter-agent communication, characterised in OWASP's launch material through spoofed inter-agent messages misdirecting entire clusters. Both are integrity failures. The composition problem is a confidentiality failure with no integrity failure anywhere in it, which is exactly why a control built for one does nothing for the other.

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

The Aggregation Problem Has a Name and a Literature

This is not a new discovery about AI. Data-governance people have called it the mosaic effect for over a decade, and the US government defined it in a memo in 2013. OMB M-13-13, the Open Data Policy, puts it plainly: the mosaic effect "occurs when the information in an individual dataset, in isolation, may not pose a risk of identifying an individual (or threatening some other important interest such as security), but when combined with other available information, could pose such risk". The same memo says agencies "must account for" it, and that it "demands a risk-based analysis".

The European framing is more precise and more useful for engineers, because it enumerates what you are defending against. Article 29 Working Party Opinion 05/2014 names three risks essential to anonymisation:

• Singling out, "the possibility to isolate some or all records which identify an individual in the dataset".
• Linkability, "the ability to link, at least, two records concerning the same data subject or a group of data subjects (either in the same database or in two different databases)".
• Inference, "the possibility to deduce, with significant probability, the value of an attribute from the values of a set of other attributes".

Almost every hop-level authorization check an agent pipeline ships with is a singling-out check. It asks whether this response identifies a person. Linkability and inference are properties of a set of responses, and nothing in a per-call check evaluates a set.

NIST's guidance says the same thing structurally rather than legally. SP 800-188, De-Identifying Government Datasets: Techniques and Governance, published September 2023, spends much of its length on governance rather than technique, and recommends that agencies "create a Disclosure Review Board to oversee the process of de-identification". A review board is an architectural admission: somebody has to look at more than one release at a time, and it cannot be the system producing them.

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 check passes, because each hop only evaluates its own release.

The department example is the clean version, and the shape recurs constantly. A support agent shares a customer's order history with a fulfilment agent. A separate loyalty agent shares that customer's browsing pattern with a marketing tool. Neither disclosure is unusual alone. Together they reconstruct a profile detailed enough to break a privacy commitment neither agent's authorization check was written to consider.

How Few Facts It Takes

The reason to take this seriously rather than filing it under theoretical risk is that the empirical numbers are much worse than intuition suggests.

Table 1 — Three attributes, or four location pings. This is the budget you are working with, and most agent pipelines spend it in the first two calls.

Sweeney's conclusion, written in 2000 about static data releases, transfers directly: the practice of de-identifying data and of ad hoc generalization is not sufficient "because combinations of attributes often combine uniquely to re-identify individuals". The de Montjoye result adds the part that kills the obvious mitigation. Uniqueness "decays approximately as the 1/10 power of their resolution", so coarsening the data buys far less than it feels like it should. Halving precision does not halve identifiability.

Agent pipelines make this sharper than a data release ever did, for a reason that has nothing to do with models. A data release is a single event a human reviewed once. A pipeline emits disclosures continuously, at machine speed, to recipients that hold the results indefinitely, across systems that were never designed to know about each other's releases.

Why Stateless Checks Cannot See It

There is a clean mathematical statement of why checking each hop separately does not add up to checking the pipeline, and it comes from differential privacy rather than from access control.

Dwork and Roth's The Algorithmic Foundations of Differential Privacy (2014) gives the basic composition theorem as Theorem 3.14: the combination of an ε1-differentially private algorithm and an ε2-differentially private algorithm is ε1 + ε2-differentially private. The general form, Theorem 3.16, is summarised in the book's own words as "the epsilons and the deltas add up".

Read that as an engineering constraint rather than a proof. Privacy loss is additive over releases. A system that enforces a bound per release and keeps no running total enforces no bound at all on the sequence. This is not a subtlety of differential privacy; differential privacy is just the only framework that made the accounting explicit. Any per-call authorization check has the same property and almost none of them carry the ledger.

The Article 29 Working Party reached the same conclusion from the legal side, and it is the single most quotable line in the document for anyone designing an agent gateway. On differential privacy specifically, it warns that "by using multiple requests it might be possible to link the entries relating to a specific individual between two answers", that "it is possible to infer information about individuals or groups by using multiple requests", and therefore that "to limit inference and linkability attacks it is necessary to keep track of the queries issued by an entity and to observe the information gained about data subjects".

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 is what makes it structurally harder to govern rather than just harder to notice.

Walk it back afterwards and every hop looks correct in isolation. The spend agent did what it was built to do. The headcount agent did what it was built to do. Nobody violated their own scope. The violation exists only at the join, and the join is not owned by any of the systems that produced the pieces being joined.

Cross-organization pipelines make this sharper. An agent inside one company and an agent inside a partner company each operate under their own scope, reviewed by their own team. A2A, the agent-to-agent protocol now at version 1.0.0, has agents publish an Agent Card describing identity, capabilities and the authentication schemes a caller must use, and a client "MUST authenticate the request using one of the schemes declared in the public AgentCard.securitySchemes". That is a solid answer to who is calling. It says nothing about what the caller already holds, because no protocol at that layer could.

The recipient downstream of both is frequently the only party positioned to combine them, and frequently the party with the least visibility into how sensitive either piece was considered to be by whoever produced it.

What the Rules Already Say About Combination

If you need to argue for building something above the hops, the argument is already written into three regimes. All three assign the obligation to the discloser, and none of them accept per-release review as discharging it.

Table 2 — Three regimes, one shared assumption: the thing being assessed is the combination, and the assessor sits above the release.

The HIPAA actual-knowledge clause is the one we would put in front of a team that thinks this is a theoretical concern. It is an affirmative requirement, and it is triggered by knowledge you are quite likely to have, because you built both agents.

Designing Against Composition, Not Just Injection

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

The most direct version is a disclosure ledger keyed on the recipient rather than on the caller, checked before release rather than at ingestion. It has to record before returning data, or a concurrent second request re-runs the check against stale state and both pass.

FORBIDDEN = [
    Rule("individual_comp", trigger={"dept_spend", "dept_headcount"}),
    Rule("reidentification", trigger={"zip5", "sex", "dob"}),
]

async def may_release(recipient: str, fields: set[str]) -> Decision:
    async with ledger.lock(recipient):
        combined = await ledger.fields_for(recipient) | fields
        for rule in FORBIDDEN:
            if rule.trigger <= combined:
                return Decision.deny(rule.name)
        await ledger.record(recipient, fields)   # commit before the data moves
        return Decision.allow()

Note what the FORBIDDEN list contains. Not fields, but reconstructions. zip5, sex, dob is there because Sweeney measured it at 87%, not because any one of the three is sensitive.

Figure 2 — The ledger is the only component that sees both releases, which is why the check has to live there rather than inside either agent.

The second move is cheaper and gets you most of the way: treat repeated access across a relationship as a running total rather than a series of independent events. 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 third is the least technical and most often skipped. Name what a role should never be able to reconstruct, not only what it should never be able to request. "This role cannot see individual compensation" is a real constraint, and enforcing it means enumerating the combinations a role's access could produce.

We should be honest that none of this is complete. A ledger catches the combinations you thought of, exactly like a deny list. It does not catch the inference nobody enumerated, and the Article 29 Working Party's own verdict on every technique it reviewed applies here too: each one "fails to meet with certainty the criteria of effective anonymisation". The realistic goal is raising the cost of an accidental join and knowing which ones you have decided to accept.

Frequently Asked Questions

What is the mosaic effect? The term US federal policy uses for aggregation risk. OMB M-13-13 defines it as information that in isolation may not pose a risk of identifying an individual but, "when combined with other available information, could pose such risk". European guidance splits the same phenomenon into linkability and inference.

Is passing context between agents safe if every hop is authorized? No, and that is the whole point. Each hop's check evaluates its own release against its own scope. Neither hop evaluates the union, and the union is where the leak is. A pipeline can be perfectly compliant hop by hop and leak anyway.

Does redaction prevent aggregation leaks? Not on its own. Redaction removes things that should not be there. Aggregation leaks are built from things that should be there. Sweeney's 2000 result was specifically that removing explicit identifiers is not sufficient, because combinations of the remaining attributes re-identify people.

Is k-anonymity enough for agent-to-agent sharing? It addresses one of the three risks. The Article 29 Working Party's assessment of aggregation and k-anonymity is that singling out should no longer be possible, while linkability "remains possible to link records by groups of k users". If your exposure is inference rather than identification, k-anonymity is not the control you need.

How do I stop inference attacks in a multi-agent system? Keep per-recipient state and check the union before release, which is the 2014 guidance to "keep track of the queries issued by an entity" implemented in code. Then enumerate the reconstructions you will not allow, rather than only the fields.

Whose fault is an aggregation leak? Structurally, nobody's, which is the governance problem. Every hop was correct. Practically, whoever owns the point in the architecture that sees more than one release, which is why that component needs to exist before the incident rather than after it.

Does this only matter across organizations? No. The department spend and headcount example is entirely internal. Cross-organization pipelines are harder because neither side can see the other's disclosures, but two teams in one company with separate authorization models produce the same failure.

How is this different from prompt injection or context poisoning? Those are integrity failures: content is not what it claims to be. This is a confidentiality failure in which all content is exactly what it claims to be. Defences for the first class, provenance and fencing and trust tagging, do not detect the second, because there is nothing anomalous to detect.

Conclusion

Redaction, trust tagging and provenance solve the problem of context that should not be believed. They do not 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 will pass every hop-level check on the way to leaking through the second.

We would treat the two as separate line items on a security review, because a team that has hardened every hop against injection can walk away believing 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.

The encouraging part is that the requirement was written down twelve years ago and the mechanism is not exotic. Keep a ledger of what each recipient already holds. Check the union. Record before you release.

Sources

All URLs read 2026-09-29.

• Opinion 05/2014 on Anonymisation Techniques, Article 29 Data Protection Working Party (WP216) — the definitions of singling out, linkability and inference, the k-anonymity assessment, and the requirement to keep track of the queries issued by an entity.
• Recital 26, General Data Protection Regulation — identifiability judged on "all the means reasonably likely to be used, such as singling out".
• Simple Demographics Often Identify People Uniquely, Latanya Sweeney (2000) — 87% on ZIP, gender and date of birth, 53% on place, 18% at county level, and why removing explicit identifiers is not sufficient.
• Unique in the Crowd: The privacy bounds of human mobility, de Montjoye et al., Scientific Reports 3:1376 (2013) — four spatio-temporal points identifying 95% of 1.5 million individuals, and the 1/10-power decay with resolution.
• Open Data Policy, OMB Memorandum M-13-13 — the federal definition of the mosaic effect and the requirement to account for it.
• SP 800-188, De-Identifying Government Datasets: Techniques and Governance, NIST (September 2023) — quasi-identifier transformation, k-anonymity, and the Disclosure Review Board recommendation.
• 45 CFR 164.514, de-identification of protected health information — the expert determination method, the 18 Safe Harbor identifier categories, and the actual-knowledge clause covering information used "alone or in combination with other information".
• The Algorithmic Foundations of Differential Privacy, Dwork and Roth (2014) — Theorem 3.14 and the general statement that the epsilons and the deltas add up.
• OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project — ASI06 Memory and Context Poisoning and ASI07 Insecure Inter-Agent Communication, published 9 December 2025.
• A2A Protocol Specification, version 1.0.0 — the Agent Card, and the requirement to authenticate using a scheme declared in AgentCard.securitySchemes. </content>