Google ADK Agent-to-Agent Privilege Escalation: When One AI Agent Becomes The Weapon Against Another + Video

Introduction:

In a landmark disclosure that redefines the threat landscape for AI-driven development, security researchers at Pillar Security demonstrated the first practical, real-world case of agent-to-agent exploitation inside a production multi-agent system. The vulnerability, found in Google’s open-source Agent Development Kit (ADK) for Python repository (google/adk-python), revealed that a public-facing, low-privilege triage agent—the kind anyone could interact with by opening a GitHub issue or pull request—could be manipulated through prompt injection to trigger a highly privileged maintainer-only agent. This attack chain effectively turned a trusted repository signal into a privilege-escalation path, allowing an external attacker to exfiltrate GitHub personal access tokens, Google Cloud service account credentials, and even fabricate convincing approval trails on malicious pull requests. The incident underscores a critical paradigm shift: in agentic AI systems, natural language has joined the authorization path, and trust boundaries that were once implicit must now be explicitly enforced.

Learning Objectives & Secrets:

Objective 1: Understand the Agent-to-Agent Attack Vector – Learn how a low-privilege AI agent can be manipulated via prompt injection to act as a proxy for invoking a higher-privileged agent, bypassing traditional identity and CI/CD controls.
Objective 2 Secret Tip: The “Trusted Bot Identity” Trap – Never assume that a command originating from a “trusted” bot account is legitimate if that account can be manipulated by untrusted input. The attack succeeded because the privileged workflow validated who posted the command, not whether the trusted account had itself been compromised.
Objective 3 Secret Tip: Tool Allowlists Are Not Enough – A command allowlist restricting an agent to safe `git` and `gh` operations can be bypassed using Git’s own scripting features, such as `core.hooksPath` and shell aliases, effectively granting remote code execution on the CI runner.

You Should Know:

Understanding the Attack Chain: From Public Issue to Privileged Agent

The attack begins with a public GitHub issue or pull request containing a carefully crafted prompt injection payload. The adk_pr_triaging_agent—a low-privilege agent tied to a human-style collaborator account rather than a scoped bot identity—processes this untrusted input. By embedding a command such as `@gemini-cli` or `/adk-issue-fix` in the pull request comment, the researcher tricked the triage agent into posting that command using the `adk-bot` collaborator account.

Because the privileged `issue-fix.yml` workflow checked only the identity of the commenter (owner, member, or collaborator) rather than the intent or context of the command, it treated the trigger as legitimate and executed the privileged agent. The high-privilege agent then ran with write access to issues, pull requests, and repository contents, and its environment contained a personal access token (PAT) and Google Cloud service account credentials.

Step-by-Step Breakdown of the Exploit:

Reconnaissance: Identify a target repository using multi-tiered AI agents for CI/CD automation (e.g., google/adk-python).
Craft Payload: Create a GitHub issue or pull request containing a prompt injection payload that instructs the low-privilege triage agent to post a specific command (e.g., `@gemini-cli` or /adk-issue-fix).
Trigger Triage Agent: Submit the issue or pull request. The automated `issue-analyze.yml` workflow runs the low-privilege agent, which reads the untrusted input.
Agent Handoff: The triage agent, now acting under the attacker’s influence, posts the trigger command using its collaborator account credentials.
Privileged Execution: The `issue-fix.yml` workflow sees the command from a “trusted” collaborator and executes the high-privilege agent.
Credential Exfiltration: The privileged agent’s environment—containing the PAT and cloud service account key—is compromised. The attacker exfiltrates these secrets.
Supply Chain Poisoning: Using the stolen PAT with `pull-requests: write` permission, the attacker submits fake pull requests, edits comments, and fabricates approval trails.
The Git Allowlist Bypass: Turning “Safe” Commands into RCE

In a separate attack path discovered by Pillar Security, a newer Antigravity SDK-based agent attempted to restrict commands using an allowlist that only permitted `git` and `gh` as the first token. However, the script enabled CapabilitiesConfig(), which allowed Git’s extensive scripting features to be exploited.

An attacker could hide malicious instructions in a public issue, inducing the analysis agent to invoke the fixing workflow. The fixing workflow then ran the Antigravity agent with the allowlist in place. But because Git supports hooks (core.hooksPath) and shell aliases, the attacker could bypass the allowlist and achieve arbitrary code execution on the CI runner.

Step-by-Step Guide to Understanding the Bypass:

Identify the Allowlist: The workflow script restricts commands to those whose first token is `git` or gh.
Exploit Git Features: Use Git’s `core.hooksPath` to execute arbitrary scripts when a Git command runs. Alternatively, use Git aliases to execute shell commands.
Craft the Payload: In the public issue, include a prompt that causes the analysis agent to invoke the fixing workflow with a command like git --exec-path=/path/to/malicious/hook.
Execute Arbitrary Code: The allowlist permits git, but Git’s hook mechanism executes the attacker’s script, achieving remote code execution on the CI runner.
Exfiltrate Secrets: The runner holds a long-lived personal access token and Google Cloud service account credentials, which can now be exfiltrated.

Mitigation Commands and Configurations:

Linux/macOS (Hardening Git in CI/CD):

Disable Git hooks in CI/CD environments
git config --global core.hooksPath /dev/null

Alternatively, set the environment variable
export GIT_CONFIG_NOSYSTEM=1

GitHub Actions (Securing Workflows):

In your workflow file, explicitly set permissions
permissions:
contents: read
pull-requests: write
issues: write

Disable persistent credentials to prevent token leakage</p></li>
<li><p>name: Checkout
uses: actions/checkout@v4
with:
persist-credentials: false

Google Cloud (Service Account Hardening):

Use workload identity federation instead of long-lived service account keys
gcloud iam workload-identity-pools create my-pool --location=global

Grant only the minimum necessary permissions
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:SA_EMAIL" \
--role="roles/storage.objectViewer"  Minimal scope

The Trust Boundary Problem: Why Identity Alone Is Insufficient

The core vulnerability lies not in a coding error but in a fundamental architectural flaw: the implicit trust boundary between agents. The low-privilege agent ingested untrusted text (issues and pull requests from the public) and, when manipulated, acted as a bridge to the high-privilege agent. Because the privileged workflow trusted any command coming from a “collaborator” account, it failed to distinguish between a legitimate human request and a machine-manipulated one.

As Sanchit Vir Gogia, chief analyst at Greyhound Research, noted: “Natural language has joined the authorization path. That is the change worth reporting”. This means that traditional identity and access management (IAM) controls are insufficient when an agent’s output can trigger more privileged systems.

Step-by-Step Guide to Rethinking Agent Trust Boundaries:

Treat Every Agent as a Principal: Assign each agent its own distinct identity with narrowly scoped permissions.
Never Share Human Credentials: Do not tie agents to personal access tokens (PATs) or human collaborator accounts. Use machine identities with the principle of least privilege.
Validate Intent, Not Just Identity: Implement authorization checks that consider the source and context of a command, not just the identity of the poster.
Isolate Untrusted Input: Agents that process public input (issues, pull requests, emails) should run in isolated environments with no access to production credentials.
Preserve Human Guardrails: Maintain branch protection rules, mandatory code reviews, and other human checkpoints to prevent a single compromised agent from causing a full supply chain breach.
Practical Defenses: Hardening Your CI/CD Pipeline Against Agent-to-Agent Attacks

The Google ADK incident provides a clear blueprint for securing multi-agent CI/CD pipelines. Below are actionable steps and commands to implement these defenses.

Step-by-Step Hardening Guide:

Use Separate Bot Identities: Create dedicated GitHub bot accounts or GitHub Apps for each agent, with the minimum necessary permissions.
```
Example: Using a GitHub App instead of a PAT</li>
</ol>

- name: Authenticate with GitHub App
uses: actions/create-github-app-token@v1
id: app-token
with:
app-id: ${{ secrets.APP_ID }}
private-key: ${{ secrets.PRIVATE_KEY }}
```
1. Restrict Token Scopes: Never use tokens with broad permissions. For the triage agent, use read-only permissions. For the privileged agent, limit to the specific actions required.
```
permissions:
contents: read
pull-requests: write
issues: write
Do not use `contents: write` unless absolutely necessary
```
2. Implement Tool Allowlists with Caution: If using allowlists, ensure they cannot be bypassed. Disable Git’s scripting features in CI/CD environments.
```
In your CI script, before running any Git commands
git config --global core.hooksPath /dev/null
git config --global alias.exec '!echo "Aliases disabled"'
```
3. Sanitize All Inputs: Any text that an agent reads from public sources (issues, PR comments) should be treated as untrusted. Implement prompt injection detection and sanitization.
```
Example: Basic prompt injection detection (Python)
import re
def sanitize_prompt(text):
Remove or escape known injection patterns
dangerous_patterns = [r'@\w+', r'/adk-', r'!exec', r'\${.}']
for pattern in dangerous_patterns:
text = re.sub(pattern, '', text)
return text
```
4. Audit and Monitor Agent Activity: Log all actions taken by AI agents and set up alerts for unusual patterns, such as a triage agent triggering a privileged workflow.
```
Example: Monitor GitHub audit logs via CLI
gh api -X GET /orgs/ORG/audit-log --jq '.[] | select(.action | contains("workflow"))'
```
5. The Google Response and the Bounty Controversy

Google responded by removing the three affected workflows from the `adk-python` repository and hardening the codebase. Pillar Security confirmed the workflows were absent on July 2, 2026, and Google confirmed the issue fixed on July 21, 2026.

However, Google’s Vulnerability Rewards Program panel classified the report as non-rewardable for a financial payout, citing that exploitation required an element of social engineering (a human maintainer still had to merge the malicious pull request). Google did credit the researcher with an Honorable Mention.

This decision has sparked debate within the security community. The researcher’s counter-argument is compelling: agents should have their own identity, mandating what resources they can access and interact with. An agent that borrows a human’s token inherits a human’s permissions, and no review step compensates for that fundamental architectural flaw.

What Undercode Say:
- Key Takeaway 1: The Google ADK vulnerability is not a one-off bug but a structural weakness in how multi-agent AI systems are designed. The implicit trust between agents—where one agent’s output is blindly accepted by another—creates a new class of attack surface that traditional threat models were never built to address.
- Key Takeaway 2: Organizations deploying AI agents in CI/CD pipelines must treat each agent as a separate principal with its own identity, narrowly scoped permissions, and explicit limits on which agents and resources it can contact. Prompt-injection defenses alone are insufficient if an untrusted agent can cause a privileged workflow to run.
- Analysis: The refusal to pay a bounty based on the “social engineering” requirement misses the larger point. The attack chain demonstrates that an agent’s authority should be measured not only by its assigned tools but also by the more privileged systems its output can trigger or influence. As the industry moves toward fewer human checkpoints and more autonomous agentic workflows, the “human still has to merge” argument will age poorly. The direction of travel in agentic development is toward fewer human interventions, not more, making architectural mitigations—not organizational ones—the only sustainable defense.
Prediction:
- -1 The Google ADK incident foreshadows a wave of similar vulnerabilities as organizations rush to deploy multi-agent AI systems without rethinking their security architectures. The attack surface introduced by agent-to-agent interactions will become a primary target for supply chain attacks in the coming years.
- -1 The debate over bounty eligibility—whether “social engineering” should disqualify a finding—will intensify as AI agents become more autonomous. Security teams will need to advocate for threat models that account for agentic workflows, not just traditional human-centric attack paths.
- +1 On the positive side, this disclosure has already prompted Google and other major tech companies to harden their repositories and reconsider how agents are deployed. The incident serves as a wake-up call for the industry, accelerating the development of best practices for agentic AI security, including distinct agent identities, tighter access controls, and explicit trust boundaries.
- +1 The rise of agent-to-agent attacks will drive innovation in AI security tools, including prompt-injection detection, agent behavior monitoring, and automated threat modeling for multi-agent systems. This will create new opportunities for cybersecurity vendors and researchers alike.
- -1 However, the pace of adoption of AI agents in CI/CD pipelines far outstrips the development of security controls. Many organizations will remain vulnerable to similar attacks for years, as they continue to deploy agents with overly broad permissions and implicit trust relationships, treating them as “assistants” rather than privileged code execution environments.
▶️ Related Video (80% Match):

https://www.youtube.com/watch?v=-mlL8yZj650

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: https://lnkd.in/p/ev2yTzJS – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky
Share this:

Listen to this Post

Introduction:

Learning Objectives & Secrets:

You Should Know:

Step-by-Step Breakdown of the Exploit:

Step-by-Step Guide to Understanding the Bypass:

Mitigation Commands and Configurations:

Step-by-Step Guide to Rethinking Agent Trust Boundaries:

Step-by-Step Hardening Guide:

5. The Google Response and the Bounty Controversy

What Undercode Say:

Prediction:

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

🚀 Request a Custom Project:

IT/Security Reporter URL:

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

📢 Follow UndercodeTesting & Stay Tuned:

Share this:

Related Posts: