How to protect Amazon Bedrock AI agents: two AWS WAF patterns

AWS has published two architecture patterns for protecting AI agents in Amazon Bedrock with AWS WAF, both tested with SigV4 authentication and OAuth via Amazon Cognito JWT.

Why AgentCore Runtime needs WAF protection

AgentCore Runtime, the Amazon Bedrock component for running AI agents in production, has no built-in web-application-level filtering by default. Without additional architecture, an attacker can hit the agent with injections, DDoS or request forgery by calling the service directly.

AWS WAF (Web Application Firewall) can block known attack vectors, rate-limit requests and apply managed rule groups before a request reaches the agent. Both patterns use an internet-facing Application Load Balancer (ALB) with AWS WAF attached, and route traffic through a VPC Interface Endpoint to AgentCore Runtime.

Key parameters of both solutions:

• The ALB is open to the internet, and AWS WAF inspects every incoming request
• Traffic goes through a VPC Interface Endpoint to AgentCore Runtime
• A resource policy prohibits bypassing WAF directly
• SigV4 and OAuth (Amazon Cognito JWT) authentication are supported
• Both patterns were tested in end-to-end scenarios

Pattern 1 vs. Pattern 2: what's the difference

Pattern 1 adds an AWS Lambda function as a proxy between the ALB and the VPC Endpoint. The function receives the request after WAF filtering, can transform it (add headers, normalize paths, modify the body), and then passes it to AgentCore through the VPC Endpoint. This gives maximum control over traffic, which is especially useful if you need transformation logic or extra validation before the agent. The trade-off is added latency and the cost of Lambda invocations.

Pattern 2 removes the Lambda hop entirely: the ALB calls the IP addresses of the ENI (Elastic Network Interface) of the VPC Interface Endpoint directly. This is a more straightforward design with lower latency and no Lambda overhead. It fits when request transformation is not needed and minimal latency is the priority while keeping WAF protection.

"Both patterns were tested end-to-end with SigV4 and OAuth (Amazon Cognito JWT) authentication,"

AWS notes on its Machine Learning blog.

How to close the backdoor with a resource policy

The most critical part of both patterns is correctly configuring the AgentCore Runtime resource policy. Without it, WAF protection is pointless: an attacker can discover the public AgentCore endpoint and call it directly, bypassing the ALB and WAF entirely.

The fix is the `aws:SourceVpce` condition in the resource policy. It allows calls to AgentCore only through a specific VPC Interface Endpoint, which ensures all traffic passes through the ALB and AWS WAF. The direct backdoor is closed at the IAM policy level.

This approach implements the Defence in Depth principle: WAF is the first line of filtering, and the resource policy is the second, preventing the first from being bypassed.

What this means

The AWS guide gives developers of AI agents on Bedrock ready-made, tested patterns instead of having to invent their own protection schemes. The choice between them is simple: if you need request transformation, use Pattern 1 with Lambda; if speed and simplicity matter more, use Pattern 2 with a direct route to the ENI.

Frequently asked questions

Which authentication methods do both patterns support?

Both patterns were tested with AWS SigV4 (request signing with AWS access keys) and OAuth with Amazon Cognito JWT tokens. The choice depends on the application architecture.

Why isn't enabling WAF alone without a resource policy enough?

AWS WAF only protects traffic that passes through the ALB. If you don't close direct access to the AgentCore endpoint with a resource policy using the `aws:SourceVpce` condition, an attacker can bypass WAF by calling AgentCore directly at its public address.

Why is

Amazon Bedrock AgentCore Runtime vulnerable without WAF?

AgentCore Runtime has no built-in web-application-level filtering by default. Without additional architecture, an attacker can attack the agent with injections, DDoS or request forgery.