用 Google 的 Agent Development Kit 构建零信任 AI 智能体

Core Highlights

On its official developer blog, Google open-sourced a zero-trust customer-service and returns agent example built on the Agent Development Kit, or ADK, and the Gemini model. The project's central purpose is to demonstrate how an agent can call tools and read or write databases while still blocking attacks such as prompt injection, which remain one of the most common ways these systems get hijacked in production. What makes this example notable is that it turns the enterprise fear of "an agent tricked by one sentence into scrambling the data" into a demonstrable, reusable engineering template, rather than leaving it as an abstract principle buried in a research paper that nobody knows how to implement. For teams that have been nervous about letting an LLM touch a real database, the sample is a concrete answer to the question of how to do it without disaster, and it shows the defensive pattern in runnable code rather than in hand-waving.

What It Does or What Happened

Crucially, this project does not try to put security inside the system prompt. Instead it places three hard defensive layers entirely outside the model context. The first layer is hardware-backed cryptographic signing: every database write carries a signature that cannot be forged, so any action is non-repudiable and can be audited across its full history. The second layer uses a gVisor sandbox to isolate dynamically generated code executed by the agent, so that any attempt to overstep privilege is contained inside the container and never touches the host. The third layer is a deterministic semantic gateway that validates business logic, checking rules such as whether a given refund is actually permitted before anything is committed to the database. The three layers do not depend on one another, so bypassing any single layer does not compromise the rest of the system, and the failure of one defense still leaves the others standing as independent barriers that an attacker must defeat in turn.

Technical Details

The key insight is that the system prompt is only a soft constraint. No matter how firmly you tell the model "do not modify the database," an attacker can slip past that instruction with a single injected sentence, because to the model a prompt is merely a suggestion, not a guarantee it must honor. The real security boundary must be enforced by deterministic mechanisms that live outside the model. The model is only responsible for understanding and generating text, never for making the final authorization decision, which is handed to external code that the model cannot override no matter what the conversation contains or how cleverly the injection is phrased. Treating the prompt as a wall is the single most common and most dangerous mistake teams make when they first ship an agent.

Versus Competitors

Many open-source agent examples hand permission decisions directly to the model's own judgment. The difference in Google's design is that it fully decouples "whether execution is allowed" from "whether the model wants to execute," so authorization no longer depends on the model's obedience or good behavior. Even if the model is compromised mid-conversation by an injected instruction, the dangerous operation is still blocked by the outside gateway that sits between the model and the data. That separation is what turns a polite request into an enforced rule, and it is the reason the example is worth studying even by teams that will never use ADK or Gemini specifically.

Industry Impact or Use Cases

For enterprises, this means an agent can be wired into sensitive flows such as orders and refunds without fear that a single crafted message will trick it into corrupting the data. It offers a reusable blueprint for production-grade deployment where trust cannot be assumed, and it also lowers the barrier to compliance auditing because every write is signed and every decision is checked by a rule the model cannot quietly rewrite. Companies that adopt this pattern can move faster on agent projects while keeping their risk officers on board, which is often the real bottleneck that stops promising prototypes from ever reaching a customer-facing service. The pattern also gives security teams a concrete vocabulary to demand from vendors, shifting the conversation from vague trust to verifiable gates that anyone can inspect. It is a small shift in language that changes how the whole project is secured.