Skip to content

Instantly share code, notes, and snippets.

@jordotech
Created March 25, 2026 17:21
Show Gist options
  • Select an option

  • Save jordotech/a0a5d0a6145b8cabfaf25c04f261823e to your computer and use it in GitHub Desktop.

Select an option

Save jordotech/a0a5d0a6145b8cabfaf25c04f261823e to your computer and use it in GitHub Desktop.
Capitol AI — Data Access Controls for Customer Organizations

Capitol AI — Data Access Controls for Customer Organizations

Overview

Capitol AI has implemented platform-level access control that restricts who can view and download an organization's files. Access is determined by the user's verified email domain — only users with authorized email addresses (e.g., @ey.com) can access the organization's data, even if other users have platform administrator privileges.

This control works alongside the existing External Key Management (EKM) encryption to provide multiple independent layers of data protection.


How It Works

When a user requests a file from a protected organization, the platform checks their email address:

flowchart TD
    A[User requests file from Organization X] --> B{Is user's email domain\nin org's allowed list?}
    B -->|Yes\ne.g. user@ey.com| C[Platform assumes\norg-specific credentials]
    B -->|No\ne.g. admin@capitol.ai| D[Platform uses\ndefault credentials]
    C --> E[Access Granted\nFile returned to user]
    D --> F[Access Denied\nBlocked by security policy]

    style E fill:#2d8659,color:#fff
    style F fill:#c0392b,color:#fff
Loading

Key points:

  • Each protected organization is configured with a list of allowed email domains (e.g., ey.com)
  • Users with matching email domains receive credentials scoped specifically to that organization's data
  • Users with non-matching domains are blocked by a security policy — this is enforced at the infrastructure level, not just in application code
  • Denied access attempts are logged and tracked

What This Protects Against

A Capitol AI platform administrator who adds themselves to a customer organization cannot access that organization's files through the platform. The security policy blocks the request regardless of the user's role or permissions within the platform.

This applies to:

  • Document uploads (collections and data sources)
  • Workflow input files
  • Generated outputs (documents, charts, presentations, etc.)

Relationship to External Key Management (EKM)

Capitol AI's data protection operates on two independent layers:

flowchart LR
    subgraph Layer1["Layer 1: Encryption (EKM)"]
        direction TB
        S3[Data Storage] -->|encrypted with| KMS[AWS Key Service]
        KMS -->|key managed by| AKV[Customer's\nAzure Key Vault]
    end

    subgraph Layer2["Layer 2: Access Control"]
        direction TB
        User[User Request] -->|email verified| App[Capitol Platform]
        App -->|scoped credentials| Data[Organization Data]
    end

    style Layer1 fill:#e8f0fe,stroke:#4285f4
    style Layer2 fill:#fef7e0,stroke:#f9ab00
Loading

Layer 1: Encryption at Rest (EKM) — Already deployed

  • All data is encrypted using a key that lives in the customer's Azure Key Vault
  • The key material never leaves Azure — Capitol AI and AWS never have access to the raw key
  • Customer controls:
    • Revoke the key at any time to instantly make all data unreadable
    • View audit logs of every time the application accesses the key
    • Full ownership of the encryption key lifecycle

Layer 2: Platform Access Control — Newly implemented

  • Controls which authenticated users can access organization data through the Capitol AI platform
  • Based on verified email domain matching
  • Enforced by infrastructure-level security policies (not just application logic)
  • Operates independently of the encryption layer

How They Work Together

Threat EKM (Encryption) Access Control
Cloud provider reads stored data Protected
Platform admin accesses data via the app Protected
Customer wants to revoke all data access Protected (key revocation)
Unauthorized user added to customer org Protected

Each layer addresses different threat vectors. Together, they ensure that customer data is both encrypted with customer-controlled keys and access-restricted to authorized personnel only.


Configuration

Enabling access control for an organization requires:

  1. Define allowed email domains — e.g., ["ey.com"]
  2. Create scoped credentials — limited to only that organization's data
  3. Deploy security policies — infrastructure-level deny rules applied to default credentials

No application code changes are required per organization. The control is entirely configuration-driven.


Summary

Control What It Does Who Controls It
EKM (Encryption) Encrypts all data with a key in Azure Key Vault Customer owns the key
Platform Access Control Restricts file access to verified email domains Capitol AI configures per org

Both controls are active and independent — disabling one does not affect the other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment