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.
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
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
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.)
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
- 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
- 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
| 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.
Enabling access control for an organization requires:
- Define allowed email domains — e.g.,
["ey.com"] - Create scoped credentials — limited to only that organization's data
- 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.
| 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.