my gt research: the privacy leak between your ai agents (week one)

the project in two sentences: when an ai assistant is really a team of agents handing a task back and forth, they tend to forward far more of your private data to each other than the task needs, and the privacy filters in common use only watch the final answer, so they never see it. ciguard is a small filter that sits between the agents, strips the private fields the task does not need, and then rewrites away the paraphrases a literal redactor would miss.

this is cs 8903 research at georgia tech this summer, advised by prof. vijay madisetti, same weekly-update habit as before. one honest note up front: i started the term on a different idea, a monitor for mcp servers that trick agents into burning compute. i spent a week on it, decided this privacy problem was more defensible to actually finish in a term, and switched. the rest of this is the new direction.

the problem, slightly longer

the paper that frames it best is agentleakExternal sourceagentleakarxiv.org (feb 2026). it instruments full multi-agent systems and measures where private attributes actually escape. the headline: inter-agent messages leak a protected attribute 68.8% of the time, against 27.2% for the final user-facing output. if you only audit the output, which is where almost every deployed guardrail sits, you miss 41.7% of the violations.

so the channels that leak the most are the channels nobody guards. perimeter tools like llama guard and nemo guardrails cut output leakage to single digits but leave the agent-to-agent and memory channels near 30%, because they inspect the boundary between the system and the user, not the traffic between agents inside it. agentleak names this gap clearly and then leaves internal-channel defense as future work. that open problem is the one ciguard goes after.

progress this week

my advisor's rule is replicate before you build, so the first thing was reproducing agentleak's leak characterization from their shipped data, then building the defense on top.

ciguard is two stages. first a deterministic step removes every value of a field that is not in the task's allowed set, which is the contextual-integrity idea: what is appropriate to share depends on the task and the recipient, not on whether a string looks sensitive. then a language-model pass rewrites what is left, to strip the paraphrases and implications a literal deletion leaves behind. "the patient's a1c was 11.2" survives a name-and-number redactor, and it should not survive this.

the numbers, on agentleak's internal channels:

• ciguard cuts semantic leakage to 14.1%, against 40.4% for the redactor agentleak ships, while keeping about 90% of the fields agents are actually allowed to use. it wins in every domain and on both channels, and the gap is not close (a paired significance test puts it past p < 1e-82).
• it does not work by quietly breaking the task. i ran live coordinator-to-worker handoffs with the gatekeeper off and on, and task success holds while leakage collapses. that held across two different model setups and four domains agentleak never tested.
• the part i cared about most: it replicates on a benchmark i did not build. on privacylensExternal sourceprivacylensarxiv.org (neurips 2024), scored by privacylens's own leak metric under two independent judges, leakage drops by half to three-quarters and helpfulness stays put.

total compute for all of this was modest api spend and no gpu.

roadblocks (and how they got handled)

the first one was the metric. to measure leakage by meaning and not just by exact string, you need a judge you can trust, and the benchmark's default judge is not one. i fed it messages that plainly leaked an ssn and a diagnosis and it called them clean at high confidence. so the headline semantic numbers needed a better judge. the fix is to anchor on agentleak's own exact-match canary detector, which ciguard also beats decisively, so the "we beat their benchmark" claim does not even depend on the semantic judge, and then validate a capable judge against that ground truth for the paraphrase cases. worth being precise: this is a measurement choice on my end, not a knock on agentleak, whose canary design is the right call.

the second was making sure i was not reinventing something. i ran a hard prior-art search to try to scoop my own idea, and i mostly succeeded at it. the closest work is abdelnabi et al.External sourceabdelnabi et al.arxiv.org, a contextual-integrity firewall on agent-to-agent messages. it is real and it is close. but it runs on a different benchmark, uses a different mechanism (learned abstraction rules rather than redact-then-rewrite), and does not cover the shared-memory channel. so i rewrote the framing to cite and distinguish it rather than claim to be first. on my advisor's actual bar, replicate a strong paper and beat its baselines, this holds up. for a top-tier venue the novelty is more incremental, and that's what we decide next week.

next week

i meet my advisor to lock the framing of the first three sections and decide the venue. after that, fold in the results sections, do a full citation pass against the related work i just dug up, and add the boring publication scaffolding.

more next week.

References

3 sources

1. 01AgentLeakPaper·arxiv.org
2. 01PrivacyLensPaper·arxiv.org
3. 01Abdelnabi et al., contextual integrity for agent-to-agent messagesPaper·arxiv.org