AGENTIC PRIVACY // FIELD MAP
← field map
PART III · ECOSYSTEM · 03 OF 04§11.3–11.4 · pp. 69–72 · OP 11.6–11.9

Protocols, attestation, side channels

The wire between agents, the proof of what runs on each end, and the leaks that slip around both.
TL;DR — Today's agent protocols standardize the envelope but leave the letter as free-form text, so every message is a possible injection, leak or covert signal. One way out is to make the language between agents deliberately narrower, which trades flexibility for safety in a way nobody can yet measure. A second is attestation: hardware can prove which code is running, but for an agent the code does not determine the behavior, so the report asks what "attesting behavior" could even mean. Even a perfectly narrow channel still leaks through timing, ordering and choice of partner. And to study any of this at scale, the report points to simulated social worlds and formal coordination problems as test beds.

Section 11 is where the report stops looking at one agent and starts looking at many. The earlier parts of §11 (§11.1–11.2) deal with shared norms, delegation and the way individually fine disclosures can add up to a harm. These two subsections drop one level lower, to the plumbing: what actually crosses between agents, how one side can trust the other side's machinery, what an observer learns without reading a single message, and where researchers can run experiments that would be unsafe or impossible in live deployments. The four open problems here are less about norms and more about mechanisms, but they come back to Contextual Integrity at the end: the channel itself can encode which flows are appropriate.

OP 11.6 · Secure and robust agent-to-agent protocols

What it asks

Agents that cross organizational lines need a channel they can trust. The report wants more than encryption: a good protocol should also let agents negotiate things like shared norms safely (§11.3, p. 69).

Why the current protocols do not settle it

The report credits MCP and A2A with standardizing transport, discovery and identity. What they do not constrain is the payload. The thing inside the envelope is natural language, and neither protocol enforces policy negotiation or compliance. That one fact explains a lot. A free-text message can carry an injected instruction, can disclose more than it should, and can hide coordination between agents that a reviewer would never spot. It also hurts auditing: when syntax barely constrains meaning, a log of messages tells you little about what was actually communicated.

The report's sharper claim is that several of the risks it catalogs elsewhere, such as injection through peer messages, disclosure under persuasion, and collusion, come from the communication layer as well as from the models. Fixing the model alone leaves the channel wide open.

A way to picture this: HTTP made the web interoperable, but it does nothing to stop a page from containing a phishing form. MCP and A2A are in a similar position. They solve "can these two agents talk" and leave "should this sentence have been said" to whoever is on each end.

What the report points to

Two pieces of prior work suggest the channel can do some of the trust work itself.

"what the protocol cannot express, it also cannot leak or actuate."— the report, §11.3, p. 69

Our reading of why these two matter together: the firewall shows that a narrow channel is a security boundary, and Agora shows that agents can arrive at a narrow channel by themselves. Neither shows how to get a narrow channel that is also chosen with privacy in mind.

The report frames the result as a design space it calls largely unexplored, sitting between rigid APIs written by humans and unconstrained natural language. In that space, how expressive the inter-agent language is becomes a dial you can turn.

Point on the dialExample the report citesWhat it buys / costs
Free-form natural languageMCP and A2A payloadsMaximum flexibility; maximum injection, leakage and covert-channel surface
Negotiated structured protocolAgoraEfficient and verifiable once agreed; negotiation itself has no privacy semantics
Closed, task-scoped protocolFirewalled agentic networksCannot express (so cannot leak) off-task content; rigid when tasks change

Table: our arrangement of the systems the report names in §11.3, not a table from the report.

What a good answer would have to do

Keep the interoperability that MCP and A2A provide, while giving the payload enough structure that policy can be negotiated, checked and logged. It would also need the negotiation step itself to be safe, since that step is where an adversary would push.

OP 11.7 · Trust across agent boundaries with attestation

What it asks

Every agent interaction crosses a trust boundary. A user may trust their own agent, but does the tool provider handle the data properly? Does the peer agent apply the same security standards? Can the infrastructure operator see data in transit? The report asks whether agents can run on secure infrastructure and use attestation to build trust with the parties they deal with (§11.3, p. 69).

The classic toolkit

Confidential Computing is the established answer for distributed systems. Its building block is the Trusted Execution Environment (TEE), a hardware-enforced space that protects the confidentiality and integrity of code and data even from the operating system or hypervisor. The report acknowledges hardware and side-channel attacks on specific TEE implementations, then sets them aside on purpose: for this discussion it assumes TEEs will deliver what they claim as they mature.

A TEE enables remote attestation: a remote party can verify, cryptographically, which code is running inside, with a chain of trust that starts at the CPU maker's hardware. Add binary transparency (public, append-only logs of every binary deployed in TEEs) and reproducible builds, and a user may be able to check that the software they talk to matches reviewed, public source. For ordinary software, the report notes, that is enough: review the attested code and you know its security properties.

Why agents break it

An agent's behavior is not fixed by its code. It comes out of nondeterministic model inference over context nobody can predict.

"the same attested binary can take arbitrarily different actions depending on its inputs."— the report, §11.3, p. 70

So a perfectly attested TEE running a correct agent can still do harm, especially when an adversarial prompt steers it. Attestation answers "is this the code we reviewed?" and the honest reply can be "yes" while the agent is being hijacked. The report asks two questions it does not answer: how to extend attestation to behavior, and what "behavioral attestation" could even mean when behavior depends on inputs an attacker can control.

What can still be attested

If behavior is out of reach, the mechanisms around it may not be. The report points to work on attesting the security mechanisms that govern an agent, its execution environment, and the results of safety evaluations. Deterministic parts, like the policy engine binary and its configuration, can be attested with standard techniques. The reason this matters is delegation: a user who hands an agent credentials needs to know the guardrails actually sit in the path of every action, not merely exist somewhere in the repository.

Then the harder layer. Many guardrails are themselves models: prompt-injection classifiers, safety filters, and policy generators (the report cites Tsai & Bagdasarian, 2025, among others). A generated policy is produced at runtime from context, so it was never part of the audited binary. The report asks whether one can attest the policies a generator produces rather than only the generator, and which security properties are both meaningful for nondeterministic agents and feasible to check.

Mixed trust levels, ZKPs, and trusted third parties

Different agents will rest on very different foundations: TEEs, software-only guardrails, or nothing verifiable. The report notes there is no shared vocabulary yet for comparing or composing these trust levels. It raises zero-knowledge proofs as a possible way to reconcile two sides: give the receiving agent exactly the evidence its requirements call for, while withholding the side information the sending agent's own policy says to protect. It poses this as a question.

On the optimistic side, the report suggests that even a few agents that reliably respect contextual privacy and security could serve as trusted third parties. As in the physical world, agents that distrust each other could each hand data to a trusted analyzing agent, which computes the joint result without exposing any one party's data to the others. Better trusted infrastructure, it says, could make multi-agent workflows much more feasible.

A way to picture this: two companies want to know whether they share customers without revealing their customer lists. Today they might hire an auditor. The report imagines an attested agent playing that auditor, which only works if its behavior, not just its binary, can be trusted.

What a good answer would have to do

Define a notion of assurance that covers runtime decisions (generated policies, mediated actions), not only the code shipped. Offer a common scale for heterogeneous trust levels. Keep the TEE assumption explicit, since the report itself only assumes it holds.

OP 11.8 · Security versus utility in agent communication

What it asks

If agents talk freely, an adversarial agent can inject instructions and hijack the others' control flow. Every defense that constrains the conversation also reduces what the system can do together. The problem is to find protection that does not cost the utility (§11.3, p. 70).

The options on the table, and their costs

The report names the dilemma that runs through all of them. Fixed communication patterns resist attack but get brittle when agent capabilities change quickly. Protocols that adapt to changing needs are exposed to manipulation of the adaptation itself. Our reading: this is the same tension as in OP 11.6, now stated as a cost. The negotiation step that lets a protocol evolve is exactly where an attacker would aim.

How much expressiveness does a task need?

This is the most precise research question in the section. Narrowing the language trades adaptability for security, but there is no way to quantify the trade. The report asks, for a given task: what is the smallest language that is enough to finish it? As the language grows past that minimum, how fast do three things grow: the injection surface, the leakage capacity, and the capacity for covert channels? Are there tasks whose minimal language is already dangerous on those axes, and can they be split into sub-tasks that each need less?

A way to picture this: booking a table needs a date, a time, a party size and maybe a dietary flag. A schema with those four fields is close to the minimal language. Let the agents exchange a free-text "notes" field and every one of the three risks opens up at once. The research question is how to measure that jump rather than argue about it.

The report adds a warning. A closed protocol bounds the overt channel, but that pushes adversaries toward behavioral side channels: timing, message order, which fields get used.

Side-channel and behavioral leakage

With many agents, the room for side channels multiplies. Information can leak through observable behavior rather than message content: the timing and order of tool calls, which downstream agent gets the delegation, shared state left behind. An adversarial agent could infer something sensitive about a user just by watching which agents that user's assistant contacts, when, and in what order, even if every message is properly filtered (§11.3, p. 71).

"No current benchmark measures these implicit information flows."— the report, §11.3, p. 71

Our reading: this is traffic analysis, a long-known problem in network security, now applied to agent orchestration. Content filters, data minimization and closed protocols all work on what a message says. None of them address the fact that a message was sent.

What a good answer would have to do

Quantify the expressiveness trade-off per task, so a designer can pick a point on the dial on purpose. Treat behavioral metadata as an information flow subject to the same appropriateness judgment as content. And build benchmarks that measure it.

OP 11.9 · Realistic multi-agent environments for Contextual Integrity

What it asks

How can researchers simulate realistic agent interactions, with agents holding a user's data or acting for a business, so that complex information flows and contextual norms show up, and so the same setup supports both evaluating and training models that are contextually private and secure (§11.4, p. 71)?

Why testing in the wild does not work

The behaviors that matter appear only across long, branching conversations among several agents and their users. Real deployments give little control over the contexts in which information moves. You cannot replay them, vary one factor, or run them a thousand times.

Two families of test bed

Simulated social worlds. The report traces a line of work that drops agents into scripted social scenarios where roles and sharing norms can be set and replayed at scale. Sotopia has language agents role-play rich social situations and scores them against explicit social goals, which makes emergent multi-agent behavior measurable and repeatable. Later frameworks used the same approach to study information flow between agents. Haicosystem extends it to safety: human–AI interactions sandboxed with simulated tools and adversarial users, so that operational, societal and legal risks can be drawn out and graded over thousands of runs.

Formal coordination problems. The complementary route uses Distributed Constraint Optimization Problems (DCOPs). A DCOP spells out the agents, their local variables and constraints, and who talks to whom. That makes the knobs explicit: number of agents, network topology, local objectives, communication structure. The report notes recent work that grounded LLM multi-agent cooperation in a DCOP and audited collusion under different coalition goals, persuasion strategies and topologies. It suggests such environments could be extended to encode CI roles, information constraints and transmission principles, which would give controlled ground truth for privacy harms at scale.

Our reading of the split: simulations buy realism and messiness; DCOPs buy a known right answer. A serious evaluation program probably wants both, the first to find failures and the second to measure them.

What the benchmarks of the future should measure

The report closes the section with a wish list for moving beyond single-agent, single-flow tests toward system-level privacy assessment (§11.4, p. 72):

This ties the section together. The side channels from OP 11.8 and the aggregation harms from §11.2 are exactly what single-model CI benchmarks cannot see, and these environments are where the report expects them to become measurable.

What a good answer would have to do

Produce environments realistic enough that the failures found there also happen in deployment, controlled enough to vary one factor at a time, and instrumented to record metadata as well as content.

Securing what agents say is not enough. Decide how much language each task actually needs, attest the guardrails that mediate actions rather than trusting attested code to imply safe behavior, and treat who-called-whom-and-when as a data flow in its own right.

Connections

The aggregation example and the composition problem this section's benchmarks are meant to measure are on Shared norms, delegation, composition (§11.1–11.2). Runtime policy generation, the thing OP 11.7 wants to attest, is the subject of the contextual policy engine (§6). Delegated credentials and agent identity, which attestation is meant to back up, live on Identity, authorization, accounting (§7.1–7.3). The broader benchmark landscape, including single-model CI benchmarks the report wants to extend to many agents, is on Evaluations and benchmarks (§10). Who sets the norms these protocols should encode is the question of Governance (§12–13).

Further reading, verified

Next: Governance: whose norms, and who checks · Back to the map.