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.

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.

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.