Listen to this Post
Introduction:
In what researchers are calling the first-ever documented real-world agent-to-agent exploitation, a public-facing AI agent in Google’s open-source Agent Development Kit (ADK) for Python was manipulated into triggering a highly privileged maintainer-only agent. The attack, discovered by Pillar Security researcher Dan Lisichkin, exploited a trust boundary failure between two AI agents operating at different privilege levels within the same GitHub repository. This vulnerability demonstrates that AI agents ingesting untrusted text—such as GitHub issues and pull requests—while holding credentials must be treated as potential attacker-controlled vectors.
Learning Objectives & Secrets:
- Objective 1 – Understand Agent-to-Agent Privilege Escalation: Learn how a low-privilege, internet-exposed triage agent can be manipulated via prompt injection to invoke a high-privilege agent, effectively crossing trust boundaries without direct authentication bypass.
-
Objective 2 Secret Tip – Bot Identity as Authorization Bridge: The attack succeeded because the privileged workflow validated who posted a triggering comment, not whether the trusted account had itself been manipulated. Always verify the source of a command, not just the identity claiming to send it.
-
Objective 3 Secret Tip – Command Allowlists Are Not Silver Bullets: A command allowlist restricting the agent to safe `git` and `gh` operations could be bypassed using git’s own scripting features—
core.hooksPathand shell aliases—turning an apparently safe tool into a path to arbitrary code execution. Allowlists must be evaluated in the context of the tool’s full attack surface.
You Should Know:
- The Attack Chain: From Public PR to Privileged Execution
The google/adk-python repository, a Python toolkit with more than 90 million downloads, ran two classes of automated AI agents. The lower-privilege, public-facing agent activated whenever a user opened a pull request or issue. A second, high-privilege maintainer-only agent possessed broad repository and cloud credentials.
Pillar’s attack unfolded as follows:
Step 1: An attacker opened PR A—a seemingly legitimate pull request combining a real fix with malicious code, such as a modified `package.json` or a malicious dependency.
Step 2: The public-facing `adk_pr_triaging_agent` read the attacker’s PR text and marked it for review. This agent was tied to a high-privilege collaborator personal access token (PAT).
Step 3: The attacker crafted PR B containing a prompt injection. The triage agent emitted a trusted `@gemini-cli` handoff, triggering the privileged `gemini-invoke.yml` and `gemini-review.yml` workflows.
Step 4: The privileged workflow executed with full repository write access, allowing the attacker to extract the GITHUB_TOKEN, modify PR comments, impersonate maintainers, and fabricate an entire believable approval trail.
The critical insight: because the agent commented using a real collaborator account (adk-bot with Collaborator privileges), GitHub treated the trigger as coming from a trusted human. The trusted bot identity itself became the authorization bridge.
2. The Antigravity SDK Bypass: When Allowlists Fail
Days after initial disclosure, Google added new Antigravity SDK-based automation to the same repository—and introduced a fresh vulnerability. The workflow `issue-fix.yml` listened for `/adk-issue-fix` comments and restricted execution to owners, members, or collaborators. However, the gate checked who posted the command, not whether an outsider had manipulated the trusted account behind it.
The privileged job ran a script (run_antigravity.py) that rejected shell metacharacters and allowed only commands whose first token was `gh` or git. But the script enabled CapabilitiesConfig(), which Antigravity SDK documentation says turns on all tools, including writes. More critically, the command allowlist could be bypassed using git’s own scripting features:
Bypass via git alias git config alias.exec '!sh -c "malicious_command"' git exec Bypass via core.hooksPath git config core.hooksPath /path/to/malicious/hooks git commit --allow-empty -m "trigger hook"
Because the runner held a long-lived personal access token and Google Cloud service account credentials, an attacker who simply opened a GitHub issue—no privileged access required—could potentially exfiltrate sensitive secrets from the pipeline.
3. GitHub Actions Token Permissions: What Went Wrong
The affected workflows declared permissions that created a dangerous mismatch:
Vulnerable pattern from the ADK repository permissions: issues: write pull-requests: write contents: write
The privileged job declared write access to issues, repository contents, and pull requests. These settings applied to GitHub’s generated GITHUB_TOKEN, not the `ADK_TRIAGE_AGENT` PAT the job actually used. The PAT’s exact scopes were not public, but it was sufficient to check out the repository, authenticate to Google Cloud, and run the agent with the PAT and API key in its environment.
To harden workflows against similar attacks:
Least-privilege pattern permissions: contents: read Read-only by default pull-requests: read issues: read No write permissions unless absolutely necessary
If write access is required, scope it to the specific job and use OpenID Connect (OIDC) instead of long-lived PATs:
jobs:
privileged-job:
permissions:
id-token: write Required for OIDC
contents: read
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
4. Detection and Monitoring for Agent-to-Agent Attacks
Security teams should monitor for indicators of agent-to-agent compromise:
Linux/Unix command to audit GitHub Actions runner logs:
Search for suspicious git commands in runner logs grep -E "git\s+config|git\s+commit.--allow-empty|gh\s+api" /var/log/github/runner/.log Monitor for unexpected tool invocations auditctl -a always,exit -F path=/usr/bin/git -F perm=x -k git_execution ausearch -k git_execution --format text
Windows PowerShell for GitHub Actions secret exfiltration detection:
Monitor for unusual PAT usage in GitHub audit logs
Get-GitHubAuditLog -Event "token.access" -StartTime (Get-Date).AddHours(-24) |
Where-Object { $<em>.Actor -like "bot" -and $</em>.Action -eq "token.access" }
Check for unexpected workflow trigger patterns
Get-GitHubWorkflowRun -Repository "google/adk-python" -Status "completed" |
Where-Object { $<em>.TriggeringActor -1e $</em>.Actor }
GitHub-1ative detection:
- Enable GitHub Advanced Security secret scanning
- Configure Dependabot alerts for dependency confusion risks
- Review the `audit.log` for `workflow_dispatch` events from unexpected actors
5. Practical Hardening: Securing Multi-Agent CI/CD Pipelines
Based on the ADK vulnerability, implement these defensive controls:
Separate Bot Identities: Never tie a public-facing agent to a human-style collaborator account. Use dedicated bot accounts with narrowly scoped permissions.
Enforce Strict Tool Allowlists with Context: Allowlists must be evaluated against the full attack surface of each tool. For git, consider:
Restrict git to safe operations via allowed commands list
allowed_git_commands=("status" "diff" "log" "show" "branch")
for cmd in "${allowed_git_commands[@]}"; do
if [[ "$user_input" == "git $cmd" ]]; then
execute "$user_input"
else
echo "Command not allowed"
exit 1
fi
done
Implement Authorization Signals: Untrusted text should never generate a privileged command. Use structured signals:
Vulnerable: trusting LLM output directly
if "approve" in agent_response.lower():
trigger_workflow("approve-pr")
Safer: require structured, verified signal
if agent_response.get("action") == "approve" and verify_signal(agent_response):
trigger_workflow("approve-pr")
Preserve Human Guardrails: Branch protection, mandatory code review, and required status checks prevent a single compromised agent from cascading into a full supply chain breach.
Use Short-Lived, Scoped Credentials: Prefer the automatic `GITHUB_TOKEN` with read-only defaults over long-lived PATs stored as secrets. The built-in token is scoped to the running repository and expires when the job ends.
What Undercode Say:
- Key Takeaway 1: The ADK vulnerability represents a structural weakness in multi-agent systems, not a one-off bug. As AI agents gain more tools, data, and system operations, permission control and human approval have become enterprise defense priorities. Traditional threat models were never built to address agent-to-agent trust boundary failures.
-
Key Takeaway 2: The attack required no sophisticated hacking skills—“you just need to know English to build the prompt injection (or just ask an AI to do it for you)”. This democratization of attack capability means every organization deploying AI agents in CI/CD pipelines must reassess their threat models. The fact that Google deemed the exploit non-rewardable because it involved social engineering highlights a dangerous gap: supply chain attacks that require social engineering are still supply chain attacks, and AI makes them easier to execute at scale.
Prediction:
-
+1 The ADK disclosure will accelerate the development of standardized security frameworks for multi-agent systems. OWASP’s 2026 LLM Top 10 has already elevated “Excessive Agency” from 6 to 3, and we can expect dedicated agent-to-agent security standards to emerge within 12–18 months.
-
-1 Organizations that deploy AI agents with broad, un-scoped credentials will face increasing incidents of lateral movement and privilege escalation. A 2026 survey found that 76% of organizations don’t fully govern or monitor nonhuman identities, including AI agents—a gap that attackers will aggressively exploit.
-
-1 The “social engineering” defense used by Google’s VRP panel sets a dangerous precedent. If prompt injection in a public GitHub issue that manipulates an AI agent into exfiltrating cloud credentials is deemed “non-rewardable,” it disincentivizes responsible disclosure of AI-specific attack vectors. Expect more researchers to weaponize rather than report similar flaws.
-
+1 The incident will drive adoption of zero-trust principles for AI agents: hardware-backed cryptographic signatures for actions, kernel-level sandboxing (e.g., gVisor), and deterministic semantic gateways for I/O validation. Google’s own ADK documentation now emphasizes these controls.
-
-1 The attack surface will only grow as AI agents move from single-assistant to multi-agent pipelines. With GitHub Actions workflows now routinely delegating repository hygiene to AI agents, we will see a wave of similar vulnerabilities across major open-source repositories before the security community catches up.
▶️ Related Video (84% Match):
https://www.youtube.com/watch?v=5ZA1lTxTH3c
🎯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/ex24srzr – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
