Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getnao.io/llms.txt

Use this file to discover all available pages before exploring further.

nao Enterprise can pass each end user’s identity through to the warehouse, so queries run as the user asking them instead of as a single shared service account. This unlocks native row-level security (RLS) policies you’ve already configured on the warehouse - the agent inherits those policies automatically, with no nao-side rule duplication. Today this is supported on Amazon Redshift via Microsoft Entra ID. Other warehouses can be added on request.

​
Why per-user identity matters

When nao runs queries with one shared connection, every user sees the same rows: the warehouse can’t tell them apart. That’s fine for analytics agents inside a small team, but it doesn’t fit organizations that already enforce RLS or column-level security at the warehouse layer (sales reps see only their accounts, finance sees only their region, etc.). With per-user identity:
  • Each chat message is executed against the warehouse using the asking user’s access token.
  • Redshift identifies the user and applies whatever native policies you’ve defined (RLS, column masking, role-based grants).
  • nao does not need a parallel rules system - the warehouse stays the source of truth for who can see what.

​
Redshift row-level security via Entra ID

Use this when your Redshift cluster is configured to authenticate end users via Microsoft Entra ID (federated single sign-on).

​
Prerequisites

  • Microsoft SSO is configured for your nao deployment (see Authentication).
  • Your Redshift cluster is set up with Microsoft Entra ID federation and your Azure app registration includes the Redshift scope.
  • Your RLS policies are already defined on the Redshift side (Redshift’s native row-level security feature).

​
Configure the connection

In nao_config.yaml, set auth_mode: azure_entra_id on the Redshift database: 
databases:
  - name: redshift_prod
    type: redshift
    host: your-cluster.region.redshift.amazonaws.com
    port: 5439
    database: analytics
    auth_mode: azure_entra_id
    user: "{{ env('REDSHIFT_USER') }}"          # optional, sync-only
    password: "{{ env('REDSHIFT_PASSWORD') }}"  # optional, sync-only
    schema_name: public
Two auth modes are available:
  • password (default) - traditional service-account auth. All queries run as the same Redshift user.
  • azure_entra_id - per-user identity. Sync-time queries (metadata, previews, query history) use the optional user/password if provided. Runtime queries from the chat agent always flow through the end user’s Azure access token.

​
How it works

  1. The user signs in to nao with Microsoft SSO (Entra ID).
  2. nao stores the user’s encrypted refresh token.
  3. When the agent runs a query, nao silently exchanges the refresh token for an Azure access token scoped to your Redshift API.
  4. The query is sent to Redshift over the IAM-federated connection with that token.
  5. Redshift identifies the user and enforces its native RLS policies.
If a user does not have access to a given row or table, Redshift returns the same response it would return for any other client - the agent surfaces the result as-is.

​
Verifying it works

  1. Sign in as a user with restricted access.
  2. Ask the agent a question that should hit RLS-protected data.
  3. The query result should reflect the user’s policy. Cross-check with the same query run directly against Redshift as that user.
  4. Sign in as a user with broader access and confirm the result set widens accordingly.
The sync-time user/password credentials in azure_entra_id mode are never used at runtime - they only exist so nao sync can read schema metadata and query history. If your security policy forbids any service-account access, leave them unset and provide warehouse metadata through another sync source.

​
Other warehouses

BigQuery, Snowflake, Databricks, and other warehouses also support identity-federated auth. We add per-user identity passthrough on request as we see customer demand. Email claire@getnao.io with your warehouse + identity-provider combination and we’ll scope it for your deployment.