Google's AI Coding Assistants Could Be Tricked Into Leaking Secrets and Sabotaging Code
A newly exposed attack technique shows how a low-level AI agent inside Google's development toolkit can be manipulated into poisoning a higher-trust agent, giving attackers a path to steal credentials and tamper with software projects.
Key points
- Researchers found a flaw in Google ADK, Google's toolkit for building AI-powered coding assistants, that lets attackers pass poisoned instructions between AI agents.
- A low-privilege agent (one with limited access) could be tricked into slipping a malicious command to a higher-privilege agent (one that can read secrets and modify code).
- The attack could expose stored credentials, such as API keys, passwords that let software talk to other software.
- Attackers could also tamper with pull requests, the proposed code changes developers submit for review before software ships.
- Google's ADK is used in DevSecOps (development plus security plus operations) workflows, meaning real codebases are in scope.
Software teams have spent years worrying about humans making mistakes in code reviews. The AI assistants meant to help can be manipulated too.
Researchers disclosed a technique targeting Google ADK (Agent Development Kit), a framework companies use to build fleets of AI agents that collaborate on coding tasks. Think of ADK agents as a team of specialised robotic assistants. One might have read-only access to a project. Another might have permission to push code changes or read stored passwords.
How does the attack actually work?
A criminal crafts a hidden instruction that rides inside a routine handoff message between agents, and the higher-trust agent follows it without question.
In a normal ADK workflow, a low-privilege agent finishes part of a task and passes a summary comment to a more powerful agent so it can carry on. The attack stuffs extra hidden instructions into that comment, a technique called prompt injection, where attackers embed rogue commands inside text an AI is meant to read as ordinary content.
The higher-privilege agent treats those instructions as legitimate work orders. It could then read API keys and other credentials stored in the project environment, or alter a pull request before a human developer reviews it. A change that looks safe on screen could contain malicious code underneath.
It's a classic failure mode in new clothes: the trusted component blindly accepted input from the less trusted one. First reported by SecurityWeek, the disclosure lands as AI coding assistants are being wired into production pipelines at serious speed. We covered the broader problem of unmonitored agent behaviour on 3 August in "Why Locking Down What AI Agents Can Do Is Not Enough".
Should developers be worried?
Yes, if they're running multi-agent ADK setups without strict input validation. Many teams deploy these toolkits quickly and tune the guardrails later.
| Detail | Facts |
|---|---|
| Affected toolkit | Google ADK (Agent Development Kit) |
| Attack type | Prompt injection via agent handoff comments |
| What could be stolen | API keys, stored credentials |
| What could be tampered with | Pull requests (proposed code changes) |
| Affected workflow | Multi-agent AI coding pipelines |
For developers and engineering managers, the immediate question is whether any ADK agents in your pipeline pass unvalidated text between privilege levels. If they do, that handoff is an attack surface.
What the post-mortem will say: we assumed the agents were talking to each other, not to an adversary.
Operational takeaway: Treat every agent-to-agent message as untrusted input and sanitise it before a higher-privilege agent acts on it, the same way you'd sanitise user input before writing it to a database.
