GoogleのAgent Development KitでゼロトラストなAIエージェントを構築するBuild zero-trust AI agents with Google's Agent Development Kit

Google's Developers blog has published guidance on securing agents built with its Agent Development Kit (ADK), arguing that autonomous systems capable of changing production state require far stronger protections than the instructions written into a system prompt. The topic matters because agents are increasingly connected to real tools — databases, APIs, internal services and transactional systems — where a single manipulated instruction can trigger irreversible actions rather than merely a poor response.

The central premise is that "soft" system prompts, the natural-language rules developers write to steer a model's behavior, are not a dependable security boundary. A directive such as "never delete records" or "only act on authorized requests" can be overridden by carefully crafted input, because a language model tends to treat trusted instructions and untrusted data as the same stream of tokens. Once an agent can mutate production state, that ambiguity becomes an attack surface rather than a quality-of-output concern.

Prompt injection is the specific threat the guidance foregrounds. In a direct injection, a malicious user embeds instructions that hijack the agent's intended task. In an indirect injection, the hostile payload is hidden inside content the agent retrieves — a web page, an email, a document or a tool response — so that reading data effectively becomes executing commands. For an agent with permissions to write to systems or call functions, this is the difference between a chatbot saying the wrong thing and an automated process taking a harmful action.

To counter this, the guide advocates a zero-trust architecture. Zero-trust is a security model borrowed from network engineering, built on the principle of "never trust, always verify": no request, identity or component is trusted implicitly, and every action is authenticated and authorized on its own merits. Applied to agents, this means the model's output is not treated as an inherently trustworthy command. Instead, actions that alter production state are gated by controls that sit outside the model and cannot be talked out of enforcing their rules. The source excerpt indicates the recommendations extend to hardware-level enforcement, which appears to point toward isolating execution and grounding trust in components that a prompt cannot influence, though the full technical specifics sit within Google's own documentation.

In practice, this class of architecture typically combines several layers. Least-privilege access limits each agent and tool to the narrowest set of permissions needed. Sandboxing and isolation contain code execution so a compromised step cannot reach beyond its boundary. Deterministic guardrails and validation check proposed actions against explicit policy before anything is committed, and sensitive operations can require human approval or a separate authorization step. The recurring theme is that safety is enforced by the surrounding system, not requested politely from the model.

As background, ADK is Google's open-source framework for building, orchestrating and deploying AI agents, introduced as part of the company's broader agent tooling and designed to work with Gemini models while remaining model-agnostic. It fits alongside Google's wider agent stack, including Vertex AI and its agent runtime services, and competes with frameworks such as LangChain and LangGraph, CrewAI, Microsoft's AutoGen and OpenAI's agent tooling. The industry has also converged on shared plumbing like the Model Context Protocol for connecting agents to external tools and data, which is useful for interoperability but also widens the pathways through which untrusted content can reach a model.

The security emphasis reflects a broader shift as agentic systems move from demos into production. Prompt injection is listed among the top risks in the OWASP guidance for large language model applications, and researchers have repeatedly shown that instruction-following behavior is difficult to fully constrain through prompting alone. Framing agent security as an architectural problem rather than a prompting problem aligns with that consensus, and is likely to become a prerequisite for teams granting agents real authority over live systems. For developers evaluating ADK, the takeaway is that autonomy and the ability to mutate production state raise the stakes considerably, and that treating the model as an untrusted component — while enforcing permissions, isolation and validation externally — is presented as the more defensible foundation.