Athena User-Level Connector with RBAC

The Athena user connector lets a Custom Chatbot query Amazon Athena under each end user's own AWS permissions. Users authenticate individually through Amazon Cognito, Abacus.AI exchanges their Cognito tokens for temporary AWS credentials, and every query runs with the IAM role that Cognito maps to that user. Data access is therefore always governed by your own IAM and Lake Formation policies.

Athena is a database user connector: it is used through a Custom Chatbot and is not a direct chat tool for RouteLLM.

This guide is split into short pages so you only follow the route that applies to you:

Page	Who it is for
Set up Amazon Cognito	Everyone. The user pool, app client, identity pool, groups and IAM roles that all three access models share.
Option A — Role-level access	Users in the same Cognito group should see the same tables.
Option B — Email-based row filtering	Each user should see only their own rows.
Option C — Combined table and row isolation	Different groups see different tables, and within them users see only their own rows.
Connect to Abacus.AI and use in ChatLLM	Everyone. Create the RBAC-enabled connector, build the chatbot, and troubleshoot.

Prerequisites

• An organization-level Athena connector with RBAC enabled (created in the last step; the org-level fields are described in the Athena connector guide)
• An Amazon Cognito User Pool with users provisioned
• An Amazon Cognito App Client configured for OAuth 2.0 with the redirect URI https://abacus.ai/oauth/callback
• An Amazon Cognito Identity Pool that maps authenticated Cognito users to IAM roles
• IAM roles and policies for user-level Athena access, and AWS Lake Formation if you need row-level filtering

How it works

1. An organization admin creates an Athena connector with RBAC enabled, providing the Cognito configuration.
2. Each user authenticates via Cognito OAuth when they first interact with a Custom Chatbot connected to that connector.
3. Abacus.AI exchanges the user's Cognito tokens for temporary AWS credentials via the Cognito Identity Pool.
4. Queries execute with the user's own AWS permissions, so what they see is decided by IAM policies and Lake Formation, never by Abacus.AI.

Choose your access model

Before diving into setup, decide which access control model fits your needs.

Option A — Role-level (group-based) access. All users in the same Cognito group share the same IAM role and see the same data scope. Cognito user groups → IAM roles → table or database-level permissions via IAM policies or Lake Formation tags. Best for shared dashboards where entire departments access the same datasets.

Option B — User-level (email-based) access. Per-user row isolation using the authenticated user's email address, so users in the same Cognito group can see different rows. Cognito groups → IAM roles → Lake Formation data cell filters with owner_email = '${session:UserEmail}'. Best when each user should see only their own records, for example sales reps and their own leads.

Option C — Combined (group + email) access. Two layers: Lake Formation tags control which tables a group can access, and data cell filters restrict rows by user email within those tables. Best for multi-department setups where groups access different tables and users see only their own data inside them.

Need per-user row isolation?	Need department-level table isolation?	Use
No	No	Option A, the simplest
Yes	No	Option B
Yes	Yes	Option C

info

Options B and C need extra AWS configuration: Lake Formation data cell filters, the sts:TagSession permission on every IAM role, and the email scope on the Cognito app client. Their pages walk through each requirement.

Setup path

1. Set up Amazon Cognito: user pool, app client, hosted UI domain, identity pool, user groups, role mappings and IAM roles.
2. Configure your access model: Option A, Option B or Option C.
3. Connect to Abacus.AI and use in ChatLLM: create the RBAC-enabled Athena connector, build a Custom Chatbot on it, and let users sign in.