# AEGIS CYBER — Outstanding Integration Work: Phased Build Plan

**Date:** 2026-06-02
**Purpose:** scope the work required to close the gap between the platform's *narrow* pilot/sandbox readiness (capability demonstration on simulated state) and *broad* readiness (live integration into a bank's production environment), so the operator can authorize a specific, honestly-bounded phase rather than a blanket "build everything."
**Companion document:** `docs/AEGIS_CYBER_API_INTEGRATION_GUIDE.md` (Part 6 enumerates the same gaps from the code side). Every claim below was re-verified against the codebase on the date above.

---

## 0. The framing this plan exists to fix

"Pilot-ready" and "sandbox-ready" each have two readings, and the gap between them is the substance of the operator's concern:

- **Narrow** — the platform runs in a controlled evaluation environment, exercising **real** functionality (KYT scoring, session/RBAC/CSRF auth, WebSocket push, webhook + SIEM outbound, the OpenAPI/trust surfaces) while CBS workflows are demonstrable end-to-end **on simulated state**. The bank evaluates analytical capability. **The platform supports this reading today.** The production-grade tenant-isolation substrate (Phase 1) is **COMPLETE IN PROD** as of 2026-06-07: 69-table RLS with 16/16 functional verification, session-derived authorization-bound tenant-resolution (x-tenant-id removed), and PII field-level encryption across 17 tables.
- **Broad** — the platform is wired into a bank's live core banking system, with real machine-to-machine auth, real regulator transmission, and production-grade tenant isolation. **The platform does not support this reading today.** This plan is the path to it.

This plan must never be used to produce "complete-looking" stubs that recreate the simulation-vs-real gap one layer deeper. Each phase states explicitly which reading it satisfies when it closes.

---

## 1. Buildability classification of every outstanding item

### (a) Agent-buildable alone — no external dependency beyond operator runbook execution for prod SQL

| Item | What it is | Current state (verified) |
|---|---|---|
| **§8.1/§8.2 tenant-isolation arc** (T001 → T002 → T002.5 → T003 → T004a → T004b → T005) | RLS over a functional GUC writer + per-column PII encryption. The production-grade isolation **foundation**. | **COMPLETE IN PROD 2026-06-07.** All seven tasks closed in prod: GUC writer (T001), storage audit + 105-(d)-sink remediation (T002), x-tenant-id IDOR removal + session-derived tenant-resolution (T002.5), 69-table RLS 16/16 prod-verified (T003), PII encryption 40 AES-GCM + 2 HMAC columns across 17 tables (T004a), 22-row in-place migration gate:CLEAN (T004b), dossier reconciliation (T005). |
| **Mount `apiKeyAuth` on bank-facing routes** | Enforce the existing DB-backed machine credential (`server/lib/api-key-auth.ts`). | Middleware exists and is real (SHA-256, `aegis_<64hex>`), but has **zero mount/usage sites** — not enforced anywhere. |
| **CBS workflow durable state** | Move the CBS gateway's in-memory `Map`s (two-phase-commit logs, kill-switches, account-status cache) into the database. | Confirmed: 4 in-memory `Map`s in `core-banking-gateway.ts`; all state lost on restart. |

### (b) Buildable only with specific external inputs

| Item | What it is | What's needed, from whom |
|---|---|---|
| **Real CBS provider clients** | Replace `simulateCBSCall()` with actual Finacle / Flexcube / T24 HTTP clients (request/response mapping per provider). | Vendor API documentation or sandbox credentials for the **specific** CBS the partner bank runs. Cannot be built against guessed specs without recreating the simulation gap. |
| **mTLS + OAuth2 wiring to CBS** | Load client certs, acquire OAuth2 tokens. Config *shape* exists; nothing loads certs or fetches tokens. | mTLS certificates and OAuth2 client credentials provisioned by **bank IT**. |
| **Machine credential via mTLS client-cert** (alternative to apiKeyAuth for bank↔AEGIS) | Verify bank's client certificate at the route boundary. | Cert provisioning (bank IT) — same dependency as above. |

### (c) Blocked on business / legal / regulatory work outside engineering

| Item | What it is | Blocker |
|---|---|---|
| **Live regulator transmission** (SAR/CTR → FIA, SupTech → BoU) | Replace the internal status transition (`submitSARToFIA` just sets `status="SUBMITTED"`) with real submission to the regulator's endpoint. | FIA / BoU API access, credentials, and submission-protocol accreditation. Typically requires regulatory onboarding, not just engineering. |

---

## 2. Sequencing dependencies (the advisor's specific questions, answered)

1. **Does `apiKeyAuth` wiring need T002.5 to close first?** — **Yes — and T002.5 is CLOSED IN PROD (2026-06-03).** The original dependency is resolved: `x-tenant-id` has been removed from the middleware; tenant context is session-derived and authorization-bound via `user_tenant_roles`. `apiKeyAuth` wiring (Phase 2) is **unblocked** on this dependency. `req.apiKeyAuth.tenantId` will bind to a trustworthy substrate when mounted.
2. **Does CBS durable-state work depend on T003 RLS?** — **Yes.** Moving CBS state into the database creates new tenant-relevant tables. Without T003's RLS substrate they would be a fresh isolation gap. Build CBS durable state **after T003**.
3. **Does the §8.1/§8.2 arc need to close before integration plumbing can claim production-grade?** — **Yes.** Production-grade tenant isolation is the foundation; machine auth and CBS plumbing built on an un-isolated substrate cannot honestly claim production-grade. The arc is Phase 1 for exactly this reason.
4. **Do CBS provider clients / regulator transmission depend on the arc?** — Not technically blocked by it, but they are **(b)/(c)** items blocked on external inputs regardless, so they sit in later phases by necessity, not just sequencing.

---

## 3. Phased build plan

### Phase 1 — Production-grade tenant-isolation foundation  *(COMPLETE IN PROD — 2026-06-07)*
The §8.1/§8.2 arc, T001 → T002 → T002.5 → T003 → T004a → T004b → T005 — all seven tasks closed in prod.
- **What landed:** GUC writer (pinned-client + explicit-transaction, T001); storage audit + 105-(d)-sink remediation (T002); x-tenant-id IDOR removal + session-derived tenant-resolution + `user_tenant_roles` + `utr_primary_per_user` partial unique index (T002.5); 69-table RLS USING+WITH CHECK, 16/16 prod-functional-verification (T003); PII field-level encryption 40 AES-GCM + 2 HMAC-lookup columns across 17 tables (T004a); 22-row in-place migration gate:CLEAN (T004b); dossier reconciliation (T005).
- **Readiness achieved:** **narrow** pilot/sandbox readiness now rests on a *trustworthy* isolation substrate (RLS-enforced multi-tenancy + session-derived authorization-bound tenant-resolution + customer-PII encryption). Does **not** make CBS or regulator transmission live. **Phase 2 is now unblocked.**

### Phase 2 — Machine auth + CBS durable state  *(agent-buildable; sits on Phase 1)*
- Mount `apiKeyAuth` on bank-facing routes (after T002.5, so the credential binds to an authorization-bound tenant).
- Move CBS in-memory `Map`s → database (after T003, so the new tenant-scoped tables inherit RLS).
- **Rule cascade:** Rule 9 architect review (auth + multi-tenant isolation surfaces); Rule 2 Phase 2.A for the new schema; Rule 7 dual-environment; Rule 13 publish on completion.
- **Readiness after this phase:** machine-to-machine credential **enforced**; CBS workflow state durable and auditable. CBS *calls remain simulated*. **Narrow** readiness materially strengthened; still not broad.

### Phase 3 — Live CBS integration  *(blocked on vendor input — (b))*
- Real provider clients + mTLS + OAuth2, replacing `simulateCBSCall`.
- **Requires:** vendor API docs / sandbox credentials for the partner bank's specific CBS, and mTLS certs from bank IT.
- **Agent can do now without those inputs:** define the provider-adapter interface and a clearly-labeled "vendor-doc-ready" boundary — **not** a fake client. Real client construction waits on docs.
- **Readiness after this phase:** **broad** readiness for the CBS control surface (live freeze/hold/reverse against a real core).

### Phase 4 — Live regulator transmission  *(blocked on regulatory accreditation — (c))*
- Wire `submitSARToFIA` / SupTech push to real FIA / BoU endpoints.
- **Requires:** regulator API access, credentials, accreditation (business/legal).
- **Readiness after this phase:** **broad** readiness for regulatory filing (live SAR/CTR transmission).

---

## 4. Recommendation

**Phase 1 is COMPLETE IN PROD (2026-06-07).** The foundation is in place: trustworthy multi-tenant isolation (69-table RLS 16/16 prod-verified), session-derived authorization-bound tenant-resolution (x-tenant-id removed), and customer-PII field-level encryption (40 AES-GCM + 2 HMAC columns across 17 tables). Narrow pilot/sandbox readiness rests on a substantive substrate, not a documented-gap framing.

**Phase 2 is now unblocked** — both sequencing dependencies from §2 items 1–3 are resolved (T002.5 closed; T003 substrate in place for CBS durable-state tables). Phase 2 requires explicit operator authorization before any work begins.

Phases 3 and 4 remain blocked on external inputs (vendor docs/certs for CBS; regulator API access + accreditation); those constraints are unchanged by Phase 1 completion.