AgentLeak tests whether teams of AI agents leak private data behind the scenes

What AgentLeak is

AgentLeak is an open-source project for testing privacy leaks in multi-agent systems, setups where several AI programs pass work, notes and data to one another. As github.com reported in its repository page, it started as a research benchmark tied to a paper in IEEE Access, an academic journal. A preprint is also on arXiv.

The project now comes in two parts. The research repository holds the benchmark and the code to reproduce the paper's experiments. A separate, installable tool offers a Python library, a command-line interface, a local web interface and checks that can run inside a software build pipeline.

It was posted to Hacker News as a Show HN, the section where developers present their own projects. Per our newsletter, it had 2 points and no comments, so it is very early.

The leaks nobody reads

The core idea is that an AI system can give a spotless final answer and still have spread sensitive data along the way. Think of an assistant that summarizes a patient record. The summary may hide the person's details, while an earlier message between two agents, a log file or a tool request carried them in the clear.

AgentLeak names seven places to look. They are the final output, messages between agents, tool inputs, tool outputs, shared memory, logs and generated files, which the project calls artifacts. The tool says it can flag sensitive data disclosed in any of these.

The test scenarios span healthcare, finance, legal and corporate work. The project also lists 32 attack classes in six families, plus support for agent frameworks such as CrewAI, LangChain, AutoGPT and MetaGPT.

What the numbers say, and how far to trust them

The paper evaluates 1,000 scenarios and 4,979 validated execution traces across five models. The authors are careful to say the channels are not covered equally. The large-scale analysis covers final outputs, agent-to-agent messages and shared memory. Tool inputs and logs are checked on a sample, and tool outputs and artifacts get a smaller integration study.

The README also lists striking figures. It says internal channels leak 2.6 times more than external ones (74.0% versus 28.2%), and that checking only final outputs misses 45.9% of violations. It also reports that Claude 3.5 Sonnet had the lowest final-output leakage (8.2%) but the highest internal-to-external ratio, at 6.6 times.

Here is the catch. The repository itself warns that those README figures rest on 5,694 traces, a count that has not been reconciled with the paper's 4,979. It tells readers not to treat them as the paper's validated results or to mix the two. For rigorous claims, go to the paper.

Trying it safely

The tool needs Python 3.10 or newer. A bundled synthetic example, a healthcare patient summary, shows a clean final answer next to internal disclosures. The project calls it a demonstration, not an estimate of real-world leak rates.

Core trace analysis runs locally and does not need an LLM. Optional live runs use whichever model endpoint you configure. That means you can analyze recorded traces without sending them to another service.

• Use fake data only, such as made-up names and ID numbers.
• Run it against a staging copy, not production.
• Treat a clean result as a starting point, not a certification.

The project is MIT-licensed, a permissive license that allows free use and modification.

Who should care

The audience is teams building or buying agent workflows that touch personal or confidential data. Hospitals, banks, law firms and any company with customer records fit that description. For them, a test that looks past the final answer fills a gap that output-only checks leave open.

Non-engineers can still take a lesson from it. When a vendor says its agents are private or safe, ask what was checked: only the answer, or also the messages, logs, memory and tool calls behind it.

Caution is warranted. The project has little community feedback so far, its figures carry the reconciliation caveat above, and its coverage differs by channel. It is a promising tool and a useful vocabulary for the problem, not yet a proven standard.