Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway

Amazon Bedrock AgentCore gateway now supports Policy and Lambda interceptors to secure AI agent behavior, addressing the challenge of managing access to thousands of tools across enterprise platforms. The Policy mechanism provides deterministic access control using Cedar language policies, while Lambda interceptors enable dynamic validation, payload enrichment, and response filtering before or after tool calls. This layered security architecture allows organizations to enforce governance on LLM-powered agents that dynamically select tools at runtime, solving the auditing and compliance problems inherent in traditional fixed-logic applications.

Artificial Intelligence https://aws.amazon.com/blogs/machine-learning/ Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway Securing AI agent behavior is a key customer challenge in building agentic solutions. As enterprises rapidly adopt AI agents to automate workflows, they face a scaling challenge in managing secure access to tools across the organization. Modern unified enterprise AI platforms have hundreds of agents serving users across the organization. These agents need to access thousands of Model Context Protocol MCP tools spanning different teams, organizations, and business units. The scale of these platforms creates a fundamental governance problem. Traditional applications execute fixed logic. Agents powered by a large language model LLM decide at runtime which tools to invoke, with what arguments, and in what sequence. Because of the dynamic nature of this workflow, auditing the call graph in advance becomes a problem. You must build mechanisms for an LLM so that it behaves the way you intend. You can use Amazon Bedrock AgentCore gateway https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html to secure agents and tools through two complementary mechanisms: Policy in Amazon Bedrock AgentCore https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html for deterministic access control and interceptors for AgentCore gateway https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html for dynamic validation. Policy in Amazon Bedrock AgentCore lets you define policies on tools attached to your Gateway. Policies are authored in Cedar, a declarative policy language that evaluates each request against a principal , an action , and a resource , with optional conditions over request context. The result is a deterministic allow or deny decision, automatically recorded in the audit log. Lambda interceptors let you define custom code that runs before or after each tool call, supporting dynamic validation, payload enrichment, token exchange, and response filtering. You can combine both mechanisms to build a layered security architecture for your agentic solutions. In this post, we use a lakehouse data agent to demonstrate how you can use Policy for deterministic access control and Lambda interceptors for dynamic validation. We then show how to combine Lambda interceptors and Policy to implement a geography-based access control which requires both dynamic validation and deterministic access control. Prerequisites Before implementing this solution, you need: An AWS account https://aws.amazon.com/free/?trk=04d587d8-77d6-4750-bffa-2bc5a475e1a9&sc channel=ps&ef id=EAIaIQobChMI7NLH8eDRkwMVJ0n AR2 lTPDEAAYASAAEgKGlPD BwE:G:s&s kwcid=AL 4422 3 798517281036 e g create%20aws%20account 23610836392 199347046688&gad campaignid=23610836392&gclid=EAIaIQobChMI7NLH8eDRkwMVJ0n AR2 lTPDEAAYASAAEgKGlPD BwE .- Access to the GitHub repository https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/lakehouse-agent . AWS Identity and Access Management IAM permissions https://docs.aws.amazon.com/IAM/latest/UserGuide/access policies.html to set up the prerequisites https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/lakehouse-agent prerequisites . Solution overview The lakehouse data agent is an AI assistant that lets insurance company employees query claims data. The data is stored in Amazon S3 Tables https://aws.amazon.com/s3/features/tables/ Apache Iceberg and queried through Amazon Athena https://aws.amazon.com/athena/ and AWS Lake Formation https://aws.amazon.com/lake-formation/ . Three user roles exist in the application: policyholders who can only view their own claims , adjusters who manage assigned claims , and administrators who have full data access including audit logs . A Streamlit UI authenticates users through Amazon Cognito https://aws.amazon.com/cognito/ and passes JSON Web Tokens JWT to the agent. The MCP Server exposes five tools: query claims , get claim details , get claims summary , query login audit , and text to sql . Role-to-tool access, tenant IAM role mappings, and user geography are stored in Amazon DynamoDB. AWS Lake Formation enforces row-level and column-level security at query time. In this case, even if an agent constructs a broad SQL query, the results are automatically scoped to what the caller’s IAM role is permitted to see. The following diagram shows the architecture for the lakehouse data agent: Users access the lakehouse agent through a Streamlit UI, where Amazon Cognito authenticates them and issues bearer tokens. AgentCore Runtime hosts the lakehouse agent, validates these tokens, and establishes isolated sessions for each user. When the agent invokes tools, AgentCore Gateway routes requests through a Lambda Interceptor. The Interceptor extracts the bearer token, validates tool access through Tenant Role Mapping, and generates a token with tenant-scoped claims. The AgentCore Policy Engine evaluates each tool call against defined policies before permitting access. The lakehouse MCP Server then queries data using the scoped credentials. AWS Lake Formation enforces row-level and column-level security based on the Users Table and Claims Table, helping each user see only the data they are authorized to access. AgentCore Observability and Session Logs stream to Amazon CloudWatch for real-time monitoring and compliance auditing. Request flow The following diagram shows the tool call flow through the solution: When the lakehouse agent initiates a tool call through the AgentCore Gateway, the request is intercepted by the Request Interceptor Lambda function. The Request Interceptor transforms the request by replacing the bearer token with tenant-scoped credentials and injects additional context. The Policy Engine then evaluates the transformed request based on the Cedar policy. The transformed request is used to invoke the tool using the lakehouse MCP Server. The response is then evaluated by the Response Interceptor Lambda function, which filters the tool list before the response is returned to the user. The Gateway evaluates the request interceptor before the Cedar policy. This order is fundamental to the design patterns where you would use the interceptor to enrich the request context before using policy to evaluate that enriched context. Policy enforcement in AgentCore Gateway Policy in Amazon Bedrock AgentCore uses the Cedar policy language to enforce deterministic, auditable access control at the Gateway. Cedar policy is expressed as permit or forbid rules evaluated over a principal, an action, and a resource, with conditions based on the context of the action. We use Cedar policies for fine-grained access control when the authorization rules can be expressed as a logical condition over identity attributes, action identifiers, and request context. Typical use cases include restricting which tools a role can invoke and blocking access to sensitive operations for certain user groups. Cedar also enforces data-residency rules based on context attributes injected by an interceptor, and supports scope-checking or time-window enforcement at the gateway before requests reach downstream services. Design 1: Policy only First, let’s look at an example of a policy acting as a security layer for the lakehouse agent. Consider the scenario where the business decides that policyholders should not be able to call get claims summary . Policyholders can view their own individual claims, but the aggregate summary is reserved for adjusters and administrators. To do this, you can attach a Policy Engine to the Gateway https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-getting-started.html and define two Cedar policies that work together: a baseline permit rule and a targeted forbid rule. When a Policy Engine is attached to a Gateway, it follows deny-by-default semantics. If no policy explicitly permits a request, it is denied. Therefore, you first need a baseline permit policy that allows the agent to invoke tools on the Gateway: permit principal, action, resource == AgentCore::Gateway::"<gateway arn " ; With this policy alone, all authenticated users can invoke any tool. Next, add a forbid rule to carve out the specific restriction for policyholders. Because forbid rules take precedence over permit rules in Cedar, this single rule is sufficient to block the targeted tool invocation while leaving all other access intact. 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 combination of these two policies allows the agent to invoke any tool, except when policyholders attempt to access the claims summary. Note: A best practice is to begin with the policy enforcement mode on the policy engine set to LOG ONLY . All policy decisions are written to CloudWatch, but no requests are blocked. This lets you validate that every policy rule behaves as expected before switching to ENFORCE mode. The following diagram shows the tool call flow following the policy only pattern: When the lakehouse agent sends an incoming request, AgentCore Gateway first validates the JWT token using built-in authorization. The Policy Engine then evaluates the request against a combination of attached Cedar policies. In this example, the Cedar policy uses a forbid-permit pattern. It first forbids access to the get claims summary tool for OAuth users, then permits access only when the principal has a Cognito group tag matching policyholders . This deterministic policy evaluation makes sure that only users belonging to authorized groups can invoke specific tools. Based on the policy evaluation result, the Gateway either permits the call to the lakehouse MCP Server and returns the original response to the agent, or denies the request before it reaches the tool. Policy evaluation results for Design 1 User | Tool | Expected result | Decision owner | | policyholder001 | query claims | Allow | Policy: permit matches | | policyholder001 | get claim details | Allow | Policy: permit matches | | policyholder001 | get claims summary | DENY | Policy: forbid overrides | | adjuster001 | get claims summary | Allow | Policy: no forbid match | Benefits of policy-based enforcement Cedar policies provide three key benefits for securing AI agents: - They are deterministic. The same inputs always produce the same decision regardless of LLM behavior. - They are auditable. Once CloudWatch log delivery is enabled for the Gateway, every allow or deny decision is recorded with full context, providing a full audit trail. - They add low latency. Cedar evaluation introduces minimal overhead to request processing. Interceptors for dynamic control Interceptors are custom Lambda functions that AgentCore Gateway invokes at two stages in the request lifecycle. A REQUEST interceptor runs before the request reaches the downstream tool, and a RESPONSE interceptor runs before the response is returned to the agent. The Gateway passes each interceptor a JSON event under the mcp key, containing the original request headers and body. The interceptor transforms the request content and returns it in the same structure. Interceptors work with all Gateway target types including Lambda functions, OpenAPI endpoints, and MCP servers. For the full payload contract and a detailed walkthrough, see this post https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/ . When an agent invokes tools on behalf of the user, a critical security decision is how identity propagates through the call chain. The impersonation approach is to pass the original user JWT unchanged to each downstream service. This is simpler, but it also allows downstream services to receive more permissions than they need. A compromised service can then reuse the overly privileged token elsewhere the confused deputy problem https://en.wikipedia.org/wiki/Confused deputy problem . An alternate approach is “act-on-behalf”, where each downstream target receives a separate, least-privileged token scoped specifically for that service. The user’s identity context flows through for auditing. Design 2 implements this pattern. The REQUEST interceptor exchanges the user’s Cognito JWT for short-lived, tenant-scoped IAM credentials through sts:AssumeRole , and those scoped credentials are what reaches the MCP Server. Design 2: Interceptor only — act-on-behalf token exchange and context propagation Three operations occur in the REQUEST interceptor that Cedar cannot perform: - JWT-to-IAM token exchange act-on-behalf . Read the user’s Cognito group from the JWT, look up the corresponding tenant IAM role in DynamoDB, and call sts:AssumeRole to obtain short-lived scoped credentials. - Context injection. Write user identity and the temporary IAM credentials into the MCP request body at params.arguments.context so the MCP Server can use them to construct scoped Athena clients. - Tool authorization. Check DynamoDB allowed tools before forwarding the request, returning a structured MCP error for unauthorized calls. The REQUEST interceptor handler simplified : The MCP Server receives the transformed request with the injected context. Each tool function accepts a context argument and uses it to construct a scoped Athena client. Lake Formation then applies row-level and column-level filters automatically at query time based on the tenant role’s permissions without a SQL WHERE clauses: Call flow for the Interceptor-only pattern The following diagram shows the call flow for the Interceptor-only pattern: When the lakehouse agent sends an incoming request, AgentCore Gateway validates the JWT token and routes the original request as a JSON event with the mcp key to the Gateway Request Interceptor Lambda. This interceptor transforms the request by exchanging the Cognito JWT for tenant-scoped credentials and validating tool authorization. The Gateway then calls the lakehouse MCP Server using the transformed request with injected context and tenant credentials. When the MCP Server returns the original response, a Gateway Response Interceptor processes it before returning to the agent. This interceptor filters the tool list and redacts sensitive information dynamically based on user permissions, helping each user see only the tools and data they are authorized to access. Dynamic tool filtering with the Response interceptor A Response interceptor also gives you control over what the agent sees after a tool responds. The most common use is filtering the tools list and semantic search responses to show each user only the tools they are permitted to call. You can also integrate with services such as Amazon Bedrock Guardrails https://aws.amazon.com/bedrock/guardrails/ for use cases like personally identifiable information PII redaction. This improves security by hiding unauthorized tools from the agent and preventing sensitive information like PII from leaking. It also improves reliability by giving the LLM a smaller, correctly scoped tool list, reducing erroneous tool-selection decisions. When to use Policy compared to Lambda interceptors Policy and interceptors are not interchangeable. They serve different purposes in the security architecture. The following table summarizes the key decision criteria. Consideration | Use Policy | Use Lambda interceptor | | Nature of the rule | Deterministic logical condition over known attributes | Requires external data or runtime computation | | External lookups DynamoDB, STS, APIs | Not supported | Full access | | Payload transformation | Not supported | Full read/write access to headers and body | | Response modification | Not supported | RESPONSE interceptor | | Latency impact | Negligible <1 ms, on Cedar evaluation | Lambda cold start + execution time | | Auditability | Automatic per-decision CloudWatch logging | Lambda logs manual instrumentation | | Emergency block | Add forbid rule through API, immediate effect | Lambda redeploy required | | Rule change velocity | High: API call, no redeploy | Low: code change + redeploy | | Evaluation order | After REQUEST interceptor | Before Cedar Policy | | Token exchange / credential vending | Not supported | Full STS and secrets access | | Semantic search filtering | Not supported | RESPONSE interceptor | Use Policy when: - You need a hard, auditable boundary that cannot be bypassed by the agent or the LLM. - The authorization rule depends only on identity claims, action name, resource ARN, or context already present in the request. - You need an emergency kill switch. A forbid rule takes effect immediately through the control-plane API. Use interceptors when: - The rule requires data that must be fetched at runtime DynamoDB, secrets, external authorization services . - You need to transform or enrich the request payload before it reaches the tool. - You need to filter or sanitize the tool response before it returns to the agent. - The authorization decision is stateful — for example, token exchange or per-user rate limiting. - You need to enforce authorization at the method level tools/call compared to tools/list rather than at the tool level. The design goal is composability. Use interceptors for everything that is inherently dynamic, and Cedar for everything that can be expressed as a logical rule over the enriched context. Because REQUEST interceptors run before Cedar, the two mechanisms form a natural pipeline rather than competing for the same responsibility. Combining Policy and Lambda interceptors When policies and interceptors operate together, each layer handles what it does best. The following diagram shows the call flow using the layered security with a combination of Policy and Lambda interceptors: In this pattern, when the lakehouse agent sends an incoming request, AgentCore Gateway validates the JWT token and routes the original request to the Gateway Request Interceptor Lambda. This interceptor enriches the request by dynamically injecting geography , user id , and tenant credentials. The Policy Engine then performs deterministic Cedar policy evaluation based on this enriched context, providing consistent access decisions. If permitted, the Gateway calls the lakehouse MCP Server using the transformed request with injected tenant credentials. When the MCP Server returns the original response, a Gateway Response Interceptor filters the tool list and redacts sensitive information dynamically based on user permissions before returning the transformed response to the agent. The evaluation order is REQUEST interceptor before Cedar policy. With this composition, you can use the interceptor to fetch any data from any source and inject it into the request arguments, and use Cedar policies to evaluate the already-enriched request. We will see this again in the next design pattern. Design 3: Policy + Interceptor — geography-based access control This pattern addresses an example compliance requirement. We want to create a boundary that users operating from EU jurisdictions should not be able to access individual claim records, only aggregate summaries. This is a data-residency rule that combines a dynamic attribute user geography stored in DynamoDB with a deterministic policy rule EU users may not call query claims or get claim details . Cedar cannot fetch geography from DynamoDB. The Lambda interceptor cannot express declarative forbid semantics with automatic audit logging. The combination of Policy and Lambda interceptor handles both by using the Lambda interceptor to fetch geography and enrich the request. Policy then uses this enriched request to evaluate the individual claim records based on user geography before passing the request to the target. Step 1: Interceptor fetches geography and injects it into tool arguments Key detail: Cedar references tool arguments as context.input.<field . Cedar can access any field regardless of nesting depth, but placing geography at the top level of params.arguments keeps the policy concise. It can then be referenced as context.input.geography instead of the more verbose context.input.context.geography if nested. Step 2: Cedar policy evaluates the injected geography // EU users cannot access individual claim records GDPR data-residency requirement . // The broad permit all rule still allows EU users to call get claims summary. forbid principal, action in AgentCore::Action::"lakehouse-mcp-target query claims", AgentCore::Action::"lakehouse-mcp-target get claim details" , resource == AgentCore::Gateway::"<gateway arn " when { context.input has geography && context.input.geography == "EU" }; // Restricted geographies are denied all tool access. forbid principal, action in AgentCore::Action::"lakehouse-mcp-target query claims", AgentCore::Action::"lakehouse-mcp-target get claim details", AgentCore::Action::"lakehouse-mcp-target get claims summary", AgentCore::Action::"lakehouse-mcp-target query login audit", AgentCore::Action::"lakehouse-mcp-target text to sql" , resource == AgentCore::Gateway::"<gateway arn " when { context.input has geography && context.input.geography == "RESTRICTED" }; All three forbid policies are evaluated together by the same Cedar Policy Engine. If any forbid rule matches, the request is denied regardless of any matching permit rule. Responsibility matrix for the combined design Control | Handled by | Why this layer | | User authentication JWT | Gateway JWT Authorizer | Built-in capability, no custom code needed | | Tool authorization group → tool | Cedar Policy forbid | Declarative, auditable, no Lambda redeploy | | Act-on-behalf token exchange | Lambda interceptor | Requires sts:AssumeRole — Cedar cannot call APIs | Context injection user id , credentials | Lambda interceptor | Requires DynamoDB lookup and payload mutation | | Geography lookup and injection | Lambda interceptor | Requires DynamoDB lookup and payload mutation | | Geography-based access control | Cedar Policy forbid | Declarative rule over injected attribute, with audit log | | Tool list filtering UX | RESPONSE interceptor | Requires response body modification | | Row/column data security | Lake Formation | Backend enforcement underneath the Gateway layer | Policy evaluation results for Design 3 User | Geography | Tool | Expected result | Decision owner | | policyholder001 | US | query claims | Allow | No forbid rule matches | | policyholder002 | EU | query claims | DENY | Cedar: EU forbid on individual claims | | policyholder002 | EU | get claims summary | DENY | Cedar: Design 1 policyholder forbid | | adjuster001 | US | get claims summary | Allow | No forbid rule matches | | adjuster002 | EU | get claim details | DENY | Cedar: EU forbid on individual claims | | any user | RESTRICTED | any tool | DENY | Cedar: RESTRICTED geography forbid | End-to-end implementation walkthrough To try this solution yourself, start by cloning the Amazon Bedrock AgentCore samples repository https://github.com/awslabs/amazon-bedrock-agentcore-samples and navigating to the lakehouse-agent directory https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/lakehouse-agent : Then follow the setup and deployment instructions in the README of this directory to configure your AWS environment and run the deployment using the CLI scripts. Step 1: Pre-deploy generate cdk.json, detach interceptors, update Lambda To prepare for the CDK deployment, run pre-deploy.sh to perform the following steps in one shot: - Automatically generate cdk.json from SSM Parameter Store. - Temporarily detach interceptors from the Gateway. - Update and redeploy the Request Interceptor Lambda function with Design 3 support. Step 2: CDK deploy Use CDK to create the Policy Engine, create four Cedar policies, and attach the Policy Engine and interceptors to the AgentCore Gateway. Step 3: Validate with test requests Invoke the agent with credentials for policyholder002 geography=EU and confirm that query claims returns a 403 from the EU geography forbid rule. Then verify that get claims summary also returns a 403, caught by the Design 1 policyholder guardrail. Test with policyholder001 geography=US and confirm that query claims succeeds and returns only that user’s own claims enforced by AWS Lake Formation . Observability: end-to-end traceability through the pipeline AgentCore Gateway integrates with AgentCore Observability and Amazon CloudWatch, providing traceability across every enforcement layer. Each layer leaves a distinct, queryable trace. The Gateway JWT authorizer logs the token validation outcome for every request. The REQUEST interceptor Lambda function logs JWT claims extraction, DynamoDB lookup results, token exchange outcome, and geography injection. The Policy Engine logs the full authorization context and the resulting ALLOW or DENY decision for every evaluation. The RESPONSE interceptor Lambda function logs which tools were filtered from tools/list and semantic search responses, providing a record of tool visibility per user. Next steps The sample code for all three designs is available in the GitHub repository https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/lakehouse-agent/deployment/advanced-agentcore-policy-gateway-interceptor . Start with the policy rules demonstrated in Design pattern 1, then build out Designs 2 and 3 incrementally as your security and compliance requirements grow. Clean up We recommend that you clean up any resources you do not plan to continue using. This avoids any unexpected charges. Follow the instructions https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/02-use-cases/lakehouse-agent to clean up after you have explored the solution. Conclusion In this post, we demonstrated three design patterns to build secure agents using Policy, Lambda interceptors, and a combination of both. Use Policy when the authorization rule is deterministic and expressible over identity and context. Use Lambda interceptors when the rule requires external data, payload transformation, or token exchange. Combine both when you need to fetch dynamic context at runtime and enforce rules over it declaratively. You can use these patterns to secure agent behavior as you build your agentic solutions.