Protecting Agents with Cisco AI Defense and Google Agent Development Kit

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 security problem changes with agents

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.

Cisco AI Defense adds security without disrupting the developer flow

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.

Deploy the same protected agent to Agent Runtime

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.

Why ADK is the right integration point

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:

Before a model call
After a model response
Before a tool call
After a tool response

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.

Two ways to attach protection in ADK

There are two main integration patterns depending on whether you want shared app-wide controls or agent-specific protection.

1) App-level plugin

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])

2) Agent-level callbacks

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.

Monitor vs. enforce

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.

What a block decision looks like

This is what makes enforcement auditable for developers and security teams. Decision: block

Stage: tool_response
Classification: PRIVACY_VIOLATION
Rule: PII

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.

From local ADK to Agent Runtime on Gemini Enterprise Agent Platform

One of the most practical benefits of this integration is that the same ADK application model works across two environments:

Local ADK runs for fast development and iteration
Hosted Agent Runtime runs for managed deployment

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.

Built on the official Google’s ADK path

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:

It keeps the application readable.
It makes the security layer easier to adopt in normal ADK workflows.

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.

Why this integration matters

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.

Final thoughts

The value of this integration comes down to a simple combination:

A small ADK integration surface
Live proof in both local ADK and hosted Agent Runtime
Clear runtime decisions in monitor and enforce modes
Deployment flexibility: teams can route calls either directly to Cisco AI Defense or through Google Cloud’s Agent Gateway, depending on how they want to operationalize enforcement

That combination turns agent protection from an abstract requirement into something developers can evaluate quickly and adopt with confidence.

Get started with Cisco AI Defense on Google ADK and Vertex Agent Engine

The fastest way to see the value is to run the same agent workflow in Monitor and Enforce and compare what AI Defense does at runtime: what it flags, what it blocks, and the “blocked and why” decision trace.
Start here (live demo runner):
- https://dev.aidefense.cisco.com/demo-runner?mode=vertex
If you want to run it yourself end-to-end, use the official Google ADK path and compare local vs hosted behavior with AI Defense enabled:
- Google ADK + Vertex quickstart
- Local Google ADK demo
- Hosted Vertex AI Agent Engine demo
To get access to an AI Defense evaluation (including API key), request a demo here: cs.co/aidefensedemo

Get started with Cisco AI Defense on Google’s ADK and Agent Runtime

The fastest way to see the value is to run the same agent workflow in Monitor and Enforce and compare what AI Defense does at runtime: what it flags, what it blocks, and the “blocked and why” decision trace.
Start here (live demo runner):
- https://dev.aidefense.cisco.com/demo-runner?mode=vertex
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
- GitHub Repo: https://github.com/cisco-ai-defense/ai-defense-google-adk
To get access to an AI Defense evaluation (including API key), request a demo here: https://www.cisco.com/c/en/us/products/security/ai-defense/request-demo.html?linkclickid=primary

Why this matters

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.