AWS Builder Center

Builder Center

Fine-Grained Access Control for Multi-Tenant MCP Servers with AgentCore Gateway & Policy

Authorization patterns for multi-tenant MCP servers using Amazon Bedrock AgentCore through Gateway Interceptors and AgentCore Policy.

Arya Subramanyam

The Multi-Tenant MCP Challenge

MCP servers  provide a standardized way for AI agents to access tools, data sources, and custom functions. When building multi-tenant SaaS applications with MCP, ensuring the LLM can't accidentally or maliciously access another tenant's data through tool invocations is critical—especially for user-facing applications where reliability and security directly impact customer trust.
The core problem: The MCP protocol focuses on tool discovery and invocation, not tenant isolation. When your AI agent calls an MCP tool, how do you ensure it only accesses data for the correct tenant? Traditional approaches might rely on the LLM to "remember" which user it's serving—but that's fundamentally insecure. The LLM could hallucinate user IDs, be manipulated through prompt injection, or simply make mistakes.
Real-world scenario: You're building an AI-powered analytics platform where multiple users query their own data through a shared MCP server. Each user should only access their own data stores, but you need fine-grained access control that works regardless of what the LLM requests. You need an architecture where tenant identity comes from the authentication layer, not from the agent's reasoning.
This post presents a three-layer security architecture using AgentCore Gateway that solves this challenge through defense-in-depth: Gateway Interceptors establish trusted tenant identity, AgentCore Policy enforces tool-level authorization, and MCP tools implement tenant-scoped data access—ensuring the LLM never influences security decisions.

Understanding AgentCore Gateway Security Primitives

Before diving into the multi-tenant architecture patterns, let's understand the three key components that AgentCore Gateway provides for securing MCP servers:
AgentCore Gateway  transforms your existing APIs and AWS Lambda functions into agent-compatible tools, connects to existing MCP servers, and provides seamless integration with essential third-party business tools. This unified access point serves as the central control plane for all agent-to-tool interactions, orchestrating request routing, managing authentication flows, and coordinating the execution of interceptors and policy evaluations.
Gateway Interceptors  are lambda functions that execute at specific points in the request lifecycle—before your MCP tools are invoked (REQUEST interceptors) or after they respond (RESPONSE interceptors). Think of them as middleware that can inspect, validate, transform, or enrich requests as they flow through the gateway. This provides critical functions for multi-tenant MCP architectures such as fine-grained access control, schema translation, custom header propagation, per-tool authorization and data sanitization.
AgentCore Policy  is a declarative authorization framework based on Cedar policy language that evaluates whether a principal (user, agent, or service) can perform an action on a resource. Policies are defined as human-readable rules that security teams can manage without writing code, enabling centralized governance without requiring changes to agent implementations or tool code. These policies are evaluated at the gateway level after interceptors have enriched the request, providing configuration-based security that blocks unauthorized access to MCP tools.

Choosing Between Lambda Interceptors and AgentCore Policy for Tool Authorization

Both Lambda Interceptors and AgentCore Policy can enforce fine-grained tool access control, but they serve different purposes and are owned by different teams. Understanding when to use each—or both together—is critical for building maintainable multi-tenant architectures.
AgentCore Policy  provides fine-grained control through declarative Cedar policies evaluated by a managed policy engine at the gateway level.
  • Declarative configuration - Write human-readable Cedar policies in natural language that convert to formal policy language, no code required
  • Managed policy engine - AWS evaluates policies at infrastructure level without custom Lambda execution or warm-up time
  • Security team ownership - Owned by security, compliance, or governance teams who can update policies independently without code deployments
  • Best for static rules - Ideal when tool access is based on tenant tier, user roles, or other attributes that don't require complex computation
Gateway Interceptors  provide the finest-grained control through custom code, executing at the gateway level with complete flexibility for any authorization logic.
  • Programmatic implementation - Write Python/Node.js functions with full programming language capabilities for complex authorization logic, resource-level validation, and custom business rules
  • Centralized request handling - Single interceptor Lambda handles all tool authorization across all MCP targets, reducing code duplication
  • Developer ownership - Owned and maintained by application development teams as part of the codebase, requiring code deployments for changes
  • Best for dynamic logic - Ideal when authorization depends on time-of-day, geographic location, external API calls, or proprietary algorithms

The Solution: Three-Layer Security for Multi-Tenant MCP

The architecture I'm sharing uses AgentCore Gateway's capabilities to create three complementary security layers, each addressing a different aspect of multi-tenant isolation in a shared infrastructure environment.
The most robust multi-tenant architectures use both Lambda Interceptors and AgentCore Policy in complementary ways. While both can enforce tool-level access control, they serve different purposes. Use Gateway Interceptors for resource-level validation and complex dynamic logic (developer-owned, programmatic). Use AgentCore Policy for static authorization rules and governance (security-team-owned, declarative). The hybrid approach provides defense-in-depth: even if the interceptor fails to validate a resource path, Policy will still block unauthorized tool access. And even if Policy allows tool access, the interceptor ensures the tenant can only access their own data.
The execution order: Interceptors run first to establish identity and enrich context, then Policy evaluates authorization based on that enriched context, and finally the Lambda Target (your MCP tool) executes if authorized.

Layer 1: Gateway Interceptor (Authentication & Identity Injection)

The Gateway Interceptor runs first, before any authorization checks, at the gateway level. Its job is to establish trusted tenant identity from the authentication context—not from the LLM or user input. It extracts the tenant_id from JWT claims, validates it exists and is properly formatted, performs resource-level validation (like checking that requested data paths match the tenant's allowed scope), and forwards the trusted tenant_id to downstream components. This ensures your MCP tools receive authenticated tenant context without needing to handle authentication logic themselves.
The critical insight: The LLM never influences which tenant's data is accessed. The tenant identity comes from the authentication layer, not from the agent's reasoning.

Layer 2: AgentCore Policy (Authorization)

AgentCore Policy runs second, after the interceptor has enriched the request with tenant context. Using declarative Cedar-based policies, you define which MCP tools each tenant tier can access. For example, you might have premium tier users who can access both read_data and query_analytics tools, while basic tier users only access read_data. These policies are evaluated at the infrastructure level, completely independent of LLM behavior. Security teams can manage these policies without code changes, and unauthorized tool access is blocked before any MCP server code executes.
The key benefit: You get configuration-based security that prevents unauthorized tool access at the gateway level. Policy can also evaluate tenant identity directly from JWT claims, providing an additional authorization layer beyond what interceptors provide.

Layer 3: MCP Target or MCP Tool

The MCP tool implementation runs last, only if Policy authorizes the request. It reads the trusted tenant_id from the request context (forwarded from the interceptor), constructs tenant-scoped queries with row-level security, and returns only authorized data for that specific tenant.
Important: The tool itself programmatically constructs data paths using the trusted tenant_id . The LLM only provides business-level parameters like dates or filters, never infrastructure details like storage paths or database table names. This prevents the LLM from accidentally or maliciously specifying paths to other tenants' data.

Example: Success and Blocked Flows

Let me show you how this plays out with two different tenant scenarios:
Premium Tier Success Flow:
1
2
3
4
Client sends JWT with {tenant_id: "user_a", tier: "premium"} requesting the get_data MCP tool with parameter {date: "2024-01"}
Gateway Interceptor extracts user_a from JWT and forwards the tenant_id to downstream components
AgentCore Policy checks: Can tenant_id: user_a with premium tier access get_data? → ✓ ALLOW
MCP Tool (Lambda Target) reads tenant_id: user_a, programmatically constructs path data/user_a/2024-01.json, and returns only user_a's data
Basic Tier Blocked Flow:
1
2
3
4
Client sends JWT with {tenant_id: "user_b", tier: "basic"} requesting the query_analytics MCP tool
Gateway Interceptor validates JWT and forwards tenant_id
AgentCore Policy checks: Can tenant_id: user_b with basic tier access query_analytics? → ✗ DENY (basic tier restricted to read_data only)
Request blocked at gateway level—MCP tool never executes

Adapting the Three-Layer Security Model Across Deployment Patterns

The three-layer security architecture (Interceptor → Policy → Tool) applies across various multi-tenant deployment patterns , but the implementation complexity varies based on your infrastructure model:
  1. Pool (Shared) Pattern - This post focuses on the Pool pattern, where all tenants share the same infrastructure with tenant context flowing through every request. This represents the most challenging security scenario and requires the most rigorous implementation of all three layers.
  2. Silo (Dedicated) Pattern - Each tenant gets dedicated infrastructure (separate Gateway, Runtime, and MCP servers). The three-layer security model simplifies significantly since infrastructure boundaries provide isolation. The interceptor primarily validates that requests are routed to the correct tenant's gateway, Policy focuses on user-level permissions within the tenant rather than cross-tenant isolation, and the MCP Target uses simplified data access logic since cross-tenant concerns are eliminated.
  3. Bridge (Hybrid) Pattern - Premium tenants get dedicated infrastructure while standard tenants share pooled resources. This is the most common pattern in production systems. The interceptor becomes more complex, requiring a control plane to determine each tenant's deployment model and route requests accordingly. Premium tenants route to dedicated infrastructure (similar to Silo pattern), while standard tenants route to pooled infrastructure (using the Pool pattern security model above). Policy rules must account for tier-specific tool access and SLA requirements.

Additional Security Considerations

Regardless of your deployment pattern, implementing these security measures ensures robust tenant isolation and defense-in-depth:
  • Token Scope-Down: Interceptors should request scoped-down tokens for specific tools rather than passing full-scope user tokens, limiting blast radius if a tool is compromised.
  • Response Filtering: RESPONSE interceptors provide a last line of defense, filtering any cross-tenant data that might accidentally leak from MCP servers.
  • Rate Limiting: Per-tenant rate limits prevent noisy neighbor issues where one tenant's heavy workload impacts others.
  • Fail-Secure Defaults: All authorization checks must fail closed—deny access if tenant extraction or validation fails.
  • Data Layer Isolation: Use row-level security or consider dedicated tables per tenant to secure MCP tool access to your data.

Conclusion

Building secure multi-tenant MCP servers requires thinking beyond the MCP protocol itself and carefully considering your tenancy model. By leveraging AgentCore Gateway Interceptors for authentication and identity injection, AgentCore Policy for authorization, and careful MCP tool implementation for data access, you create a defense-in-depth architecture where the LLM never influences security decisions.
The Pool (Shared) pattern we've explored represents the most challenging security scenario, requiring rigorous code-level enforcement of tenant boundaries. However, when implemented correctly with the three-layer security model, it provides an efficient, scalable foundation for multi-tenant SaaS applications. The same security principles apply to Silo and Bridge patterns, with varying levels of infrastructure isolation providing additional safety nets.
The key insight across all patterns is that each layer serves a distinct purpose in the MCP request flow: interceptors establish trusted identity first, policies enforce tool-level authorization second, and MCP tools implement tenant-scoped data access last—all working together to ensure your AI agents are both powerful and secure.
As MCP adoption grows and more SaaS platforms build multi-tenant AI capabilities, these patterns will become increasingly important. The architecture patterns I've shared here provide a solid foundation for building secure, scalable multi-tenant MCP servers on AWS, regardless of which tenancy model best fits your business requirements.

Resources

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article