Time and again in production agentic AI deployments I see companies spending months hardening their LLM prompts, but almost no time thinking about what happens after the model decides to call a tool.
Traditional application security was built around a predictable actor: a user at a device, taking a defined action, but agentic AI has dissolved that predictability. The actor is now reasoning logic that improvises its own next step, selecting tools dynamically and feeding results straight back into the model with no human seeing the intermediate data.
And this shift is creating risks that the request/response world never had. Without explicit rules, an agent can call any tool the gateway exposes. The right tool called by the wrong user, or with parameters outside an allowed range, looks identical to a legitimate call unless something evaluates identity and arguments together. A crafted instruction smuggled inside a tool response can override the agent’s intent entirely. And according to the Netskope AI Index, the average enterprise already sees users accessing 60 AI apps a week.
Two things close that gap: A policy engine decides whether an agent is even allowed to call a given tool with those exact parameters. Then, guardrails inspect what’s actually inside the prompt or the tool response, checking for intent and meaning, not just permission. Production agentic AI needs both checks in place.
Together, AWS and Netskope have both sides covered.
What is Policy in AgentCore?
AWS AgentCore Gateway is a managed MCP tool server that sits between agents and the tools they invoke. It handles inbound authorization, outbound credential injection, and a registered list of permitted tools. What changes the security posture is Policy in Amazon Bedrock AgentCore, the gateway’s policy engine, which became generally available in March 2026.
A policy engine is a set of Cedar (AWS’s open source authorization policy language) policies attached to a gateway. It intercepts every agent-to-tool request and evaluates it before the call reaches the target, outside the agent’s code. Two design choices make it a hard boundary. Evaluation is default-deny, and an explicit forbid always beats a permit. Each policy names a principal, an action, and a resource. Its conditions can also read the caller’s identity and the tool’s input arguments together, binding authorization to who is acting and what they’re asking for.
The policy engine answers one question, and it answers it deterministically. Is this action permitted? What it doesn’t do, by design, is reason about the meaning of the content. It can confirm an agent may call summarise_document with a given document_id, but not whether the document contains a jailbreak instruction, or whether the summary reproduces copyrighted text. Cedar evaluates structure and claims, not semantics. That’s fine, as long as something else covers semantics.
What does Netskope One AI Guardrails protect?
Netskope One AI Guardrails is a runtime security layer that sits between the user or agent and the LLM, inspecting every prompt and response in real time. Where pattern matching fails the moment content is rephrased, AI Guardrails evaluates intent and meaning instead, which is exactly what agentic threats exploit.
Traffic flows through it via Netskope One Next Gen SWG (north-south) or Netskope One AI Gateway (east-west), where AI guardrails, DLP, and threat protection inspect every prompt and response in parallel, correlated under a single incident ID. Netskope One AI Guardrails specifically covers:
- Prompt injection and jailbreak defence. Multi-stage intent analysis in real time, across 29 languages, including crescendo attacks.
- Semantic inspection, not signatures. Catches paraphrased or split payloads by intent, not keyword matching.
- Content moderation. Controls harmful content, from hate speech to weapons, against the organization’s risk tolerance.
- IP and copyright protection. Blocks patented or copyrighted material before it becomes legal exposure.
- Agent- and tool-aware inspection. Inspects agent-to-tool data, not just the user prompt. to catch indirect injection.
- Framework-mapped detections. Every finding maps to MITRE ATLAS and the OWASP Top 10 for LLMs, for a standardized, auditable record.
Netskope’s AI Guardrails answers the nuanced question: Is this content safe? It reasons about meaning and intent in both directions, but it doesn’t decide whether a given agent, acting for a given user, had the right to call that tool with those parameters in the first place. That’s the gap AWS’ policy engine closes.
The case for using both
These two systems govern different dimensions of the same agentic action. The policy engine is the deterministic gate on actions, and AI guardrails are the semantic gate on content and intent. An action is only truly safe when both have cleared it, as the table shows.
| Layer | Threat | Protects | How |
|---|---|---|---|
| Agent identity | Unauthenticated agent reaching tools | AWS AgentCore Gateway | Inbound OAuth/JWT (or IAM SigV4) authorization |
| Tool scope | Agent invoking tools it should never call | AWS AgentCore Gateway | Policy engine deny rules over the registered target list |
| Conditional access | Right tool, wrong user, wrong context | AWS AgentCore Gateway | Cedar identity- and parameter-aware authorization |
| Credential exposure | Agent holding downstream secrets | AWS AgentCore Gateway | Gateway outbound credential injection |
| Prompt injection / jailbreak | Crafted input overriding agent instructions | Netskope One AI Guardrails | Multi-stage intent analysis of the prompt |
| Harmful / unsafe content | Toxic, illegal, or policy-violating generation | Netskope One AI Guardrails | Content moderation across 29 languages |
| IP / copyright leakage | Patented or copyrighted data in responses | Netskope One AI Guardrails | Response inspection and blocking |
| Indirect / tool-borne injection | Malicious payload inside a tool result | Netskope One AI Guardrails | Inspects agent-to-tool data, not just the user prompt |
| Sensitive data movement | PII, secrets, or source code in calls | Both | Cedar parameter rules + Netskope One AI Guardrails / DLP semantic inspection |
| Audit & traceability | Forensic record of agent behaviour | Both | CloudTrail (who/when/which tool) + Netskope (intent/what was in it) |
Cedar parameter rules can stop a value from ever being passed. AI Guardrails catches sensitive content that rules alone would miss, because it was rephrased, embedded, or returned unexpectedly by a tool. On the audit side, AWS CloudTrail tells you a tool was called and what the policy decided. Netskope tells you what the intent was and what data moved. Combined, they cover ground that neither view reaches alone.
What this means in practice
Neither system is a silver bullet. Cedar policies need to be written and maintained, and if the policy library is out of date, the gate is open; AI Guardrails only inspects what flows through it, so it has to sit in the traffic path.
What the combination gives you is a principled architecture. You’re not relying on the agent to police itself, and you’re not relying on a single control that only understands half the problem. The policy engine governs decisions and AI Guardrails governs meaning, so production-grade agentic AI needs both on every call.
Securing agentic AI with Netskope
Netskope One AI Guardrails is part of the Netskope One AI Security suite, covering the full lifecycle of AI risk, from discovering unmanaged AI usage to protecting the data and prompts flowing through every AI interaction.
The AWS AgentCore integration extends that coverage to the tool boundary, where agent decisions become real-world actions. Together, the two platforms cover the full decision-to-execution surface agentic AI creates.
See how Netskope One AI Guardrails fits into a full agentic AI security architecture. Explore Netskope One AI Security.
