The privacy failure that breaks an agentic workflow may not look like a chatbot blurting out a Social Security number. It may look boring. A routing agent summarizes a customer case for a specialist agent and includes more history than the specialist needs. A planning agent passes a full tool result into a second agent because it is convenient. A support copilot writes a sensitive inference into long-term memory because it might be useful later. A trace captures tool arguments that were never meant to become reusable context.
That is the uncomfortable point behind the new paper, “MNC: Scope-Bound Semantic Declassification for Private LLM-Agent Communication.” The authors argue that multi-agent LLM systems can expose protected state through internal messages, tool arguments, logs, and persistent memory even when the final user-facing answer appears clean. In other words, the leak is not only at the edge of the product. It is inside the workflow.
That matters because most teams still reach for the wrong control first. They add redaction to the final answer. They filter logs. They write a prompt telling the model not to reveal sensitive details. Those controls can help, but they are cleanup tools. They do not answer the harder design question: when one agent legitimately knows something, what exactly is it allowed to tell another agent, for which purpose, for how long, and with what downstream reuse limits?
Access is not disclosure
Agent builders already have a vocabulary for access control. A tool may require OAuth. A server may require a scoped credential. The Model Context Protocol authorization specification, for example, treats authorization as a formal boundary around access to protected resources. That boundary is necessary. It helps decide whether an agent may call a tool or reach a resource at all.
But access control does not automatically solve disclosure. Imagine an intake agent is authorized to read a full support ticket. The refund agent may need the order number, refund amount, and the reason code. It probably does not need every prior conversation, the customer’s unrelated account notes, or a private internal assessment. If the intake agent forwards the whole ticket as “context,” the system may be authorized in one sense and still careless in another.
That is the distinction MNC makes useful. The paper frames the problem as scope-bound semantic declassification: not just which strings to block, but which meanings may move across a boundary. A receiving agent may need a derived fact, a narrow field, or a yes/no eligibility determination. It does not necessarily need the raw evidence behind that determination.
This is a more mature way to think about agent privacy. It treats communication as an architectural surface, not a prompt hygiene problem.
Redaction is a seatbelt, not the road design
Redaction tends to happen after data has already traveled too far. By the time a filter removes a phone number from a final answer, the raw value may already have moved through a planner, a retriever, a tool argument, a debug trace, a memory candidate, and a queue message. In a single-model chatbot, that path is already hard to reason about. In a multi-agent system, it becomes a small supply chain.
The practical failure mode is “redaction theater”: the visible output looks safe, but the workflow still spreads sensitive state internally. A system can pass a demo because the UI is clean while still creating audit, retention, and misuse risk in the background.
A minimum-necessary communication layer changes the default. Instead of asking, “Can this agent see the source?” it asks, “What is the smallest semantic payload this next step needs?” Instead of forwarding raw context, it sends a purpose-limited disclosure. Instead of treating memory as a harmless cache, it gates memory writes as a separate act with its own scope.
That framing also fits broader privacy risk management. The NIST Privacy Framework does not reduce privacy to one filter or one policy statement. It treats privacy as an organization-wide risk discipline: understanding data processing, governing controls, communicating clearly, protecting data, and improving over time. Agent communication belongs in that same discipline. The handoff is processing. The tool argument is processing. The memory write is processing.
What builders should implement
The first practical step is to inventory agent boundaries. Every handoff deserves a name: planner to executor, intake to specialist, retrieval agent to writer, supervisor to subagent, agent to tool, agent to memory, agent to log. If a workflow diagram only shows boxes and arrows, it is not done. Each arrow needs a communication contract.
A useful contract should answer at least seven questions.
First, what is the purpose of the disclosure? “Help the refund agent decide eligibility” is better than “provide context.” Purpose matters because it limits what can be included.
Second, who is the recipient? A human reviewer, a specialist agent, a tool server, and a memory store should not receive the same payload by default.
Third, what fields or derived facts are allowed? The safest payload is often not a redacted transcript; it is a structured summary with only the necessary facts.
Fourth, what source constraints remain attached? If a fact came from a private note, a user message, a system observation, or a tool result, the receiving component should not lose that provenance.
Fifth, how may the recipient reuse the information? A fact that can be used to answer the current ticket may not be allowed to train a future preference, update long-term memory, or appear in a cross-customer analytic summary.
Sixth, how long may it persist? Transient context, audit evidence, and durable memory are different storage classes.
Seventh, what evidence proves the contract was followed? If the system cannot reconstruct what was disclosed, to whom, and why, it will struggle to debug incidents or satisfy enterprise review.
These questions sound heavy, but they can be implemented incrementally. Start by replacing free-form inter-agent messages with typed handoff schemas. Add allowlists for fields and derived claims. Make tool arguments visible in traces, but avoid dumping unnecessary raw records into those arguments. Separate “use this for the current step” from “store this for future tasks.” Add tests that simulate adversarial handoffs: a downstream agent asks for extra context, a summarizer includes protected details, or a memory writer tries to persist a sensitive inference.
This is where the broader agent-engineering advice from Anthropic’s “Building Effective Agents” is relevant. Reliable agents are not magic prompts. They are systems: workflows, tools, boundaries, evaluations, and human-understandable control points. Minimum-necessary communication is one of those control points.
The business case is not only privacy
A communication contract reduces privacy risk, but it also makes agent systems easier to operate. Smaller payloads are easier to inspect. Purpose-limited handoffs are easier to test. Scoped memory writes are easier to revoke. Auditors get a cleaner story.
It also lowers blast radius. If a specialist agent is compromised, confused, or prompt-injected, the damage is bounded by what it received. If a log sink is overexposed, it contains structured minimal facts rather than raw context dumps.
The important shift is cultural. Teams should stop treating internal agent messages as harmless implementation details. In an agentic product, internal communication is product behavior. It can disclose, transform, retain, and authorize. It deserves the same design seriousness as APIs and database schemas.
MNC is a research proposal, not a turnkey enterprise standard. But its central lesson is immediately useful: privacy in agent systems is not achieved by hiding bad strings at the end. It is achieved by controlling meaning as it moves through the workflow.
If your agents collaborate, delegate, remember, and call tools, give every handoff a minimum-necessary contract. Redaction can still be the seatbelt. It should not be the road design.
Build AI Systems That Survive Contact With Real Work
We help teams turn AI research into practical automations, agent workflows, and operational systems that can be evaluated and improved.
Get the Field Guide — $10 →