Security you can verify, stated only as far as the record supports it

AWS infrastructure — SOC 2 Type II inherited

Kaia runs on AWS (RDS, S3, SES, Bedrock). The physical, network, and host infrastructure layer is covered by AWS’s own SOC 2 Type II attestation under the shared-responsibility model, which narrows Kaia’s own audit scope to the application controls we operate — the inventory on this page.

Application controls — enforced in code, self-assessed

13 application controls are designed and operating today, each backed by live enforcement in the platform (database-level tenant isolation, append-only audit trail, role gating, regulated-decision floors). “Designed & operating” is our self-assessment from that live evidence — independent verification of operating effectiveness comes only from a third-party audit.

Independent attestation — in progress, not held

Kaia holds no completed independent attestation today. The launch path: a SOC 2 Type I (point-in-time design assessment) as the entry credential, with the SOC 2 Type II observation window opening at go-live. Until a report is issued, no Kaia surface will imply one exists — this row is generated from the same open gap the product discloses to clients.

Tenant data isolation enforced in the database, not the application

Every row of tenant data is protected by PostgreSQL row-level security. Isolation is enforced by the database itself, so an application bug cannot read across tenants — the query returns nothing rather than someone else’s data.

• RLS is ENABLEd and per-tenant policies are created on the tenant-scoped tables (15 ENABLE/POLICY statements).
• The tenant context is bound to the database session inside the transaction (DR-094) — the request path never runs a bare $transaction.
• Every organization-scoped API call resolves its scope against the authenticated workspace and refuses a mismatch.

Least-privilege role gating on every protected operation

Access is granted by professional role, checked on every call. A user who does not hold the capability cannot invoke the operation — the refusal happens server-side, not by hiding a button.

• The permission check runs server-side on every gated procedure and returns FORBIDDEN when the role lacks the capability.

Your half: You decide which of your people hold which role, and you review those assignments on your own cycle. Kaia enforces the boundary; only you know who should be inside it.

Machine credentials cannot escalate to human authority

An API key carries only the narrow scopes it was issued for. Administrative, settings and correction capabilities are not derivable from any key — the escalation path does not exist rather than being blocked.

• The key→permission map grants document-pipeline permissions only; no settings, team, correction or engine permission is reachable from a key.

The audit trail is immutable at the database level

Audit records cannot be updated or deleted. The prohibition is a database trigger, so it holds even against a privileged connection running raw SQL — the audit trail cannot be quietly rewritten by anyone, including Kaia.

• A BEFORE UPDATE OR DELETE trigger on "AuditLog" raises an exception — append-only enforced in the database, not in application code.
• The audit record carries actor, action, resource, before/after state and context.

Compliance state and its audit trail cannot drift apart

Your checklist state is not a table that an audit log describes — it IS a projection over the audit rows. There is no second store to reconcile, so "what did the record say at the time?" and "what does the system say now?" cannot disagree.

• Current checklist state is computed as a latest-per-item projection over appended AuditLog rows.
• A status change is written as an appended audit row — the write IS the audit.

Audit-record retention classes and archival enforcement

Every audit record is classified by retention regime at write time (7 years for corrections and documents, 10 for cross-tenant admin access, 3 for AI outputs, with regulated-regime floors), and a scheduled monthly sweep archives records past their retention floor to cold storage — recording each enforcement run as auditable evidence in the affected organization’s own trail. Records are append-only and are never deleted: the designed deletion path requires dual approval and is deliberately not built, so the retention floor can never be undercut.

• The retention policy: regime class derived from the regulated vertical, minimum-retain-until from the event schedule with regulated-regime floors — a record the policy cannot classify retains at the LONGEST general floor, never a shorter guess.
• The shared audit write path stamps retentionClass and minRetainUntil on every row it creates — classification happens where the record is born.
• The enforcement sweep: expired, non-legal-hold records are bundled to the cold-storage prefix per organization, and each run writes an enforcement receipt (with its idempotence watermark) into the same append-only trail it enforces.
• The monthly scheduled executor binding for the sweep.
• The schedule, the regime floors, the fail-long default, and the write-path stamping are pinned by tests.
• The sweep’s selection shape, cold-storage bundle, enforcement receipt, legal-hold exclusion and watermark idempotence are pinned by tests.

Privileged cross-tenant administration is logged

Platform-operations actions on a client organization (such as an engagement-tier grant) write two audit records: one in the affected client’s own trail, and one in the platform organization’s trail naming the target, the acting administrator, and the written reason — retained for 10 years. Tenant isolation means no client session can ever act on another organization; this control evidences the one sanctioned exception.

• The platform-side record: every platform→tenant act writes a CrossTenantAccess row in the platform organization’s trail with the target organization, actor, reason, and seam — on the 10-year admin-access retention schedule.
• The tier-grant seam (the reference platform→tenant act) records its cross-tenant access after the SECURITY DEFINER grant writes the tenant-visible row.
• The grant path is pinned to write the platform-side record with the 10-year stamp — and to write NO record when the grant refuses.

Every mutating API procedure is audit-covered, machine-checked

A continuous gate enumerates every state-changing API procedure the platform serves and fails the build when one neither writes to the audit trail nor carries a written, reviewed exemption. Audit coverage can only be reduced deliberately, in a reviewed change — never by omission.

• The gate: live-router mutation enumeration cross-checked against each procedure’s source for a named audit write, with a staleness-checked exemption registry.

Regulated decisions cannot be automated past their statutory floor

Where the regulation requires a qualified human, the platform stops. A floor classification (attorney privilege, a qualified technical person’s sign-off) forces human review and cannot be waived by confidence, by mode, or by an operator in a hurry — the floor is declared in the vertical’s configuration and enforced on every agent turn.

• The regulated floor is declared per vertical in the config layer, never inline in the driver (DR-087).
• A floor release requires a named credentialed signer — the credential set is config, not code.
• The engine refuses to advance past a floor until the required signatures are recorded.

Regulatory snapshots are write-once

A recorded correction version is frozen. It cannot be updated or deleted — the electronic record an auditor reads is the record that was made, not a later edit of it.

• A BEFORE UPDATE OR DELETE trigger on "CorrectionVersion" raises an exception — write-once in the database (21 CFR Part 11 · FRCP 37(e)).

A document under legal hold cannot be destroyed

When a document is under legal hold, deletion is refused by the database. Spoliation is prevented structurally rather than by policy — the delete does not happen even if something tries.

• A BEFORE DELETE trigger on "Document" raises an exception while legalHold is true (FRCP 37(e)).

Evidence goes from your browser to your own storage path

Compliance evidence is uploaded on a short-lived signed URL, straight to a storage path keyed by your organization. The document does not pass through an application server, and the path of one tenant is not the path of another.

• The object key is prefixed `orgs/{organizationId}/compliance/...` and the URL is time-limited.

Transport encryption and browser security headers

All traffic is served over TLS, and the application declares its own browser-hardening policy on every route of both applications: HSTS (2-year, preload), X-Frame-Options, nosniff, referrer policy, a permissions policy, and a baseline Content-Security-Policy.

• The ONE shared header policy: Strict-Transport-Security (max-age 2 years, includeSubDomains, preload), X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy, Permissions-Policy, and the baseline CSP (frame-ancestors none, object-src none, form-action self, upgrade-insecure-requests).
• The product application (the tenant-facing portal) serves the shared policy on every route (DR-124).
• The public site serves the same policy on every route, with a single same-origin frame carve-out for the register-cockpit embed path — never widened beyond self. TLS itself is terminated by the hosting platform (an inherited sub-service control); HSTS pins every browser to it.

Kaia Legal

• FRCP Rule 26 (Discovery)
• FRCP Rule 34 (Production)
• FRCP Rule 37(e) (Spoliation)
• FRE Rule 502 (Privilege)
• FRE Rule 901 (Authentication)
• SOC 2 Type II
• Model Rules of Professional Conduct

Kaia Oil & Gas

• SEC Reg S-K Subpart 1200 (Items 1201-1208)
• Reg S-K 1202(a)(7) — Qualified Technical Person
• Reg S-K 1202(a)(8) — third-party reserves report
• Reg S-K 1203 — PUD narrative + the five-year rule
• SEC Release 33-8995 (Modernization of Oil and Gas Reporting)
• SOX §302 / §906 — CEO + CFO certifications
• FASB ASC 932 — Standardized Measure (SMOG)
• SEC Reg S-X 4-10 — full-cost ceiling test
• SPE-PRMS 2018 — Class × Category framework
• XBRL / EDGAR submission

Kaia Claims

• CMS (Centers for Medicare & Medicaid Services)
• HIPAA (EDI Transaction Standards)
• NAIC Model Bulletin (AI in Insurance)
• SOX (Sarbanes-Oxley Financial Controls)
• Prompt Payment Laws (State-Specific)
• False Claims Act
• SOC 2 Type II

Kaia Accounts Payable

• Segregation of duties — record ≠ authorize ≠ execute, human or agent
• ICFR — material coding + every override carries a human signature
• Sanctions screening incl. majority-ownership aggregation — human-only release
• Payment-fraud floors — two-person vendor creation, out-of-band bank-detail verification
• Delegation-of-authority bands — dual / triple sign-off on payment release
• Replayable, audit-defensible decision trace per payment cycle
• Sovereign single-tenant deployment — customer bank rails, no money custody

Kaia Health

• HIPAA (Health Insurance Portability and Accountability Act)
• COPPA (Children's Online Privacy Protection Act)
• FDA SaMD (Software as a Medical Device)
• 21st Century Cures Act (Interoperability)
• FHIR R4 (Interoperability Standard)
• SOC 2 Type II

Kaia Pharma

• 21 CFR Part 11 (Electronic Records and Signatures)
• ICH E2B(R3) (Electronic ICSR Transmission)
• GxP Validation (Computerized System Validation)
• FDA AI Credibility (Algorithmic Transparency)
• EU AI Act (High-Risk AI Systems)
• ALCOA+ (Data Integrity)
• SOC 2 Type II

Kaia Real Estate

• ASTM E1527-21 (Phase I Environmental Site Assessment)
• Fair Housing Act
• AML/BSA (Anti-Money Laundering)
• FinCEN CTA (Corporate Transparency Act)
• ALTA Standards (Title Insurance and Closing)
• SOC 2 Type II

Kaia HR

• NYC LL144 (Automated Employment Decision Tools)
• EEOC/ADA/ADEA (Anti-Discrimination)
• EU AI Act (High-Risk AI Systems)
• CO SB205 (Colorado AI Transparency)
• GDPR Article 22 (Automated Decision-Making)
• ERISA (Employee Retirement Income Security Act)
• SOC 2 Type II

Kaia Auto Loan

• ECOA/Reg B (Equal Credit Opportunity)
• TILA (Truth in Lending Act)
• FCRA (Fair Credit Reporting Act)
• CFPB AI Guidance (Fair Lending in AI)
• Fair Lending (Disparate Impact Analysis)
• MLA (Military Lending Act)
• SCRA (Servicemembers Civil Relief Act)
• SOC 2 Type II

Kaia Government

• FedRAMP (Federal Risk and Authorization Management)
• FISMA (Federal Information Security Modernization Act)
• Section 508 (Accessibility)
• NIST 800-53 (Security and Privacy Controls)
• State Data Residency Requirements
• FOIA (5 U.S.C. 552)
• SOC 2 Type II