The Problem With Securing Agents the Old Way
Traditional security tools guard the perimeter. WAFs inspect HTTP traffic. API gateways enforce rate limits. Neither one knows what a reasoning trace is, let alone how to spot a prompt injection buried inside a tool response.
AI agents are different. They call LLMs in loops. They invoke external tools via the Model Context Protocol (MCP). They read untrusted content, make decisions, and take real actions—send emails, query databases, execute code. When something malicious enters that loop, the damage isn’t a bad response. It’s a bad action.
According to Cisco’s AI Readiness Index 2025, 83% of companies plan to develop or deploy AI agents. Most of their security stacks weren’t built for this. That gap is widening fast.
Three Layers of the Agentic Stack (And Why Each One Matters)
Where you need protection depends on where your code lives. There are three distinct levels, each with its own exposure profile.
Level 1: Classic Chatbots
Simple prompt-in, response-out. The attack surface is the input boundary—catch injection before it reaches the model. Manageable, well-understood.
Level 2: Agentic Frameworks
LangChain, LangGraph, CrewAI, AutoGen, Strands, Google ADK, OpenAI Agents SDK—these orchestrate multi-step reasoning, manage state, and coordinate tool use. The catch: LLM and tool calls happen inside the framework. You’re not writing client.chat.completions.create() yourself. The framework is, often in a loop, across multiple threads.
Securing those calls without forking framework code is genuinely hard. And it matters, because the agent is making real decisions on your behalf.
Level 3: PaaS Agent Runtimes
AWS Bedrock AgentCore, Google Vertex AI Agent Engine, Azure AI Foundry. You’re not just running code—you’re deploying an agent into a managed container someone else controls. Protection has to travel with the agent into that environment and cover every LLM call and MCP invocation it makes there.
The MCP Attack Surface Nobody’s Talking About Enough
MCP is the open standard that lets LLMs call tools, access resources, and retrieve prompts from external servers. Adoption has exploded—thousands of public MCP servers now exist. Each one is a potential attack vector.
The threat categories are specific and nasty:
- Tool poisoning — Malicious instructions hidden in tool descriptions or metadata
- Indirect prompt injection — Harmful commands embedded in content the agent reads during normal operation
- Data exfiltration — Sensitive information leaked through tool responses
- Rug pull attacks — Legitimate tools updated with malicious code after deployment
None of these show up in standard API logs. None of them trigger a WAF rule. They only become visible when you’re inspecting LLM context—prompts, tool arguments, responses, and the feedback loops between them.
What Cisco AI Defense Actually Does
Cisco AI Defense covers the full AI lifecycle: discovery (inventory your AI assets), detection (find vulnerabilities and jailbreak susceptibility), and protection (runtime guardrails updated with current threat intelligence).
The Inspection API analyzes prompts and responses for injection attempts, sensitive data exposure, toxic content, and policy violations. Solid capability—but instrumenting every LLM call and MCP interaction across a real agentic stack means touching a lot of code.
The new Agent Runtime Protection in the Cisco AI Defense Python SDK solves that instrumentation problem directly.
One Line of Code. Every Call Covered.
Here’s the core idea: agentsec.protect() uses dynamic code rewrites to patch LLM and MCP client libraries at runtime. Every call routes through AI Defense inspection automatically—no changes to your application logic required.
Install the SDK:
pip install cisco-aidefense-sdk
Then add one line before your imports:
from aidefense.runtime import agentsec
agentsec.protect(config="agentsec.yaml")
That’s it. Everything downstream is now inspected—requests before they reach the provider, responses before they reach your application, and MCP interactions at both ends.
How the Inspection Works
Request inspection runs before any LLM or MCP call. Prompt injection, sensitive data, and policy violations are caught before the call proceeds.
Response inspection runs after the provider returns. Data leakage, harmful content, and compliance violations are caught before reaching your application.
MCP protection covers all three interaction types:
call_tool— arguments and resultsget_prompt— templates from external serversread_resource— data from external sources
Simple Chat Completion (OpenAI)
from aidefense.runtime import agentsec
agentsec.protect(config="agentsec.yaml")
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-5.5",
messages=[{"role": "user", "content": "Hello!"}]
)
The agentsec.protect() call patches the OpenAI client before it’s imported. Every completion is inspected transparently.
Agentic Framework (LangChain)
from aidefense.runtime import agentsec
agentsec.protect(config="agentsec.yaml")
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langchain_core.messages import HumanMessage, ToolMessage
@tool
def fetch_url(url: str) -> str:
"""Fetch a URL via an MCP server (inspected by agentsec)."""
pass
llm = ChatOpenAI(model="gpt-5.5")
llm_with_tools = llm.bind_tools([fetch_url])
The framework handles orchestration. Agentsec handles inspection. They don’t need to know about each other—that’s the point.
PaaS Runtime (AWS Bedrock AgentCore)
from aidefense.runtime import agentsec
agentsec.protect(config="agentsec.yaml")
from bedrock_agentcore import BedrockAgentCoreApp
from shared import get_agent
app = BedrockAgentCoreApp()
@app.entrypoint
def invoke(payload: dict):
user_message = payload.get("prompt", "Hello!")
result = get_agent(user_message)
return {"result": str(result)}
Protection ships with the agent into the managed runtime. No special configuration for the PaaS environment required.
Provider Coverage and Inspection Modes
Agentsec rewrites calls for OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI, Google GenAI, Cohere, Mistral AI, Azure AI Inference, and LiteLLM. Switch providers without touching your security integration.
Two modes of operation:
- API Mode — Inspects via the AI Defense API, then calls the provider directly. Exposes three settings:
monitor(log only),enforce(block), andoff. - Gateway Mode — Routes all traffic through Cisco AI Defense Gateway for centralized enforcement. The gateway does the enforcing; the SDK setting is simply on or off.
Handling Blocked Requests Gracefully
When Agentsec blocks a request in enforce mode, it raises a SecurityPolicyError. Catch it, log it, respond appropriately:
from aidefense.runtime.agentsec import SecurityPolicyError
try:
response = client.chat.completions.create(...)
except SecurityPolicyError as e:
print(f"Blocked: {e.decision.action}")
print(f"Reasons: {e.decision.reasons}")
Clean, explicit, and easy to wire into your existing error handling.
Getting Started
The SDK is open source. Examples for seven agent frameworks and deployment guides for AWS Bedrock AgentCore, GCP Vertex AI Agent Engine, and Azure AI Foundry are available at:
github.com/cisco-ai-defense/ai-defense-python-sdk
pip install cisco-aidefense-sdk
# or
poetry add cisco-aidefense-sdk
The Takeaway
Agents are in production. The attack surfaces—LLM calls, MCP tools, external content, multi-step reasoning loops—are real and actively exploited. One line of code won’t solve every security problem, but it will close the gap that most enterprise stacks currently leave wide open.
The best security is the kind developers actually ship. agentsec.protect() is designed to be exactly that.
Comments (0) No comments yet
Want to join this discussion? Login or Register.
No comments yet. Be the first to share your thoughts!