3 Steps to RBAC for AI Agents on Amazon Bedrock AgentCore

The Problem

Building AI agents has become surprisingly easy. You connect tools via MCP servers, APIs, or built-in capabilities, wire up an LLM, and run tests. The agent performs well and pulls the right data. Then comes the part that actually matters: authorization. It doesn't know who's asking or what they're allowed to see.

TL;DR: Build secure multi-tenant AI agents on Amazon Bedrock AgentCore using OAuth scopes, Cedar policies, and Gateway interceptors. Deterministic authorization for non-deterministic agents. Working code examples included.

Full code is on GitHub: for details.

For this example, we're using Amazon Cognito with CUSTOM_JWT, but you can use any OAuth 2.0 compliant IDP (Okta, Entra ID, Auth0).

Here's how to configure the Runtime with a custom JWT authorizer:

import boto3



client = boto3.client('bedrock-agentcore-control', region_name='us-east-1')



response = client.create_agent_runtime(

    agentRuntimeName='hr-agent-runtime',

    agentRuntimeArtifact={

        'containerConfiguration': {

            'containerUri': '<account>.dkr.ecr.us-east-1.amazonaws.com/hr-agent:latest'

        }

    },

    authorizerConfiguration={

        'customJWTAuthorizer': {

            'discoveryUrl': 'https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXX/.well-known/openid-configuration',

            'allowedClients': ['hr-api-client']

        }

    },

    networkConfiguration={'networkMode': 'PUBLIC'},

    roleArn='arn:aws:iam::<account>:role/AgentRuntimeRole'

)

Now all agent invocations require authenticated JWT tokens. Gated access achieved. The Runtime validates tokens using your IDP's public keys (JWKS) from the discovery URL. Users can't invoke the agent without valid credentials.

Step 2: Scope-Based Permissions

Authentication is done. The user is in the building. But what room can they enter? That's where authorization begins.

You move to authorization by defining OAuth scopes as permission labels. You create scopes that represent different access levels. When users authenticate through your IDP, their JWT tokens include scopes based on their role.

Here's what a JWT token looks like with scopes:

{

  "sub": "[email protected]",

  "iss": "https://your-idp.com",

  "aud": ["your-api-client"],

  "exp": 1715612345,

  "iat": 1715608745,

  "scope": "api/read api/write",

  "groups": ["standard-users"]

}

Key claims:

• 
  sub: User identifier


• 
  iss: Who issued the token (your IDP)


• 
  aud: Intended audience (your application)


• 
  exp: Expiration timestamp


• 
  scope: OAuth scopes defining permissions


• 
  groups: User's role/group assignments

Different roles get different scope combinations:

You've mapped roles to scopes that define who can access which agent and which tools based on the claims in their JWT.

But having scopes in JWT tokens isn't enough. Nothing is checking them yet. The scopes are just claims sitting in a token, ignored unless something enforces them before tools execute.

Amazon Bedrock AgentCore Gateway is that enforcement point.

Step 3: Enforce Scopes with AgentCore Gateway

AgentCore Gateway sits between your agent runtime and your tools. Every tool call flows through it. This gives you a central enforcement point to validate scopes and control access.

First, AgentCore Gateway validates authentication. While Runtime already validated the JWT in Step 1, AgentCore Gateway performs its own independent validation. This is a defense-in-depth pattern where each layer verifies authentication.

Here's how to configure AgentCore Gateway with IDP authentication:

import boto3



client = boto3.client('bedrock-agentcore-control', region_name='us-east-1')



response = client.create_gateway(

    name='hr-agent-gateway',

    protocolType='MCP',

    authorizerType='CUSTOM_JWT',

    authorizerConfiguration={

        'customJWTAuthorizer': {

            'allowedClients': ['hr-api-client'],

            'discoveryUrl': 'https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXX/.well-known/openid-configuration'

        }

    },

    roleArn='arn:aws:iam::<account>:role/GatewayServiceRole'

)

Then, AgentCore Gateway enforces authorization. Your agent is non-deterministic. The LLM decides which tools to call based on natural language prompts, which means you can't trust the agent to consistently enforce authorization rules.

A cleverly worded prompt might trick the agent into calling a tool the user shouldn't access. The agent might hallucinate permissions. The agent doesn't understand security boundaries.

You need deterministic enforcement outside the agent. AgentCore Gateway provides this through Gateway interceptors, Lambda functions that run before and after tool invocations. Fixed, deterministic code. Same input = same output. Every time.

You implement a Request Interceptor, a Lambda function invoked by the Gateway before a tool call reaches its destination:

1. 
   Extract & evaluate. Parse the request to pull user context (token claims, tenant ID, role, scopes). Use those attributes to determine what this user is authorized to do: scope their access, identify their tenant, resolve their permissions.


2. 
   Enforce & enrich. Inject tenantId into tool parameters for tenant isolation. Add/strip headers. Transform or restrict parameters based on role. Reject unauthorized requests outright.


3. 
   Forward. Return the modified (or blocked) request to the Gateway, which routes it to the target (an MCP server or direct tool invocation).

If the scopes are insufficient, the interceptor rejects the request before it ever reaches your tools. Your agent code doesn't change. Your tool code doesn't change. The enforcement logic lives in the interceptor Lambda.

But the interceptor operates at the request level. It sees the raw inbound call. It doesn't evaluate what the agent decided to do. When the agent autonomously selects a tool and constructs parameters, you need to evaluate: Is this principal allowed to perform this action on this resource, with these parameters?

This is where Cedar policies come in. AgentCore Gateway supports Cedar policy evaluation as part of its authorization layer.

Cedar evaluates the authorization request constructed from the JWT claims and the tool call. The interceptor and Cedar operate as complementary but independent layers: the interceptor provides imperative custom logic, while Cedar provides declarative policy evaluation against the original request.

Here's what Cedar evaluates:

1. 
   Principal - The user making the request (created from the JWT's sub claim)


2. 
   Action - Which tool they're trying to invoke (extracted from the tool name)


3. 
   Resource - The Gateway instance (the resource boundary being protected)


4. 
   Context - The tool arguments and additional attributes (tenant, time, etc.)

Cedar checks these attributes against your policies and returns a decision: ALLOW or DENY.

Example Cedar policy:

// Only users with 'read' scope can search employees

permit(

  principal,

  action == AgentCore::Action::"HRDataTarget___search_employee",

  resource

) when {

  principal.getTag("scope") like "*hr-dlp-gateway/read*"

};



// Only users with 'comp' scope can access compensation

permit(

  principal,

  action == AgentCore::Action::"HRDataTarget___get_employee_compensation",

  resource

) when {

  principal.getTag("scope") like "*hr-dlp-gateway/comp*"

};

The flow becomes:

1. Gateway validates the JWT signature (CUSTOM_JWT authorizer)


2. 
   Request Interceptor (if configured) runs custom Lambda logic to enrich, validate, or block the request


3. 
   Cedar policy evaluation (if configured) independently evaluates the original JWT claims and tool call against declarative policies


4. If either layer denies → request blocked with 403


5. If both allow → tool invocation proceeds

You can use interceptors alone, Cedar alone, or both together. They're complementary layers, not a required chain. In this demo, we use both: interceptors for runtime enrichment and Cedar for declarative policy enforcement.

With both layers active, you've achieved three critical controls:

1. 
   Tenant isolation - Users can only invoke tools for their own tenant (interceptor injects tenantId into tool parameters)


2. 
   Scope-based enrichment - Request Interceptor extracts scopes from the JWT and injects context for downstream evaluation


3. 
   Tool-level authorization - Cedar evaluates each tool invocation request against declarative policies and blocks unauthorized calls

At this point, you've secured tool invocation. But there's another gap: tool discovery.

Say your agent connects tools via an MCP server with 5 tools defined. Users ask "what tools are available?" and get the complete list. Cedar prevents unauthorized invocations, but users still see everything.

This is a security risk. Why should users see tools they'll never be authorized to use? You're leaking information about system capabilities.

You need to filter tool discovery based on scopes. Users should only see tools they're authorized to invoke. This requires intercepting the response AFTER the MCP server returns the tool list, but BEFORE it reaches the caller (agent or user).

That's where the Response Interceptor comes in. It filters tool lists based on the user's scopes. It also redacts data fields in tool responses before they reach the caller.

Now let's see these layers in action. Here's how the same query produces different results for three personas.

Define Your Access Control Personas

Let me show you with an HR agent. Consider a simple request: "Show me John Smith's full profile."

Who's asking matters:

• 
  HR Manager should see the full salary


• 
  HR Specialist should see job details but NOT compensation
  


• 
  Employee should only see public information

Same query. Three different people. Three different results. This is the multi-tenant authorization problem.

The pattern applies to any multi-tenant agent: customer support agents that scope replies to one customer's tickets, or healthcare agents that limit responses to a single patient's records. The HR example just makes it concrete.

Persona 1: HR Manager (Full Access)

OAuth Scopes: read pii address compensation

What they see:

{

  "employee_id": "12345",

  "name": "Jane Doe",

  "job_title": "Senior Engineer",

  "department": "Engineering",

  "manager": "John Smith",

  "ssn": "123-45-6789",

  "date_of_birth": "1990-05-15",

  "home_address": "123 Main St",

  "city": "Seattle",

  "state": "WA",

  "salary": "$150,000",

  "bonus": "$20,000",

  "stock_options": "5000 shares"

}

Use case: HR Managers need full visibility for:

• Compensation reviews


• Benefits administration


• Compliance reporting

Key Takeaways

Here's what we built and why it matters:

1. Authentication ≠ Authorization

• 
  Authentication = WHO the user is (Your IDP)


• 
  Authorization = WHAT they can access (Cedar + Gateway interceptors)


• You need both layers

2. Deterministic Security for Non-Deterministic Agents

• AI agents generate unpredictable responses


• Your security layer must enforce predictable rules


• OAuth scopes + Cedar policies = deterministic authorization


• Independent of the LLM

3. Defense in Depth

We enforce authorization at multiple points:

• 
  Request Interceptor - Validates scopes and injects tenant context


• 
  Cedar policies - Evaluates tool-level authorization (can this user invoke this tool?)


• 
  Response Interceptor - Redacts fields based on scopes (which fields can this user see?)


• Each layer protects against different attack vectors

4. Field-Level Redaction Without Agent Changes

• Write one query for all roles


• Redact fields based on user's scopes


• The agent doesn't know about authorization


• The interceptor handles it

5. OAuth Scopes are Standardized

Using OAuth 2.0 scopes means:

• Works with standard identity providers (Okta, Entra ID, Cognito, Auth0)


• Industry-standard permission labels


• Portable across different agent platforms

6. Cedar Policies are Auditable

Cedar benefits:

• Human-readable policy language


• Version-controlled in Git


• Audit who has access by reading policy files


• No complex SQL grants or IAM policies to untangle

Conclusion

Building secure multi-tenant AI agents requires one discipline: don't trust the agent to enforce its own boundaries. The agent is non-deterministic. Your security layer must be deterministic.

By using OAuth scopes for field-level permissions, Cedar policies for resource-level authorization, and Gateway interceptors for enforcement, you create a security architecture that works regardless of how the agent behaves. Same user, same request, same authorization decision. Every time.

Clone the repo, deploy it, and test it with the three personas. You'll see exactly how deterministic authorization protects non-deterministic agents.

How do you handle authorization in your AI agents? Have you run into cases where the agent bypassed security rules? Drop a comment and let's discuss!

Opinions are my own.