# Google's Own AI Agent Got Owned by a GitHub Issue — and That Should Worry Everyone Building with ADK
When the company that builds the model also ships the vulnerable workflow, the industry has a problem.
Google quietly deleted three automation workflows from its Agent Development Kit repository last week after a security researcher demonstrated that a crafted GitHub issue could manipulate an AI agent into taking privileged actions it was never supposed to take. The attack vector wasn't a zero-day in the traditional sense — no CVE, no memory corruption, no RCE chain. Someone just wrote the right words in a GitHub issue, and a Google-managed AI agent read them and complied.
That's prompt injection. And it just took down workflows maintained by the team teaching the rest of the industry how to build AI agents.
## The Attack Surface Nobody Wanted to Admit Existed
ADK — Google's Agent Development Kit — is an open-source framework for constructing, orchestrating, and deploying AI agents. It's been gaining traction fast as teams race to automate workflows with LLMs. Part of that push involved automating repository management with agents: bots that monitor issues, triage bugs, respond to contributors, and in some configurations, interact with Google Cloud resources.
Here's where the architecture bites back: those agents read GitHub issues. GitHub issues are public, user-submitted text. There is no meaningful distinction, from the model's perspective, between "content written by a trusted developer" and "content written by anyone on the internet." When you build an agent that reads untrusted input and holds privileged credentials, you've handed the attacker a keyboard.
The specific mechanism appears to involve crafting issue content that looks like legitimate instructions to the agent — overriding its intended behavior to instead perform actions within the scope of whatever permissions the agent holds. Depending on how the ADK workflow was configured, that could include interacting with cloud infrastructure, modifying repository settings, or triggering downstream automations.
Google's response was deletion. Three workflows, gone. No patch, no mitigation, no "here's how to harden this" — just removal.
## Prompt Injection at Scale Is Still an Unsolved Problem
This isn't a new class of attack. Riley Goodside demonstrated the basics of prompt injection in 2022. Simon Willison has been writing about it with increasing alarm for years. The OWASP Top 10 for LLMs lists it as the number one risk for a reason.
But something shifted when agentic frameworks became production-ready. Early prompt injection demos were mostly theoretical — you could make a chatbot say something weird. Now agents hold AWS credentials, push code, file bugs, and interact with SaaS platforms. The blast radius of a successful injection isn't "the chatbot said something embarrassing." It's "the agent exfiltrated secrets" or "the workflow modified a production repository."
Google's ADK incident is the clearest enterprise-grade demonstration of that shift to date. What makes it notable isn't technical novelty — it's the source. This was Google's own codebase, Google's own workflows, maintained by engineers who presumably know the risks. If a team building the tools for the industry can't ship safe agentic workflows against their own public repository, that's an indictment of how difficult this problem actually is — not a one-off mistake.
## What Google Didn't Tell You
The deletion was quiet. No security advisory was published at the time of writing. No formal CVE was assigned to the underlying workflow design. Developers who cloned ADK, studied those workflows, and built their own agents on similar patterns have no official signal that anything was wrong.
That's the gap. The workflows are gone, but the pattern they embodied — agents with privileged access ingesting user-controlled input without sanitization or a trust boundary — persists across thousands of codebases that took cues from the same documentation and examples.
Anyone running an ADK-based agent that reads GitHub issues, processes Jira tickets, ingests customer support emails, or handles any user-submitted text should treat this as a direct parallel to their architecture.
## Hardening Your Agent Before the Next GitHub Issue Finds It
The mitigations aren't exotic, but they require deliberate architectural decisions that most teams skip when moving fast:
The frameworks are maturing faster than the security understanding around them. ADK, LangGraph, AutoGen, CrewAI — all of them enable agentic patterns that carry this attack surface. The incident at Google isn't an aberration. It's a preview.
---
## HackWire Analysis
The Google ADK incident deserves more attention than it's getting, for one specific reason: this is the first high-profile case where an agentic AI framework's own maintained examples were the vulnerable artifact — not a misconfigured customer deployment.
That matters because it closes off a convenient narrative. When an enterprise misconfigures LangChain and gets burned, the post-mortems blame "poor security hygiene" at the victim organization. When Google's own ADK workflows are vulnerable to a GitHub issue, the conversation has to shift upstream — to whether the frameworks themselves are shipping safe defaults, and whether the documentation adequately communicates that any agent reading external content is processing potentially adversarial input.
The broader trend to watch: as AI coding agents like Cursor, Devin, and GitHub Copilot Workspace gain write access to codebases and CI/CD pipelines, the attack surface compounds. An agent that reads a GitHub issue and has the ability to push code or trigger a deployment pipeline is a prompt-injectable deployment mechanism. We haven't seen a major incident in that tier yet. The Google ADK case suggests we're getting closer.
For organizations moving toward agentic automation: treat any AI agent with privileged access the same way you'd treat a service account. Least-privilege, audit logging, and explicit boundaries between what the agent reads and what it can act on aren't optional best practices — they're the difference between a demo and a liability.
The deletion of those three workflows without a public advisory also raises a governance question the industry needs to answer: when a framework maintainer ships vulnerable example code that developers copy into production, does the maintainer have a disclosure obligation? Right now, the answer appears to be no. That should change.
— HackWire Editorial
---
## Related Coverage