On July 2, 2024, Pillar Security confirmed that Google removed several vulnerable workflows from its Agent Development Kit (ADK) for Python. The issue? AI agents could be manipulated into executing privileged operations by trusting messages from unverified sources. No data breach occurred, but the vulnerability highlighted a fundamental problem in AI-powered automation: we're imposing human-style trust relationships on systems that need explicit authorization boundaries.
What Happened
Google's ADK allowed developers to build AI agents that interact with GitHub repositories and other development tools. Pillar Security identified two attack paths where an attacker could manipulate these agent interactions.
The first involved a triage agent that accepted '@gemini-cli' commands in GitHub issues. A malicious actor could post such a command, triggering a workflow meant for trusted users. The agent didn't verify whether the command came from an authorized source; it just executed based on the '@gemini-cli' syntax.
The second path exploited how agents passed context between each other. An attacker could craft inputs that, when processed by one agent and passed to another, would cause the downstream agent to execute privileged operations like approving pull requests or exposing credentials.
Google patched the affected workflows after Pillar's disclosure. No timeline was provided for how long the vulnerable code was in production.
Timeline
- Pre-July 2024: Vulnerable workflows present in Google's ADK for Python
- July 2024: Pillar Security identifies and reports the vulnerabilities to Google
- July 2, 2024: Pillar Security confirms Google removed the affected workflows
Which Controls Failed or Were Missing
Missing input validation on agent triggers. The triage agent accepted '@gemini-cli' commands without verifying the issuer's identity or authorization level. In a traditional application, you'd never execute a privileged function just because a user typed the right syntax. But because the command looked like natural language, it bypassed the authorization check.
No boundary enforcement between agent contexts. When agents passed data to each other, they treated the output of one agent as trusted input to another. This created transitive authority: if Agent A trusts Agent B, and Agent B processes attacker-controlled input, then the attacker inherits Agent A's privileges through Agent B.
Lack of privilege separation in workflow design. The same agent that processed untrusted input (GitHub issue comments) also had the authority to trigger privileged workflows. There was no separation between the parsing layer and the execution layer.
Insufficient logging and monitoring of cross-agent interactions. Without visibility into how agents invoke each other, you can't detect when a low-privilege agent is triggering high-privilege operations.
What the Relevant Standards Require
NIST 800-53 Rev 5, AC-3 (Access Enforcement) requires that systems enforce approved authorizations for logical access. This applies to agent-to-agent interactions just as it does to user-to-system interactions. You need explicit authorization checks before any privileged operation, regardless of how the request arrives.
OWASP ASVS v4.0.3, Section 4.1 (General Access Control) states that access control decisions must be based on verified identity and authorization, not on the format or source of the request. Accepting '@gemini-cli' as sufficient authorization violates this requirement.
ISO/IEC 27001:2022, Control 8.3 (Information Access Restriction) requires that access to information and systems be restricted based on business requirements and authorization. The ADK workflows granted access based on syntax patterns rather than verified authorization.
NIST CSF v2.0, PR.AC-4 calls for access permissions and authorizations to be managed, incorporating the principles of least privilege and separation of duties. Running both untrusted input processing and privileged operations in the same agent context violates separation of duties.
Lessons and Action Items for Your Team
Map your agent interaction graph. Draw out every place where one automated system can invoke another. Include CI/CD pipelines, chatbots, monitoring systems, and any AI agents. For each connection, document what authority is being delegated and what input validation occurs.
Implement explicit authorization for every agent-to-agent call. Don't rely on the calling agent's identity alone. Each receiving agent must verify that the specific operation is authorized for the specific context. If your monitoring agent can trigger a deployment pipeline, the pipeline must verify that the request is authorized, not just that it came from the monitoring agent.
Separate parsing from execution. Build your agents in layers. The layer that processes untrusted input (user commands, webhook payloads, API responses) should never have direct authority to execute privileged operations. It should pass validated, structured data to a separate execution layer that performs its own authorization check.
Treat agent output as untrusted input. When Agent B receives data from Agent A, validate it as if it came from an external user. Don't assume that because Agent A is "trusted," its output is safe to process without validation. This breaks transitive authority chains.
Log cross-agent invocations with full context. Your logs should show not just that Agent B executed an operation, but that it did so because Agent A invoked it, and Agent A was processing input from source X. Without this context, you can't investigate how an attacker moved laterally through your agent network.
Review natural language command interfaces. If you're using '@mentions' or chat commands to trigger automation, add explicit authorization checks. Verify the user's identity and permissions before executing, even if the syntax is correct. Consider requiring additional confirmation for privileged operations.
Test for privilege escalation through agent chaining. In your security testing, try to find paths where a low-privilege operation in one agent can trigger a high-privilege operation in another. This is the AI equivalent of SSRF or command injection, and it requires similar testing approaches.
The Google ADK vulnerability wasn't a sophisticated exploit. It was a reminder that when you connect AI agents together, you're building a distributed system with all the same security requirements as any other distributed system. Authorization boundaries don't disappear just because the components speak in natural language. AI security best practices
