Agents are powerful because they do more than answer questions. They call tools, retrieve context, and act across multiple steps. That is what makes frameworks like Google’s Agent Development Kit (ADK) so useful, and it is also what changes the security problem. Cisco AI Defense provides runtime protection for AI agents. With this integration, AI Defense now plugs into Google’s ADK and carries the same runtime controls from local development to Agent Runtime on Gemini Enterprise Agent Platform.
Google’s ADK is used to build tool-using agents. Agent Runtime is the managed runtime to deploy them. This integration makes it easy to keep Cisco AI Defense runtime protection attached in both places.
The real risk is not just that an agent produces a bad answer. The bigger issue is that untrusted prompt content can influence tool behavior, and tool output can send sensitive data back into the model. Once agents start interacting with external systems, the security question shifts from “What did the model say?” to “What did the agent do, and what data crossed runtime boundaries?” That is where runtime protection matters.
Whether an agent runs locally or on Gemini Enterprise Agent Platform, teams need a way to inspect and enforce policy across the full execution path—not just at the first model call. They need visibility into what crosses those boundaries and a mechanism to decide whether a run should continue, be observed, or be stopped.
The Cisco AI Defense integration for Google’s ADK is designed to add runtime security controls without forcing developers to rebuild their application around a separate security workflow. Instead of creating a parallel control plane, it plugs into the ADK lifecycle developers are already using.
Start with two lines of code
For a local ADK agent, the fastest path is intentionally small:
from aidefense_google_adk import defend agent = defend(agent, mode="enforce")
That is the simplest agent-level integration. You keep the ADK agent structure you already have and attach policy enforcement directly to it.
Once the agent is protected, you can use the standard ADK deployment flow to run it on Agent Runtime:
app = agent_engines.AdkApp(agent=agent)
remote_agent = client.agent_engines.create(
agent=app,
config={
“requirements”: [“google-cloud-aiplatform[agent_engines,adk]>=1.112”], “staging_bucket”: “gs://YOUR-STAGING-BUCKET”,
},
)
The important detail is that protection is attached before deployment. The same protected ADK agent can move from local development into Agent Runtime without requiring a different security pattern.
Google ADK is a strong seam for runtime protection because it already defines clear lifecycle boundaries around model and tool execution. Those boundaries create natural inspection points:
These are the moments where agent behavior changes. Untrusted prompt content can shape a tool request. Tool output can leak sensitive data back into the model. Runtime protection is most effective when it sits at those transitions instead of being scattered across prompts and custom wrappers.
There are two main integration patterns depending on whether you want shared app-wide controls or agent-specific protection.
Use the plugin path when you want shared protection across the ADK app runtime.
plugin = defend(mode="enforce") app = App(name="my_app", root_agent=agent, plugins=[plugin])
Use callbacks when you want protection attached directly to a specific agent.
from aidefense_google_adk import make_aidefense_callbackscbs = make_aidefense_callbacks(mode="enforce") cbs.apply_to(agent)
Use the plugin for app-wide controls; use callbacks when you want agent-specific protection.
This distinction usually matters most to both developers and platform teams.
For example, a sensitive data request might be observed in monitor mode and then blocked in enforce mode at tool_response, because that is the point where the violation becomes visible. That difference matters. Monitor helps teams understand risk in a live workflow. Enforce turns the same decision point into a runtime control.
This is what makes enforcement auditable for developers and security teams. Decision: block
In simple terms, this means the request was allowed to proceed until the tool returned sensitive data, and the runtime blocked the flow at the point where the violation became visible. For developers, this is especially useful because it explains not just that a run was stopped, but where the unsafe behavior surfaced.
One of the most practical benefits of this integration is that the same ADK application model works across two environments:
That does not mean every runtime surface looks identical all the time. Hosted evidence should still be treated as request-correlated data tied to a specific invocation, with logs used as supporting context. But the same policy model follows the agent from local development into the hosted runtime. Teams do not need one security pattern for local testing and another for deployment. The same runtime controls travel with the agent.
This integration uses the extension points that Google’s ADK already provides instead of asking developers to work around the framework. That matters for two reasons:
For teams evaluating platform fit, that can matter as much as the policy outcome itself. Security should feel like part of the framework lifecycle—not a parallel workflow bolted onto the side.
Google’s ADK and Gemini Enterprise Agent Platform make it easier to move from prototype to hosted agent runtime quickly. That is good for development speed, but it also means agent behavior can reach real systems faster. If runtime protection is too disruptive, teams will delay it. If it fits naturally into the ADK model, lets teams start in monitor mode, and provides a clear path to enforce, it becomes much easier to keep security turned on as the agent matures.
The value of this integration comes down to a simple combination:
That combination turns agent protection from an abstract requirement into something developers can evaluate quickly and adopt with confidence.
If you want to run it yourself end-to-end, use the official Google’s ADK path and compare local vs hosted behavior with AI Defense enabled.
Google’s ADK + Agent Runtime quickstart
Local Google’s ADK demo
Hosted Agent Runtime demo
Google’s ADK is the framework for building tool-using agents and Agent Runtime is the managed runtime to deploy them. Cisco AI Defense Runtime Protection is designed to follow that same path, so the same runtime policy enforcement applies in local development and in hosted execution on Agent Runtime.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
