jordotech

Application-Level S3 Encryption: Technical Overview

Prepared for: EY Information Security Team Date: March 2026 Status: Proposed (LOE Review)

---

Executive Summary

jordotech

Design: Application-Level S3 Encryption for EY Environments

Generated by /office-hours on 2026-03-26 Branch: feature/ENG-857-no-celery Repo: Faction-V/gofigure_terraform Status: APPROVED Mode: Intrapreneurship

Problem Statement

jordotech

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.

---

jordotech

ENG-893: Per-Org S3 Access Isolation via Email Domain Verification

Problem

Capitol.ai is a multi-tenant platform where organizations share the same AWS infrastructure. A Capitol.ai admin can add themselves to any organization (e.g., EY) and gain full access to that org's S3 files — uploads, workflow files, and generated outputs. Client orgs need assurance that only users with verified email domains can access their data.

Strategy

We implement email-domain-scoped IAM role assumption — a belt-and-suspenders approach combining STS AssumeRole with explicit IAM Deny policies.

jordotech

ENG-857: Replacing Celery with Async Workers — Internal Briefing

Replacing Celery with Async Workers (ENG-857)

Branch: feature/ENG-857-no-celery (agentic-backend + terraform) Status: Deployed to HMG, ready for load testing

Pull Requests

• App: https://github.com/Faction-V/agentic-backend/pull/410

jordotech

Should skills/ Live in a Separate Repo?

TL;DR: The skills/ directory is 3.6MB / 282 files — smaller than a single retina screenshot. Splitting it into a separate repo adds real operational complexity to solve a non-problem, and partially reintroduces the version-coupling failures that caused the outages we're trying to fix.

---

Actual Size of skills/

Total: 3.6 MB, 282 files

jordotech

RFC: Git-Tracked Claude Skill Management

Team: Agentic Backend Author: Engineering Date: 2026-03-07 Status: Implementation planned — [plan at docs/plans/2026-03-07-cli-skill-management.md]

---

Problem

jordotech

Multi-Regional Deployment: EY SSO Region Redirect

What Are We Building?

EY has 3 regional deployments, each with its own frontend and backend:

Region	Frontend	Backend
US (us-east-2)	platform-ey-us-east-2.capitol.ai	US backend
EU (eu-west-1)	platform-ey-eu-west-1.capitol.ai	EU backend

jordotech

Agentic-Backend PR Comparison: #363 vs #362

PR #363 (sso_user_id_updates by CapitolCoder) — 527 additions, 8 deletions, 3 files PR #362 (feature/COM-18-ad-phase-1 by jordotech) — 8 additions, 1 deletion, 1 file

Both PRs add Authorization: Bearer header support to get_current_user() so SSO users can authenticate with agentic-backend.

Diff Comparison

| Aspect | PR #363 | PR #362 (ours) |

jordotech

Platform-API PR Comparison: #365 vs #363

PR #365 (sso_user_id_updates by CapitolCoder) — 3,143 additions, 80 deletions, 16 files PR #363 (feature/COM-18-ad-phase-1 by jordotech) — 3,124 additions, 264 deletions, 22 files

Both PRs target the same goal: make platform-api Auth0-aware so SSO users get proper UUIDs instead of Auth0 sub strings.

Scope Comparison

| Aspect | PR #365 | PR #363 |