Pillar Security’s research on Google’s Agent Development Kit shows something the industry hasn’t had to reckon with yet: an attacker manipulating a low-privilege AI agent into passing a prompt to a high-privilege one, extracting a GitHub token, and then fabricating a complete “a human reviewed this” trail on a poisoned pull request that no human actually reviewed. Google fixed it through hardening, but the pattern (agent-to-agent privilege escalation inside CI/CD) is going to keep surfacing anywhere agent permissions are treated as a one-time setup instead of something requiring ongoing verification.
You can find the details here: I’ll Just Call You: Agent-to-Agent Privilege Boundary Failures in CI/CD on Google’s ADK Repository
Justin Beals, CEO & Founder, Strike Graph, an AI-native GRC and compliance automation platform had this to say:
“This is a privilege escalation attack, and the fact that it moved between two AI agents instead of two human accounts is exactly the blind spot most security programs have right now. A low-privilege agent got manipulated into passing a prompt to a high-privilege one, and from there an attacker could extract a GitHub token, edit comments to impersonate a human reviewer, and fabricate a complete approval trail for a PR that was never actually reviewed by anyone.
That last part is the real story. The attacker didn’t just gain access, they manufactured evidence of legitimate human oversight that never happened. Most governance frameworks assume that if a review comment exists and a bot approved something, a real check took place. This attack proves that assumption is dead the moment agents can act with the same privileges as the maintainers they’re supposed to be assisting.
Google fixed this through hardening, but the underlying pattern will keep surfacing across every CI/CD pipeline that treats agent permissions as a one-time setup instead of something requiring continuous verification. If you can’t produce evidence of what an agent actually did versus what its activity log claims it did, you don’t have oversight, you have a trust exercise.”
Seemant Sehgal, Founder & CEO, BreachLock had this to say:
“This is a case where the trust boundary between a public-facing agent and a privileged one was enforced by prompt design without any structural isolation in place, and that gap is what the researchers walked through. A pull request is user-controlled input. Treating anything extracted from it as a trusted instruction to a higher-privileged system is an architectural assumption that breaks the moment someone tests it deliberately.
“Every team shipping multi-agent workflows into CI/CD right now should be asking whether their privilege separation is real or whether it is just a well-written system prompt away from collapsing.”
Ryan McCurdy, VP of Marketing, Liquibase adds this:
“The bigger issue here isn’t prompt injection. It’s delegation. Enterprises are starting to put multiple AI agents into software delivery with different tools, permissions, and levels of authority. This research shows why governing each agent independently isn’t enough. Organizations also have to understand what one agent can cause another agent to do.
“A low-privileged agent shouldn’t be able to use a higher-privileged agent to get around controls it couldn’t bypass on its own. As AI becomes part of CI/CD, governance has to follow the action from the original request through every agent, tool, and permission all the way to the change that reaches production.”
Waseem Ahmed, Head of Engineering, Secure.com provided this comment:
“This is the moment the agentic attack surface shifted from theoretical to demonstrated. The attack surface is no longer just the agent; it is the trust between agents. What Pillar calls the first real-world agent-to-agent case is an identity confusion problem. A public-facing agent that anyone could reach by opening a pull request was posting its output through a bot account that happened to have collaborator privileges.
“A prompt injection could make that agent post the exact command that woke up a far more privileged, maintainer-only agent. The second agent was not talked into anything. It saw a trusted badge and obeyed. That badge became the authorization bridge, and it opened a path toward leaking tokens and poisoning the software supply chain.
“Two things keep this honest. It was a proof of concept (in the demonstrated scenario) a human approval step remained in the merge path, and an attacker would need to establish some presence before slipping in the injection. And this is not a Google problem. This is a new class of flaw across agentic CI/CD pipelines, including other vendors’ coding agents. Google was where it showed first, and they fixed it.
“The lesson is structural. Never let one agent trigger another across a privilege boundary using a signal a prompt injection can fake. Give every agent its own narrow, auditable identity instead of tying it to human accounts or long-lived tokens. Treat any agent that reads external input as potentially compromised, and design so a hijacked agent hits a dead end.
“Prompt hardening will not save you here. This is a privilege problem, not a wording problem. The time to draw those boundaries is now.”
As background, reference blogs from Waseem:
Donald McFarlane, Advisory Board Member, Xcape, Inc. said this:
“Calling this out of scope because it relied on prompt injection is a bit like dismissing a SQL injection because it relied on attacker-controlled input. Untrusted input is precisely what security boundaries are supposed to handle. Treating this as “social engineering” of an AI agent misses the architectural issue: a lower-trust principal was able to be induced to influence a higher-trust workflow across a privilege boundary.
“Bug bounty programs should recognize that attacks which seek to “live off the agent” are becoming as important as other living off the land techniques and should encourage researchers to find those trust-boundary failures rather than exclude them from scope.”
Your defenses need to question everything. As in the fact that oversight may not have happened. Which means that oversight requires oversight. Or put another way, who watches the watchers.
Related
This entry was posted on August 4, 2026 at 4:15 pm and is filed under Commentary with tags Pillar Security. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
A privilege escalation between two AI agents—not two human accounts
Pillar Security’s research on Google’s Agent Development Kit shows something the industry hasn’t had to reckon with yet: an attacker manipulating a low-privilege AI agent into passing a prompt to a high-privilege one, extracting a GitHub token, and then fabricating a complete “a human reviewed this” trail on a poisoned pull request that no human actually reviewed. Google fixed it through hardening, but the pattern (agent-to-agent privilege escalation inside CI/CD) is going to keep surfacing anywhere agent permissions are treated as a one-time setup instead of something requiring ongoing verification.
You can find the details here: I’ll Just Call You: Agent-to-Agent Privilege Boundary Failures in CI/CD on Google’s ADK Repository
Justin Beals, CEO & Founder, Strike Graph, an AI-native GRC and compliance automation platform had this to say:
“This is a privilege escalation attack, and the fact that it moved between two AI agents instead of two human accounts is exactly the blind spot most security programs have right now. A low-privilege agent got manipulated into passing a prompt to a high-privilege one, and from there an attacker could extract a GitHub token, edit comments to impersonate a human reviewer, and fabricate a complete approval trail for a PR that was never actually reviewed by anyone.
That last part is the real story. The attacker didn’t just gain access, they manufactured evidence of legitimate human oversight that never happened. Most governance frameworks assume that if a review comment exists and a bot approved something, a real check took place. This attack proves that assumption is dead the moment agents can act with the same privileges as the maintainers they’re supposed to be assisting.
Google fixed this through hardening, but the underlying pattern will keep surfacing across every CI/CD pipeline that treats agent permissions as a one-time setup instead of something requiring continuous verification. If you can’t produce evidence of what an agent actually did versus what its activity log claims it did, you don’t have oversight, you have a trust exercise.”
Seemant Sehgal, Founder & CEO, BreachLock had this to say:
“This is a case where the trust boundary between a public-facing agent and a privileged one was enforced by prompt design without any structural isolation in place, and that gap is what the researchers walked through. A pull request is user-controlled input. Treating anything extracted from it as a trusted instruction to a higher-privileged system is an architectural assumption that breaks the moment someone tests it deliberately.
“Every team shipping multi-agent workflows into CI/CD right now should be asking whether their privilege separation is real or whether it is just a well-written system prompt away from collapsing.”
Ryan McCurdy, VP of Marketing, Liquibase adds this:
“The bigger issue here isn’t prompt injection. It’s delegation. Enterprises are starting to put multiple AI agents into software delivery with different tools, permissions, and levels of authority. This research shows why governing each agent independently isn’t enough. Organizations also have to understand what one agent can cause another agent to do.
“A low-privileged agent shouldn’t be able to use a higher-privileged agent to get around controls it couldn’t bypass on its own. As AI becomes part of CI/CD, governance has to follow the action from the original request through every agent, tool, and permission all the way to the change that reaches production.”
Waseem Ahmed, Head of Engineering, Secure.com provided this comment:
“This is the moment the agentic attack surface shifted from theoretical to demonstrated. The attack surface is no longer just the agent; it is the trust between agents. What Pillar calls the first real-world agent-to-agent case is an identity confusion problem. A public-facing agent that anyone could reach by opening a pull request was posting its output through a bot account that happened to have collaborator privileges.
“A prompt injection could make that agent post the exact command that woke up a far more privileged, maintainer-only agent. The second agent was not talked into anything. It saw a trusted badge and obeyed. That badge became the authorization bridge, and it opened a path toward leaking tokens and poisoning the software supply chain.
“Two things keep this honest. It was a proof of concept (in the demonstrated scenario) a human approval step remained in the merge path, and an attacker would need to establish some presence before slipping in the injection. And this is not a Google problem. This is a new class of flaw across agentic CI/CD pipelines, including other vendors’ coding agents. Google was where it showed first, and they fixed it.
“The lesson is structural. Never let one agent trigger another across a privilege boundary using a signal a prompt injection can fake. Give every agent its own narrow, auditable identity instead of tying it to human accounts or long-lived tokens. Treat any agent that reads external input as potentially compromised, and design so a hijacked agent hits a dead end.
“Prompt hardening will not save you here. This is a privilege problem, not a wording problem. The time to draw those boundaries is now.”
As background, reference blogs from Waseem:
Donald McFarlane, Advisory Board Member, Xcape, Inc. said this:
“Calling this out of scope because it relied on prompt injection is a bit like dismissing a SQL injection because it relied on attacker-controlled input. Untrusted input is precisely what security boundaries are supposed to handle. Treating this as “social engineering” of an AI agent misses the architectural issue: a lower-trust principal was able to be induced to influence a higher-trust workflow across a privilege boundary.
“Bug bounty programs should recognize that attacks which seek to “live off the agent” are becoming as important as other living off the land techniques and should encourage researchers to find those trust-boundary failures rather than exclude them from scope.”
Your defenses need to question everything. As in the fact that oversight may not have happened. Which means that oversight requires oversight. Or put another way, who watches the watchers.
Share this:
Like this:
Related
This entry was posted on August 4, 2026 at 4:15 pm and is filed under Commentary with tags Pillar Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.