Amazon Bedrock AgentCore Gateway でポリシーと Lambda インターセプタを用いた AI エージェントのセキュリティ強化

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 to secure agents and tools through two complementary mechanisms: Policy in Amazon Bedrock AgentCore for deterministic access control and interceptors for AgentCore gateway 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.

• Access to the GitHub repository.

• AWS Identity and Access Management (IAM) permissions to set up the 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 (Apache Iceberg) and queried through Amazon Athena and AWS 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 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 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::""
);

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::""
) 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.

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). 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):

def lambda_handler(event, context):
    # Parse the MCP gateway request from the interceptor event
    mcp_data = event.get('mcp', {})
    gateway_request = mcp_data.get('gatewayRequest', {})
    body = gateway_request.get('body', {})
    headers = gateway_request.get('headers', {})

    token = extract_bearer_token(headers)
    claims = validate_and_decode_jwt(token)  # Step 1: validate Cognito JWT

    # Step 2: check tool authorization against DynamoDB allowed_tools
    is_authorized, error_msg, tool_name = validate_tool_access(claims, body)
    if not is_authorized:
        return build_mcp_error_response(error_msg, status_code=403)

    # Step 3: act-on-behalf --- exchange JWT group claim for tenant IAM credentials
    claim_name, claim_value = get_claim_for_exchange(claims)
    tenant_credentials = exchange_jwt_to_iam(claim_name, claim_value)  # sts:AssumeRole

    # Step 4: inject user identity and scoped credentials into the MCP request body
    if 'params' in body and 'arguments' in body['params']:
        body['params']['arguments']['context'] = {
            'user_id': user_principal,
            'tenant_credentials': {
                'access_key_id': tenant_credentials['AccessKeyId'],
                'secret_access_key': tenant_credentials['SecretAccessKey'],
                'session_token': tenant_credentials['SessionToken'],
            }
        }

    # Return transformed request in the required interceptor output format
    return {
        'interceptorOutputVersion': '1.0',
        'mcp': {
            'transformedGatewayRequest': {
                'headers': transformed_headers,
                'body': body,
            }
        }
    }

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:

# server.py --- query_claims tool
def query_claims(claim_status=None, context=None):
    user_id, tenant_creds = get_user_id_with_fallback(context)

    # Athena client uses the tenant's scoped IAM credentials (not the user's JWT)
    # Lake Formation applies row-level and column-level filters automatically
    athena_client = boto3.client(
        'athena',
        aws_access_key_id=tenant_creds['access_key_id'],
        aws_secret_access_key=tenant_creds['secret_access_key'],
        aws_session_token=tenant_creds['session_token']
    )
    ...

Call flow for the Interceptor-only pattern

The following diagram shows the call flow for the Interceptor-only pattern:

<img src="https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/05/29/ML-20712-4.png" alt="Interceptor-only call flow showing AgentCore Gateway routing the original request to the Request Interceptor Lambda, which exchanges the JWT for tenant-scoped credentials, calls the lakehouse MCP Server, and routes the response through a Response Interceptor that filters the tool list before returnin