Between June and August 2026, Encrypt AI scanned more than 268,000 tools across 25,000 Model Context Protocol servers. It found over 143,000 vulnerabilities, affecting 73% of the servers it looked at. Most of these servers sit behind agents whose owners believe that they are covered because guardrails are switched on.
Amazon Bedrock Guardrails have become a cornerstone of generative AI safety on AWS, offering content filtering, PII redaction, denied topics, and automated reasoning checks. They are a powerful tool. The question is what happens when you treat them as the whole strategy? The OWASP Top 10 for Agentic Applications (2026) catalogues the gaps that such assumptions leaves.
1. What Bedrock Guardrails do
Guardrails are model-agnostic safeguards, applying policy before the model sees a prompt and after it generates a response. Through the ApplyGuardrail API they work across models hosted in Bedrock, self-hosted models, and third-party models outside Bedrock entirely. They are stationed at the front door of the AI, checking everything that goes in and out.
The filters that can be configured include:
Content Filters: detection of certain predefined content categories: hate, Insults, Sexual, Violence, Misconduct and Prompt Attack.
Prompt Attack: a category within content filters, this filter detects and filter prompt attacks including jailbreaks, prompt injections, and prompt leakages (Amazon Standard tier only)
Denied Topics: block subjects you define as out of scope.
Word Filters: configure and block specific words, phrases, profanity, competitor names and many more.
Sensitive Information Filter: detection and redaction of PII.
Contextual Grounding Check: detection and filtering of hallucinations in model responses.
Automated Reasoning Checks: uses formal verification techniques (method rooted in mathematical logic) to validate the accuracy and policy compliance of outputs from generative AI models. AWS claims 99% accuracy in detecting correct response.
2. Structural Blind Spots
AWS documents these itself. In “Extend Amazon Bedrock Guardrails to Tool Interactions Using the Strands Agents SDK” (AWS Security Blog, Stephan Traub, 27 August 2026), that model-level guardrails alone leave you exposed in four ways.
2.1 Tool Parameters passes through unchecked
Tool parameters are not automatically checked before a tool runs. If they contain private data (PII) or policy violations, the tool will execute with that bad data.
See an example of Tool parameters below:
{
"tool": "web-search (external)",
"query": "refinance options for Alice Smith, [email protected],SSN 402-11-9821, credit score 611"
}Two checks ran and both passed: once on the way in, once on the way out. Neither checks looked at the search query the model wrote in the middle: the one carrying a customer’s email and SSN to a third party. That query is the moment the data leaves your control. It is the only moment nobody is watching.
2.2 Unvalidated External Data
Agents consume data from tool responses, MCP (Model Context Protocol) server output and API results. Without boundary validation, untrusted content can corrupt the agent's behaviour before final guardrails evaluates it.
2.3 Misleading information can affect reasoning
An agent that retrieves inaccurate or misleading content from an external source might treat it as authoritative, producing skewed recommendations in lending, healthcare or legal advice.
2.4 Multi-Agent systems spread bad data downstream
A misconfigured upstream agent can hand policy-violating content to a downstream one. Model level guardrails sitting at each agent's model boundary do not inspect what flows between agents at the tool layer.
3. How AWS closes the gap
This is not a story of AWS ignoring the problem. It is a story of AWS is making deliberate efforts to address it.
In 16th June 2026 AWS announced a new InvokeGuardRailChecks API giving the flexibility to invoke safeguards for agentic loop. The API operates in a detect only mode returning numeric scores for each safeguard. The safeguard supported are:
Content filters: Harmful content across categories: hate, violence, sexual, insults, and misconduct.
Prompt attack detection: Jailbreaks, prompt injection, and prompt leakage attempts
Sensitive Information filter: PII entities including email, phone, SSN, credit card numbers (31 entity types)
An AWS August security post builds three validation checkpoints, built on Strands Agent SDK lifecycle hooks, each calling the ApplyGuardrail API.
Inbound Data Validation - Implement BeforeInvocationEvent hook to validates inbound data before it reaches the model.
Tool Interaction Supervision - BeforeToolCallEvent hook validates tool parameters before execution. (Closes gap in section 2.1 Tool parameters passes through unchecked)
Outbound Data Validation - An AfterToolCallEvent validates tool outputs such as an unwanted content that violates policies before it returns to user or passes them to downstream systems such as: AI systems, databases, 3rd party apps.
Separately, Amazon Bedrock AgentCore Policy now supports Bedrock Guardrails, evaluating inputs to every gateway target (tools, agent and models) and outputs of every authorised agent action at the gateway perimeter in real time. Results are evaluated in policy outside the agent's own code, ensuring consistent enforcement holds regardless of how autonomous the agent is.
Are AWS checks enough?
With the right configuration, AWS checks covers tool boundary by validating user input, tool parameters, tool output, final response and the use of the right Guardrail API. Another layer required is a gateway that applies policy outside the agent’s code, a CI (Continuous Integration) check that fails a build with unregistered hooks.
However as a security strategy, it is not close. None of checks tells you: Who owns AI risk? Which agents exist in your estate? Who or what can reach your AI systems and data? Who is monitoring for attacks in real time? What happens at 2am when there is a compromise?
Strategy Component
1. Governance & Risk Management
What it is: This is the foundational layer of any AI security strategy. It establishes the rules, structures, and culture for identifying, assessing, and managing AI related risks across the entire organisation. As NIST's AI RMF explains, the GOVERN function "cultivates and implements a culture of risk management" and is "a cross-cutting function that is infused throughout AI risk management".
Why it matters: Without governance, technical controls operate in a vacuum. Executive leadership must own AI risk, not delegate it solely to engineering. The NCSC CAF's Objective A reinforces this, requiring "appropriate organisational structures, policies, processes and procedures… to understand, assess and systematically" manage security risks. The CAF breaks this into governance (ensuring cyber risk is owned at the right levels) and risk management (identifying and mitigating threats before they impact operations).
Key activities:
Executive ownership of AI risk at the board level
AI asset inventory tracking every model, training dataset, pipeline, and agent across the lifecycle
Risk assessment calibrated to the specific AI use case (not one size fits all)
Supply chain scrutiny for foundation models, training data, and third-party AI services
Threat modeling that explicitly considers AI-specific attack vectors (prompt injection, data poisoning, model extraction)
Shadow AI discovery — identifying unsanctioned AI tools employees are using
Conclusion
The problem was never that AWS built something weak. Guardrails do what they claim, and the tool-boundary checkpoints work when they are in place.
The problem is that a control which depends on a developer remembering to register a hook is not really a control. It is an assumption. Nobody enforces it, and nobody checks. Most AI security failures will not be clever. There will be a check nobody switched on, an agent inheriting human permissions, and expanding the attack surface in ways that IAM tools were not designed to handle. None of this requires a sophisticated attacker.
Guardrails inspect what goes into a model and what comes out. Everything else the tool calls, the identities, the data moving between agents, the decisions nobody was watching is yours to cover. Start with the inventory. You cannot protect what you have not listed.
If you're responsible for AI agents in your organisation and you are not certain on what is actually protecting them, that is what I can help with. Let's discuss your specific use case and build a program that aligns with your threat model, regulatory requirements, and organisational maturity.
Email: [email protected].