What is it about?

AI assistants are starting to do real tasks for us: booking flights, paying for hotels, filling in forms. To get these jobs done, they often pass work on to other AI assistants run by different companies. Google's Agent-to-Agent (A2A) protocol is one of the main rulebooks for how these assistants talk to each other. We looked at what happens when the task involves our most sensitive information: credit card details, ID documents, or a private calendar. We found important gaps in the current rules. The digital "keys" an assistant receives can keep working for hours or even days. An assistant can be given far more access than the task needs. Payments can go through without a strong identity check. And nothing in the rules requires asking the user before personal data is passed on. We designed a protective layer that closes these gaps. Before anything sensitive happens, it pauses and asks the user for approval. It hands out one-time keys that expire within seconds. And it sends sensitive details straight from the user to the trusted company, so the AI assistant can organize the booking without ever seeing the card number.

Featured Image

Why is it important?

AI agents are moving from chatting to acting, and companies are connecting them to payments and personal accounts right now, while the rules for how agents communicate are still being written. This is the moment to build privacy into those rules. What makes our approach different is that it does not rely on the AI behaving well. AI models can be tricked by hidden instructions, a problem known as prompt injection. Earlier studies report such attacks succeeding 60–86% of the time. In our own small test, an agent that was told never to reveal a secret code still gave it away to another agent. Instead of adding more warnings to the AI, our design keeps sensitive data out of its reach entirely, so there is nothing to leak. And because the protections are built into the protocol itself rather than left as optional extras, every agent that uses it gets them. In our tests, the design blocked every simulated attack: reused keys, payments without a proper identity check, and a fraudulent charge hidden inside a booking. It also asked the user to approve once instead of three times, and the protective layer added less than a millisecond of processing time. The design fits European rules on payments, privacy and AI (PSD2, GDPR and the EU AI Act), and the code is openly available for developers to build on.

Perspectives

One small experiment shaped how I think about this problem. I gave an AI agent a plain instruction not to reveal a secret code, and a second agent got it out anyway. As long as sensitive data sits inside the model's context, instructions alone cannot protect it. So the question became: how can agents do useful work, like booking the trip and paying the hotel, without ever being shown the card? I hope this work is useful to people designing agent protocols and to developers building agents that handle real money and real identities. The code is openly available, and I would be glad to hear from anyone who uses it or extends it.

Yedidel Louck
Ariel University

Read the Original

This page is a summary of: Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms in Multi-Agent Systems, ACM Transactions on Software Engineering and Methodology, June 2026, ACM (Association for Computing Machinery),
DOI: 10.1145/3821216.
You can read the full text:

Read

Contributors

The following have contributed to this page