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:
- https://www.secure.com/blog/cybersecurity/google-bans-openclaw-users-a-warning-shot-for-the-agentic-ai-era
- https://www.secure.com/blog/infrastructure-security/why-enterprises-dont-buy-ai-security-tools
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.
UK police database breach exposes the data of 100K+ officers and staff
Posted in Commentary with tags UK on August 4, 2026 by itnerdThe Police National Legal Database (PNLD), a legal reference service used by all 43 Home Office police forces in England and Wales, confirmed a cyberattack that exposed the contact information of more than 100,000 police officers, police staff and criminal justice professionals.
The breach was discovered on July 26, and the ExfilSquad extortion group has claimed responsibility, alleging it stole 135,000 contact records.
According to PNLD, the compromised information includes names, employing organizations and work email addresses of police officers, government partners and criminal justice personnel, along with the names and email addresses of members of the public who used the “Ask the Police” service.
Seemant Sehgal, Founder & CEO, BreachLock Had This To Say:
“A database of 135,000 verified identities across law enforcement and criminal justice, with employing organizations attached, is not contact information in the ordinary sense. That combination tells an adversary exactly who works where, in what capacity, and how to reach them directly. The downstream risk to be concerned about here is social engineering, targeted harassment, and covert approaches to personnel who would otherwise be a lot more difficult to identify and map.”
Denis Calderone, CTO, Suzu Labs Adds This:
“A simple misconfiguration in a Microsoft Power Pages portal was the impetus for this breach. PNLD’s Anonymous Users web role had read access to backend Dataverse tables, which means the subscriber database was queryable through a standard API call by anyone who visited the site without logging in. And similar to the open S3 bucket issue that was so prevalent a few years ago, ExfilSquad didn’t need to deploy malware or exploit a zero-day, they just had to hunt for misconfigured endpoints. And what was sitting behind those endpoints happened to be the names, force assignments, and work emails of 135,000 police officers, CPS prosecutors, and criminal justice professionals across all 43 forces in England and Wales.
“The real danger here isn’t that officers may get phished. Police are trained observers, professionally skeptical, and most UK forces have had security awareness reinforcement since the PSNI incident in 2023. The danger is what this data enables criminals to do to everyone else. A verified name, force assignment, and work email for a real officer is everything you need to impersonate police when contacting witnesses, victims, solicitors, or other agencies. For organized crime groups specifically, this directory is a counter-intelligence tool. You can cross-reference names and force assignments against your own operations to map who might be investigating you. And then there’s the 21,000 members of the public from Ask the Police, people who already have a relationship with law enforcement and are primed to trust communications that appear to come from police email addresses.
“This is the same group and the same access method that hit the Department for Education the week before, exposing 607,000 records. Researchers have found Dataverse-consistent structures across 11 of ExfilSquad’s 15 claimed victims, so this is clearly a systemic configuration problem across UK public sector Power Pages deployments. If your organization runs Power Pages, open an incognito browser window and query your /_api/ and /_odata endpoints right now. See what comes back without credentials. Microsoft provides a tenant-level governance control that blocks unauthenticated Dataverse reads while still allowing public form submissions. That control should have been validated before deployment, not discovered after 135,000 law enforcement contacts land on the dark web.”
Jeremiah Fowler, Researcher for Black Hills Information Security, Inc. Has This Comment:
“Threat actors often use basic contact information as the starting point for phishing campaigns, social engineering attacks, and credential theft. Law enforcement personnel face unique risks because of the nature of their work and data they may have access to. Even if the exposed information is only of contact details, these can be combined with publicly available information or previously breached datasets to build detailed profiles of officers, investigators, or even government personnel. In 2023 I discovered 500k records that were exposed that contained records associated with vehicle seizures conducted by Ireland’s national police, I have seen firsthand how law enforcement data can become publicly accessible and the risks that come with it. Once data is exposed, you can’t put the genie back in the bottle.
Law enforcement data exposures by cybercriminals is highly concerning and more steps must be taken to protect the identities and contact information of officers, investigators, and support personnel. Even when these incidents expose limited information, multiple breaches over time can provide threat actors or even nation states with enough intelligence to identify organizational structures, identify specialized units, and target individuals based on their roles or launch a more sophisticated cyberattack. The most concerning part to me is that in the age of AI where criminals have access to advanced technology, we do not know how data exposed today will be used tomorrow.”
Thoughts and prayers to anyone affected. But given that we’re in the six digits here in terms of those affected, thoughts and prayers may not be enough.
Leave a comment »