AWS adds Policy Engine and Lambda interceptors to Bedrock AgentCore gateway for agent security controls

Amazon Web Services launched Policy Engine and Lambda interceptors for Bedrock AgentCore gateway, addressing a core security challenge in enterprise AI agent deployments: controlling which tools agents can access at runtime.

The new features provide two complementary security mechanisms. The Policy Engine uses Cedar, AWS's open-source policy language, to define deterministic access control rules. Cedar policies evaluate each request against a principal, action, and resource with optional conditions, producing auditable allow/deny decisions. Lambda interceptors run custom code before or after tool calls, enabling dynamic validation, payload enrichment, token exchange, and response filtering.

How the security model works

When an AI agent attempts to call a tool through AgentCore gateway, the request interceptor Lambda function executes first, transforming the request by replacing bearer tokens with tenant-scoped credentials and injecting additional context. The Policy Engine then evaluates the transformed request against defined Cedar policies before permitting tool invocation.

According to AWS, the architecture follows a deny-by-default model. Without an explicit permit policy, all requests are blocked. Organizations define baseline permit rules, then layer forbid rules on top to carve out specific restrictions.

Lakehouse data agent implementation

AWS demonstrated the security model with a lakehouse data agent that queries insurance claims data stored in Amazon S3 Tables (Apache Iceberg) through Amazon Athena and AWS Lake Formation. The agent serves three user roles: policyholders (viewing own claims only), adjusters (managing assigned claims), and administrators (full data access including audit logs).

The implementation uses DynamoDB to store role-to-tool access mappings, tenant IAM role configurations, and user geography data. AWS Lake Formation enforces row-level and column-level security at query time, automatically scoping results to what each caller's IAM role permits.

In the reference implementation, policyholders are blocked from calling the get_claims_summary tool through a Cedar forbid rule:

forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"lakehouse-mcp-target___get_claims_summary",
  resource == AgentCore::Gateway::"<gateway_arn>"
) when {
  principal.hasTag("cognito:groups") && 
  principal.getTag("cognito:groups") like "*policyholders*"
};

The forbid rule takes precedence over baseline permit policies, blocking the specific tool while leaving other access intact.

Geography-based access control

The system combines Lambda interceptors and Policy Engine to implement geography-based access restrictions. The Lambda interceptor dynamically validates user geography from DynamoDB and injects it as request context. The Policy Engine then evaluates Cedar policies against that enriched context to enforce data residency rules.

Authentication flows through Amazon Cognito, which issues JWT bearer tokens passed to the agent. AgentCore Runtime validates tokens and establishes isolated sessions per user. All policy decisions and tool invocations stream to Amazon CloudWatch for compliance auditing.

What this means

The launch addresses a fundamental governance problem in enterprise AI platforms managing hundreds of agents accessing thousands of tools across different teams and business units. Unlike traditional applications with fixed logic, LLM-powered agents decide at runtime which tools to invoke, making advance call graph auditing impossible.

AWS recommends starting with policy enforcement mode set to LOG_ONLY, writing all policy decisions to CloudWatch without blocking requests. This allows organizations to validate policies against production traffic patterns before enforcing restrictions. The combination of deterministic Cedar policies and dynamic Lambda interceptors provides layered security architecture for controlling agent behavior at scale.