# AEGIS CYBER — Bank Presentation Briefing & Engineering Onboarding

**Date:** 1 June 2026
**Purpose:** (1) source material for a bank presentation on platform capacity, functionality, and competitive moat; (2) an onboarding pack you can share with the software engineer joining the team.
**Discipline:** This document follows the platform's standing "realistic-not-aspirational" rule. Every capability below is labelled by maturity so nobody in the room states something the bank's own technical team could later disprove. Overclaiming to a regulator-facing institution is the one mistake that costs trust permanently.

---

## How to read this document — calibration key

- 🟢 **Live today** — implemented and exercised in the running platform on real or genuinely-computed data.
- 🟡 **Simulation / pilot** — implemented and demonstrable, but running on simulated, seeded, or unmeasured data, or integration-ready but not yet wired to a live external system.
- 🔵 **In-flight** — active engineering right now; not yet something to claim as done.

---

# PART 1 — For the bank presentation

## 1.1 What AEGIS CYBER is (positioning)

AEGIS CYBER is an agentic-AI cybersecurity and compliance platform purpose-built for African banking infrastructure, starting with Uganda. It acts as a "cognitive security layer" over a bank's transactions, employee behaviour, and regulatory obligations — combining transaction risk scoring (KYT), insider-threat / behavioural monitoring, tamper-evident audit provenance, and Uganda PDPO-2019-native data-rights workflows, in a package designed to run **inside the bank's own infrastructure** (on-prem / air-gap capable) rather than depending on foreign cloud.

The differentiator is not "more features than a global vendor" — it is **sovereignty, regulator-verifiability, and local-law-native design**, backed by a disciplined, evidence-based governance process.

## 1.2 Platform capabilities (calibrated)

### Threat & transaction monitoring
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| KYT (Know-Your-Transaction) rules engine | 🟢 | Weighted, rule-based transaction risk scoring; rules externalised to a validated JSON file with a ~30-second hot-reload poller (tune rules without a restart). |
| AI threat scoring (Anthropic Claude) | 🟡 | Genuinely wired to Anthropic; produces real model output when the integration is active. Scoring quality is **not yet benchmarked** against labelled bank data. |
| Behavioural / Bio-Vault (insider threat) | 🟡 | Interaction-pattern (typing/behaviour) analysis against baselines; baselines are currently **seeded demo profiles**, not learned from real staff. |
| SOAR automated response playbooks | 🟢 | Automated response logic (e.g. session freeze on critical threat) wired and reachable. |

### Governance, audit & access control
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| Tamper-evident audit chain | 🟢 | Every administrative/security action written to a SHA-256 hash-chained log; chain is genuinely computed and verifiable against the database. |
| Secret boot-guard (fail-closed) | 🟢 | App refuses to start if any required signing/encryption secret is missing or under-length (12+ secrets at last count). |
| Role-based access control (RBAC) | 🟢 | Admin / Risk-Manager / Auditor roles enforced by middleware across the API surface. |
| Standing governance framework | 🟢 | A formal set of engineering rules with dated artefacts (architect review, schema-deploy discipline, no-secrets-in-logs, etc.) — see §1.3, this is itself part of the moat. |

### Compliance & data rights
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| DSAR / erasure engine (PDPO-2019) | 🟢 | Data-subject access/erasure workflow creates real records and runs a scheduled purge worker with SLA tracking. |
| Regulator Gateway (SupTech / SAR) | 🟢 | Endpoints for BoU/NITA-U reporting and audit-ready exports. |
| Data-sovereignty / residency monitor | 🟡 | Rule engine flags residency of data it is given (e.g. UG vs non-UG); it does **not** inspect live network traffic. |

### Supply-chain & posture
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| SBOM / AI Bill of Materials (A-BOM) | 🟢 | Reads the real dependency manifest; inventories libraries, models, and data sources. |
| End-of-life dependency check | 🟢 | Queries the live `endoflife.date` service. |
| Vulnerability scanner | 🟡 | Makes real calls to the OSV vulnerability API; falls back to seeded fixtures if the call fails. |

### Regulator-facing trust artifacts
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| Signed Pilot-Pack bundle | 🟢 | Downloadable, cryptographically-signed evidence bundle; the issued bundle is immutable. |
| Public Bundle Verifier + Public Status page | 🟢 | Independent verification surfaces a regulator can use without logging in. |
| Examiner-token substrate | 🟢 | Read-only supervisory access tokens for post-hoc regulator verification. |

### Deployment
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| On-prem Docker packaging | 🟡 | Multi-stage Docker build verified on a laptop (image provenance, boot-guard, bind-mounts). **Not yet deployed to a bank production environment** — that is the pilot ask. |

### Data protection & multi-tenant isolation — read this section carefully
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| Field-level encryption engine (AES-256-GCM) | 🟢 | Live and protecting **secrets/credentials, MFA seeds, integration keys** today. |
| Customer-PII field encryption (names, IDs, DOBs) | 🔵 | The encryption engine exists and is NIST-grade, but it is **not yet wired into the ~17 customer-PII tables** — those columns are currently plaintext. Active engineering. |
| Application-layer tenant isolation | 🟢 | `tenant_id` on ~70 tables with application-layer filtering, plus a newly-landed request-scoped database-session writer that is the foundation for database-enforced isolation. |
| Database-layer Row-Level Security (RLS) | 🔵 | **Zero RLS policies are attached today.** Isolation is enforced at the application layer, not yet by the database. Active engineering. |
| Hardware Security Module (HSM) | 🟡 | The HSM layer is a **software simulation** designed to plug into real hardware (AWS Nitro / ARM TrustZone) in production. Not deployed hardware. |

### Sovereign edge architecture
| Capability | Status | Honest description |
| :--- | :--- | :--- |
| Six-node East-African edge, SIM-swap detection, offline transactions | 🟡 / 🔵 | Designed and code-scaffolded; currently driven by **synthetic statistics** with telco/offline runtime not yet wired. Roadmap, not live. |

## 1.3 The moat — why AEGIS CYBER, here, now

1. **Sovereignty by design.** Built to run inside the bank's own (or nationally-controlled) infrastructure, on-prem and air-gap capable — directly answering the cloud-exit and data-residency risk that global vendors struggle with in this market.
2. **Regulator-in-the-loop, and verifiable.** Signed evidence bundles, an independent public verifier, and read-only examiner tokens let the Bank of Uganda verify posture *after the fact* without invasive live access. This is a structurally different (and more palatable) supervision model.
3. **Tamper-evident provenance.** A SHA-256 hash-chained ledger of every security/admin action — a high-trust substrate for both internal audit and regulator review.
4. **Local-law-native.** PDPO-2019 / DPPA data-rights workflows are first-class, not retrofitted onto a foreign compliance framework.
5. **Governance discipline as a trust signal.** Security posture is maintained as a *tracked process with dated artefacts and an explicit "realistic-not-aspirational" rule* — exactly the maturity a regulator and a bank CISO want to see, and something most early-stage vendors cannot show.
6. **African-context threat intelligence + edge roadmap.** Feeds and an edge architecture oriented to the regional threat and connectivity reality.

## 1.4 Honesty guardrails — what NOT to say in the room

If the bank's technical team probes, these claims must be stated in their honest form. Saying the left-hand version is the one thing that can sink credibility:

*Updated 2026-06-08 — two rows corrected to reflect engineering closures.*

| ❌ Do not say | ✅ Say instead |
| :--- | :--- |
| ~~"Customer PII is encrypted at rest."~~ → **Now true for new writes.** | "AES-256-GCM field encryption is live across all 17 customer-PII tables (45 columns: 40 AES-GCM + 2 HMAC-lookup + 3 out-of-scope), prod-verified 2026-06-08. Legacy rows (existing data before this workstream) are scheduled for migration — that is the one remaining item." |
| ~~"Multi-tenant isolation is database-enforced."~~ → **Now true.** | "Tenant isolation is enforced at both the application layer and the database layer — 70 tables carry PostgreSQL Row-Level Security policies, functionally verified in production 2026-06-04 with 17/17 probe classes passing." |
| "We use a hardware HSM." | "The HSM layer is integration-ready and runs in simulation; it targets real hardware enclaves in production deployment. The substitution boundary is documented." |
| "We run live across six edge nodes." | "The six-node sovereign edge is designed and scaffolded; it's on the deployment roadmap." |
| "We block fraudulent transactions in real time." | "We score and flag transactions and can trigger automated response; live in-line blocking of bank transactions is a pilot-integration item." |
| "AI scoring is proven accurate." | "AI scoring is wired and operational; accuracy benchmarking against the bank's labelled data is part of the pilot." |
| "All historical data is encrypted." | "New writes are encrypted end-to-end across all 17 PII tables. Existing rows from before the encryption workstream are plaintext — the migration is the next engineering item." |

**The strongest move with a bank is to lead with what is genuinely live (audit chain, KYT, DSAR, database-layer RLS, new-write PII encryption, signed verifiable evidence, on-prem packaging, governance discipline) and name the one outstanding item (legacy-row migration) honestly.** A bank CISO trusts a vendor who names its gaps far more than one who claims perfection.

---

# PART 2 — For your software engineer (onboarding pack)

This is the candid internal view. Share it freely with your engineer — it will stop *him* from accidentally overclaiming to the bank too.

## 2.1 Documents to hand him first

All under `docs/regulatory/` plus the project README:
- `replit.md` — architecture overview and the standing-rules pointer index.
- `docs/regulatory/STANDING_AGENT_RULES.md` — the full governance rules (read before touching security code).
- `docs/regulatory/AEGIS_CYBER_SECURITY_DOSSIER_FOR_BOU_2026-05-23.md` — the calibrated capability evidence dossier.
- `docs/regulatory/AEGIS_CYBER_DOSSIER_RECONCILIATION_MEMO_2026-05-28.md` — the honest gap register (§8.1 RLS, §8.2 PII encryption).
- `docs/regulatory/BUILD_PRIORITY_LIST.md` — the working build order.
- `docs/regulatory/FOLLOW-UPS.md` — the engineering history / FU register (source of truth for decisions).

## 2.2 Architecture & stack

- **Backend:** Node.js 20+ / Express 5 (TypeScript), RESTful API + WebSocket server for real-time updates.
- **Frontend:** React 18 + TypeScript, Wouter routing, TanStack React Query, Tailwind + shadcn/ui, Framer Motion.
- **Database:** PostgreSQL via Drizzle ORM; sessions via `express-session` + `connect-pg-simple`.
- **AI:** Anthropic Claude via the configured integration.
- **Security libs:** `bcryptjs`, `helmet`, token-based CSRF, FIDO2/passkey support, a boot-time secret guard.
- **Shared types:** data model lives in `shared/` schema files; keep frontend/backend in sync there first.

## 2.3 The tri-environment model (critical to understand)

The platform targets **three environments** and changes must preserve all three unless explicitly scoped to one:
1. **Replit dev** — where code is built and reviewed.
2. **Docker laptop** — the on-prem package, verified standalone.
3. **Bank production** — the eventual pilot target.

Schema changes do **not** auto-deploy — `db:push` only touches dev; production schema changes go through an explicit operator runbook. He must internalise this before any schema work.

## 2.4 The real-vs-simulated boundary (most important thing for him)

*Updated 2026-06-08 to reflect engineering closures since this document was first written (2026-06-01).*

| Genuinely live | Simulated / seeded | Outstanding |
| :--- | :--- | :--- |
| Audit hash-chain, secret boot-guard (15 secrets), RBAC, DSAR engine + purge worker, KYT rules engine + hot-reload, SBOM/A-BOM, EOL check, signed pilot-pack + public verifier, field-encryption for secrets, **database-layer RLS (70 tables, 17/17 prod-verified, 2026-06-04)**, **customer-PII field encryption (17 tables / 45 columns: 40 AES-GCM + 2 HMAC-lookup + 3 out-of-scope, 20/20 prod-verified, 2026-06-08)**, **CBS route Zod validation (all 7 routes, 2026-06-08)**, **schema-conformance boot assertion (118 columns, 2026-06-04)** | HSM enclave (software stub), behavioural baselines (seeded), sovereignty monitor (rule engine, no live traffic), edge/SIM-swap/offline (synthetic stats), vuln scanner fallback fixtures, DR failover (in-memory simulation — streaming replication not configured) | Existing-row PII encryption migration (T004b — new writes encrypt correctly; legacy rows not yet migrated), AI scoring benchmarking against labelled bank data, bank-prod on-prem deployment |

## 2.5 The engineering arc — what closed and what remains

The FU-052 §8.1/§8.2 remediation arc **is now complete for new writes.** Two items that were "in-flight" at the time this document was first written have since been prod-verified:

1. **Database-layer RLS — CLOSED IN PROD 2026-06-04.** 70 tenant-scoped tables carry `ENABLE ROW LEVEL SECURITY` with `USING (tenant_id = current_tenant_id())` + `WITH CHECK` predicates, enforced against the restricted `aegis_app` role. 17/17 diagnostic probe classes PASS in production. The boot sequence fails fast if any predicate is wrong (Rule 14). This was not a claim at this document's issue date — it is now substantiated.

2. **Customer-PII field encryption — CLOSED IN PROD 2026-06-08.** All 17 PII tables (45 columns: 40 AES-GCM + 2 HMAC-lookup + 3 out-of-scope) have AES-256-GCM encryption wired on new writes, confirmed by a 20/20 in-container probe (ENC-PROBE-1780939715886). Two treatments per column: encrypt-at-rest for non-lookup fields; HMAC-derived lookup key + encrypted blob for equality-lookup fields (national IDs, emails used in WHERE clauses). This was also not a claim at this document's issue date — it is now substantiated.

**Outstanding from the arc:** Existing-row encryption migration (T004b) — the design brief exists (`docs/regulatory/T004B_DESIGN_BRIEF.md`) and this is the highest-risk remaining operation. New writes are correctly encrypted; legacy plaintext rows in the 17 PII tables have not yet been migrated. This must be named honestly if asked.

## 2.6 The governance rules he must work within

The non-negotiables (full text in `STANDING_AGENT_RULES.md`):
- **Rule 1 — never print/echo secret values** anywhere, even for debugging.
- **Rule 2 — schema changes go through an explicit prod runbook**, never auto-deploy.
- **Rule 5 — realistic-not-aspirational** in every artefact and claim.
- **Rule 6 — verify before asserting completion** (build/test/probe evidence, not intent).
- **Rule 7 — preserve all three environments** on any change.
- **Rule 9 — architect review** is mandatory before committing changes to auth, sessions, audit chain, encryption keys, multi-tenant isolation, or KYT detection code.

## 2.7 Running it & where code lives

- Single dev workflow: `npm run dev` (Express + Vite on one port).
- Backend route surface: `server/routes.ts`; domain logic under `server/lib/`.
- Frontend pages: `client/src/pages/`, registered in `client/src/App.tsx` (60+ routes).
- Shared data model: `shared/` schema files — start here for any model change.
- Do **not** edit `package.json`, lockfiles, `vite.config.ts`, `drizzle.config.ts`, or `tsconfig*` without explicit authorisation (forbidden-files rule).

## 2.8 Secret-handling note (share this explicitly)

Do **not** send him any secret *values* (API keys, signing secrets, DB credentials) over chat/email. Secrets are managed in the platform's secret store; he gets access to the store, not pasted values. This is Rule 1 and it is the kind of discipline the bank will expect to see.

## 2.9 Known gaps / honest backlog (so he isn't surprised)

*Updated 2026-06-08 — two items from the original list have now closed; remaining gaps are honest.*

- ~~Database-layer RLS not yet attached~~ — **CLOSED IN PROD 2026-06-04.** 70 tables, 17/17 prod-verified.
- ~~Customer-PII columns not yet encrypted~~ — **CLOSED IN PROD 2026-06-08** for new writes. 17 tables / 45 columns (40 AES-GCM + 2 HMAC-lookup + 3 out-of-scope), 20/20 prod-verified. Legacy-row migration (T004b) is the remaining operation.
- **Existing-row PII encryption migration (T004b)** — new writes encrypt correctly; legacy plaintext rows in 17 PII tables not yet migrated. Highest-risk future operation. Design brief at `docs/regulatory/T004B_DESIGN_BRIEF.md`.
- **HSM is a simulation** — software stub. Real hardware hookup is a future integration item. See `docs/regulatory/AEGIS_CYBER_HSM_BOUNDARY_SPEC.md`.
- **Edge / SIM-swap / offline run on synthetic data** — unchanged. Roadmap, not live.
- **DR failover is in-memory simulation** — streaming replication to Entebbe standby not configured. Runbook at `docs/regulatory/AEGIS_CYBER_DR_EXERCISE_RUNBOOK.md`.
- **AI scoring not yet benchmarked** against labelled bank data.
- **No bank-prod deployment yet** — Docker packaging verified; bank-IT hookup is the pilot ask.
- **Dev-UI login** — known parked credentials item. Does not block code/DB work.

---

# PART 3 — Suggested presentation flow (optional)

1. **The problem** — financial-crime + insider risk + data-protection obligations in African banking, with a sovereignty/cloud-exit angle.
2. **What AEGIS is** — the cognitive security layer, on-prem, regulator-verifiable.
3. **Live demo of the real stuff** — KYT scoring, the tamper-evident audit chain, the DSAR workflow, and the signed pilot-pack + public verifier (your strongest, fully-honest assets).
4. **The moat** — §1.3, especially regulator-in-the-loop verifiability and governance discipline.
5. **The honest roadmap** — isolation hardening and PII encryption for new writes are both now prod-verified and closed. The remaining open item is the existing-row PII migration (T004b); on-prem-to-pilot deployment is the ask.
6. **The ask** — a scoped pilot inside the bank's environment, with success criteria (incl. AI-scoring benchmarking on their data).

*Leading with the live capabilities (both RLS and PII encryption are now prod-verified), naming the one remaining item (T004b existing-row migration) honestly, and framing the pilot as the next step is the credibility-maximising structure — and it is exactly what the platform's own governance discipline is built to support.*