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: awslabs/agentcore-samples/role-based-hr-data-agent

Three steps on Amazon Bedrock AgentCore Runtime and Amazon Bedrock AgentCore Gateway: authentication, scope-based permissions, and gateway enforcement. Let's go.

Step 1: IDP Integration

You start by integrating your identity provider to answer the fundamental question: who is making this request? When users authenticate through your IDP (e.g., Okta, Entra ID, Amazon Cognito), they receive a JWT token. This token proves their identity and includes claims about who they are and what permissions they have.

Every agent invocation needs to validate this JWT token. The token must be:

• Cryptographically signed by your IDP (signature validation)
• Not expired (expiration check)
• Intended for your application (audience validation)

Amazon Bedrock AgentCore Runtime handles this for you. You configure your Runtime with a custom authorizer that handles all JWT validation automatically. Point it to your IDP's discovery URL, and the Runtime fetches the public keys, validates signatures, and rejects invalid tokens.

AgentCore Runtime supports multiple authorizer types: CUSTOM_JWT (for OAuth 2.0 compliant IDPs), AWS_IAM (for AWS IAM principals), and NONE (for development). See the AgentCore Runtime documentation 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": "[e-mail]",
  "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:

User Type	Example Scopes	What They Can Do
Full Access User	api/read api/write api/admin	All tools and data
Standard User	api/read api/write	Read and modify, no admin tools
Read-Only User	api/read	View data only

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

Persona 2: HR Specialist (No Compensation)

OAuth Scopes: read pii

In this system, the pii scope covers identity fields (SSN, date of birth) needed for verification, but not residential data. Address is a separate address scope which HR Specialists don't have.

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": "[REDACTED]",
  "city": "[REDACTED]",
  "state": "[REDACTED]",
  "salary": "[REDACTED]",
  "bonus": "[REDACTED]",
  "stock_options": "[REDACTED]"
}

Use case: HR Specialists need PII access for:

• Onboarding new employees
• Offboarding processes
• Employee record updates
• Identity verification

What they DON'T see: Compensation and home addresses

Persona 3: Employee (Self-Service Only)

OAuth Scopes: read

What they see (when querying their own record):

{
  "employee_id": "12345",
  "name": "Jane Doe",
  "job_title": "Senior Engineer",
  "department": "Engineering",
  "manager": "John Smith",
  "ssn": "[REDACTED]",
  "date_of_birth": "[REDACTED]",
  "home_address": "[REDACTED]",
  "city": "[REDACTED]",
  "state": "[REDACTED]",
  "salary": "[REDACTED]",
  "bonus": "[REDACTED]",
  "stock_options": "[REDACTED]"
}

Additional Cedar rule: Employees can only view their own record. If Jane tries to query another employee, the request is blocked entirely.

Use case: Employees can self-serve:

• Look up their manager
• Check department info
• View job title

What they DON'T see: Any sensitive data (PII, compensation, addresses)

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.