Security researchers have disclosed a new class of AI security issue affecting Google’s Agent Development Kit for Python, commonly known as ADK for Python.
The finding shows how one AI agent can be manipulated into triggering another, more privileged AI agent, creating a path toward supply-chain compromise inside CI/CD workflows.
The issue was discovered by Pillar Security in the google/adk-python repository. Dark Reading reported the issue under the headline “Google APK for Python,” but the affected project is Google’s ADK for Python, the open-source framework used to build and orchestrate AI agents.
What Happened
The vulnerable setup involved two classes of automated AI agents inside the repository.
The first class was low-privileged and public-facing. These agents processed external input such as GitHub issues and pull requests.
The second class was higher-privileged and intended only for maintainers. These agents could perform more sensitive repository actions.
According to Pillar Security, the core problem was that the low-privileged agent could be manipulated through prompt injection to trigger the higher-privileged agent.
That created an agent-to-agent privilege escalation path.
Instead of attacking the privileged agent directly, an attacker could influence the public-facing agent and make its output look like a trusted command.
Why This Is Different From Classic Prompt Injection
Traditional prompt injection usually targets a single AI system.
An attacker places malicious instructions inside untrusted content, such as a webpage, issue, email, or pull request, and hopes the agent follows them.
This case is more serious because the compromised agent became a bridge to another agent.
The low-privileged agent did not need to perform the most dangerous action itself. It only needed to trigger a second workflow that had more authority.
That is the key lesson: in multi-agent systems, one agent’s output can become another agent’s instruction.
This makes agent-to-agent communication a new trust boundary.
The GitHub Workflow Attack Path
Pillar Security found that Google’s ADK repository used AI workflows to help manage pull requests and issues.
One public-facing triage agent could read pull request content, label items, and post comments. The problem was that its comments appeared from a trusted account with collaborator-level privileges, not from a low-trust isolated bot identity.
Researchers showed that attacker-controlled pull request or issue content could influence that agent into posting a specially formatted command.
That command was then interpreted by a dispatcher workflow as if it came from a trusted maintainer and routed to a more privileged Gemini-based automation.
In practical terms, the attacker’s prompt injection could cross from an untrusted public contribution into privileged repository automation.
Why This Matters for the Software Supply Chain
CI/CD systems already hold powerful credentials.
They can run tests, build packages, publish releases, label pull requests, review code, write comments, and sometimes access cloud services or secrets.
When AI agents are added to those pipelines, they inherit part of that authority.
The ADK case shows how dangerous that can become when public input, agent reasoning, and privileged automation are connected without strong authorization boundaries.
Cloud Security Alliance noted that Google removed three GitHub Actions workflows after the demonstration and that the affected workflow design could expose sensitive credentials and enable pull request tampering.
A Second Weakness: Tool Allowlist Bypass
The research also found a separate issue in newer agent workflows.
Those workflows attempted to restrict command execution by allowing only certain tools such as GitHub and Git commands.
But allowing a tool does not mean every behavior of that tool is safe.
Cloud Security Alliance summarized that the command allowlist could be bypassed through Git mechanisms, turning an apparently safe command path into arbitrary code execution on the CI runner.
This is a common security lesson in a new AI context: validating the tool name is not enough. Security controls need to understand what the tool can actually do.
What Google Did
Pillar Security said the issue was reported to Google in early June 2026.
The affected workflows were removed or remediated in July, and Google confirmed the issue was fixed on July 21, 2026.
Cloud Security Alliance reported that Google deleted three affected workflows and hardened the repository after the findings were demonstrated.
The immediate issue has been addressed, but the broader lesson applies to any organization building multi-agent automation.
The Real Problem Is Delegation
The most important takeaway is not only “prompt injection.” The deeper issue is delegation.
Enterprises are beginning to deploy multiple AI agents with different permissions. Some read issues. Some review code. Some write fixes. Some call tools. Some interact with CI/CD systems. Some hold credentials.
If one low-privilege agent can cause a high-privilege agent to act, the boundary between them becomes part of the attack surface.
A low-privileged agent should not be able to make a higher-privileged agent perform an action that the first agent could not perform directly.
That is the principle security teams need to enforce.
What Organizations Should Learn
Any team using AI agents in development workflows should review how agents communicate and what each one can trigger.
Important questions include:
- Which agents process untrusted content?
- Which agents hold credentials or write permissions?
- Can one agent trigger another agent?
- Are agent commands verified independently?
- Are bot identities separate from human maintainer accounts?
- Are credentials short-lived and narrowly scoped?
- Is there human approval before privileged actions?
- Can agent outputs be treated as untrusted unless proven otherwise?
Pillar Security emphasized that the compromise lived in the “seams” between agents: delegation, impersonation, triggering, and the gap between what a permission appears to allow and what it can enable when chained with other components.
Recommended Defensive Actions
Organizations using AI agents in CI/CD should:
- separate low-trust and high-trust agents
- treat all external issues, pull requests, tickets, and comments as hostile input
- avoid using human collaborator tokens for automation
- use dedicated bot identities with minimal permissions
- require independent authorization for privileged agent actions
- use short-lived credentials instead of long-lived tokens
- avoid giving public-facing agents access to secrets
- review tool allowlists for bypassable behavior
- log all agent-to-agent handoffs
- red-team multi-agent workflows, not only individual agents
Most importantly, teams should stop assuming that an internal agent message is automatically trustworthy.
If that message was influenced by untrusted content, it should remain untrusted.
Final Thoughts
The Google ADK for Python issue is an important warning for agentic AI security.
The vulnerable workflow did not simply involve one model making a bad decision. It showed how one AI agent could be manipulated into activating another agent with greater authority.
That is a new kind of privilege escalation.
As organizations connect AI agents to GitHub, CI/CD systems, cloud platforms, issue trackers, and deployment pipelines, the security model must evolve.
