Kaiko Studios · UAE
● Confidential — 2026
Data Privacy & Security
Customer-Controlled Deployment, Sovereignty Model & Shared Responsibility
Section 01
Executive Summary
Policy Observatory is designed for customer-controlled deployment. The platform supports topologies in which enterprise and government customers retain operational control of data, cryptographic keys, and network egress. For UAE government workloads, the reference posture is a sovereign deployment where data, keys, and operational state reside on customer-operated infrastructure in the UAE, and external integrations are controlled and allow-listed by the customer.
This document is written to pass technical due diligence, not to market. It distinguishes clearly between what the platform provides today, what can be configured for enterprise and sovereign deployments, and what the customer operates. Aspirational and forward-looking items are labelled as such.
MVP stack note. The current platform (the "MVP" maturity level defined in Section 02) relies on two external providers reached via allow-listed egress: Kimi K2.5 (Moonshot AI) for LLM inference and Brave Search for news and grounding data. Both can be substituted with customer-approved, in-jurisdiction alternatives. The swap is scoped during Discovery (Section 13, Phase 1) and adds development time proportional to the replacement chosen. Commercial terms, IP arrangement, and programme milestones are defined in the accompanying proposal document (KAIKO-IMPL-2026-001), not in this technical brief.
Customer
Key Custody
Allow-Listed
Egress Control
AES-256
At-Rest Encryption
TLS 1.3
In-Transit Encryption
Hash-Chained
Audit Log
Row-Level
Tenant Isolation
Section 02
Deployment Maturity Levels
Policy Observatory is deployable across three maturity levels. Each level represents a different operational posture, not a different product. Security properties scale with the deployment — the same platform runs under all three, with controls enabled and operated differently at each tier.
| Level | Posture | Target Use | Status Today |
|---|---|---|---|
| MVP | Multi-tenant SaaS; encryption at rest, RBAC, hash-chained audit log, tenant isolation via row-level security. Uses Kimi K2.5 (LLM) and Brave Search (news) via allow-listed external egress | Pilots, non-sensitive analysis, research evaluations | In production |
| Enterprise Hardened | Single-tenant deployment; customer identity provider; customer-provided HSM/KMS; private networking; SIEM export | Sensitive workloads, enterprise IT governance | Available via engagement |
| Sovereign Deployment | On-prem or air-gapped inside customer infrastructure; customer-held keys; controlled egress; in-country data | Government and regulated sectors requiring jurisdictional control | Supported topology; joint engagement |
The MVP is what Kaiko Studios operates for current SaaS customers. The Enterprise and Sovereign tiers are delivered through deployment engagements: the customer owns the infrastructure; Kaiko Studios provides the platform, reference configurations, and implementation support. Security properties at each tier come from how the platform is deployed and operated — not from proprietary hardware. Moving from MVP to a Sovereign deployment typically involves swapping the LLM and news-feed providers for customer-approved, in-jurisdiction alternatives; this substitution is scoped during Discovery.
Section 03
Sovereign Deployment Topologies
Three topologies are available within the Sovereign tier. All three keep the data plane inside customer jurisdiction; they differ in egress posture and operational flexibility.
| Topology | Where It Runs | Egress Posture | Best For |
|---|---|---|---|
| Air-Gapped On-Prem | Customer data centre, physically isolated | No default egress; update channel separately authorised | Classified workloads; maximum isolation |
| Sovereign Private Cloud | Customer-licensed sovereign cloud inside jurisdiction | Allow-listed, audited | Sensitive workloads needing operational elasticity |
| Hybrid | On-prem data plane; isolated control plane | Controlled, per-flow audited | Mixed classification; phased migration |
A typical starting posture for UAE government workloads is air-gapped on-prem for the data plane, with a separately authorised update channel for patches and model updates. This keeps the customer in full custody of data while still allowing the platform to evolve.
Section 04
On-Prem Reference Architecture
The reference on-prem deployment uses standard, hardened building blocks. Security properties come from how the components are composed and operated — not from proprietary hardware. Every component shown is replaceable with an equivalent customer-approved option.
Customer-controlled boundary — ingress & egress allow-listed
Data / control flow
Customer-operated management plane
Components inside the boundary run on customer-owned or customer-leased infrastructure under the customer's jurisdictional control. Cryptographic keys remain in the HSM under customer custody. The platform does not require or maintain a persistent vendor access path into the environment — any access for support is customer-authorised, time-bounded, and auditable.
Section 05
Infrastructure Reference Sizing
Reference capacities for a single-country advisory workload with continuous monitoring and a 1,535-agent swarm. All values are sizing guidance, not hard requirements; every component is compatible with the customer's approved hardware and software stack.
| Tier | Reference Sizing | Notes |
|---|---|---|
| Application compute | ~48 vCPU, ~192 GB RAM across 3 nodes | Compatible with Kubernetes, OpenShift, or equivalent orchestration |
| GPU / accelerator | 2–4 GPUs if hosting LLM inference locally | Optional; customer may use an approved LLM service instead |
| Graph DB storage | ~500 GB NVMe (encrypted) | Neo4j or compatible graph store |
| Relational DB storage | ~1 TB NVMe (encrypted, RLS-enabled) | Postgres 16+ recommended |
| Object storage | ~5 TB S3-compatible with server-side encryption | MinIO, Ceph, or customer-approved storage |
| Key management | Compatible with customer HSM / KMS | e.g., FIPS 140-3 validated; customer procures and custodies |
| Network | Zero-trust segmentation compatible | Service mesh optional (e.g., Istio, Linkerd); mTLS when enabled |
| DR site | Geo-separated, customer-operated | RPO / RTO targets are customer-configurable |
The stack is designed to run on commodity, customer-approved hardware and standard container platforms. The sensitive state lives inside the encrypted data tier and the customer-held HSM; the compute layer is replaceable.
Section 06
Customer-Controlled Sovereignty
Sovereignty properties emerge from how the platform is deployed and operated by the customer. The following primitives are what the platform enables; the customer operates them and defines the policy.
| Control | What the Platform Enables | Customer Operates |
|---|---|---|
| Data Residency | All data storage can be configured to customer infrastructure in-country | Infrastructure location, storage provisioning, capacity |
| Key Custody | Envelope encryption with customer-held keys via HSM/KMS integration | HSM procurement, key custody, rotation policy |
| Jurisdictional Control | Platform does not require data to leave customer infrastructure | Contractual jurisdiction, legal framework, counsel |
| Egress Control | No default outbound telemetry. The MVP uses allow-listed egress to reach the configured LLM (Kimi K2.5) and news feed (Brave Search); both can be substituted with customer-approved, in-jurisdiction alternatives during Discovery | Firewall rules, egress policy enforcement, periodic review of the allow-list |
| Operational Control | Documented administration surface; no persistent vendor access path | Admin staffing, training, break-glass authorisation |
| Data Portability | Documented export APIs in open, non-proprietary formats | Export execution, downstream system integration |
| Right to Destruction | Cryptographic erasure via HSM key destruction renders storage unreadable | Destruction authorisation, verification, evidence retention |
| Supply Chain Transparency | Signed SBOM published per platform release | SBOM review, third-party attestation if required |
Section 07
Shared Responsibility Model
Sovereign deployments are a partnership. The platform provides the application, reference configurations, and security primitives; the customer operates the infrastructure and the surrounding controls. The table below defines the split for a Sovereign deployment. The split shifts for Enterprise Hardened and MVP tiers — more of the customer column moves to Kaiko Studios in the MVP (SaaS) deployment.
| Domain | Kaiko Studios (Platform) | Customer |
|---|---|---|
| Identity | RBAC model, SSO/OIDC integration points, JWT issuance | Identity provider (Azure AD, Okta, etc.), MFA policy, user lifecycle, access reviews |
| Network | Segmentation-compatible design, mTLS support | Network topology, firewall rules, egress allow-list, WAF if required |
| Cryptography | Envelope encryption, HSM/KMS integration | HSM procurement, key custody, rotation policy, hardware lifecycle |
| Monitoring | Structured logs, metrics, audit events, health checks | SIEM ingestion, alerting rules, SOC operations, dashboards |
| Patching | Platform component updates, CVE notifications, tested patches | OS patching, container runtime, base images, patch windows |
| Backup / DR | Backup hooks, restore procedures, consistency checks | Backup storage, DR site, failover drills and cadence |
| Compliance | Architecture aligned with standards, control evidence, design docs | Audit execution, certification, policy and procedure documentation |
| Incident Response | Triage workflow, forensic artefacts, vendor-side notification | SOC operations, customer-side response, external communications |
In the MVP (SaaS) deployment, Kaiko Studios operates identity broker services, network controls, patching, backups, and our own incident response. In a Sovereign deployment, those responsibilities shift almost entirely to the customer — the platform provides the primitives and evidence surface, the customer runs operations.
Section 08
Threat Model
Security investment is prioritised against the threats that actually affect this class of system. The table below lists what the platform architecture is primarily designed to mitigate. Not every generic enterprise threat is addressed at the platform layer — some (e.g., volumetric DDoS) are more appropriately handled at the customer edge and are noted as out-of-scope for platform-provided defences.
| Threat | Why It Matters | Primary Mitigation |
|---|---|---|
| Data leakage / tenant isolation failure | Policy data and model outputs are sensitive; cross-tenant leakage would be a critical breach | Row-level security in Postgres, namespace isolation in the app tier, per-tenant encryption context |
| Unauthorized access | Credential compromise or privilege escalation is the most common real-world breach vector | SSO + MFA (customer IdP), RBAC with least-privilege defaults, just-in-time elevation, session recording on admin paths (configurable) |
| Model misuse / adversarial inputs | User-authored custom models could attempt data exfiltration or adversarial behaviour | Sandboxed execution (no network, restricted PATH, CPU/memory limits, 30-second timeout); tenant-admin review before production use |
| Auditability of outputs | Policy recommendations must be traceable — from which inputs, by which model, with which seed | Hash-chained audit log; every model run stores inputs, outputs, seeds, and model version |
| Supply chain compromise | Dependency or build-time compromise could introduce backdoors | Signed container images, SBOM per release, dependency scanning in CI, pinned versions |
| Privileged insider misuse | Admin access is the highest-impact internal vector | Session recording (configurable), just-in-time elevation, audit log outside admin write scope, separation of duties |
Out of scope for platform-provided defences: Volumetric (DDoS) attacks — this is not a public-facing consumer service; DDoS protection is appropriately handled at the customer edge. The platform does not ship a dedicated anti-DDoS component. Physical security of infrastructure is the customer's responsibility in any sovereign deployment.
Section 09
Security Architecture — Defense in Depth
Protection is layered across network, identity, data, application, and audit planes. Controls are modular and configurable — customers select the subset that fits their maturity level. Items below are labelled as built-in (enabled by default in every deployment), configurable (shipped with the platform, enabled via deployment configuration), or customer-operated (depends on customer infrastructure or policy).
Network
- Zero-trust segmentation — configurable. Supported via service mesh (mTLS) in the reference architecture; customer may substitute equivalent mesh or disable if not required.
- East-west encryption — configurable via mTLS when the service mesh is enabled.
- WAF & DDoS mitigation — customer-operated at the customer edge; not shipped with the platform.
- Egress allow-list — configured at deployment. Platform emits no default outbound telemetry. The MVP's allow-list includes the configured LLM and news-feed providers (defaults: Kimi K2.5, Brave Search), both substitutable with customer-approved alternatives during Discovery.
Identity & Access
- SSO integration (SAML / OIDC) — built-in; federates with customer identity provider.
- MFA — customer-operated; enforced by the customer IdP. Hardware token support depends on the customer IdP.
- RBAC — built-in. Fine-grained roles (viewer, analyst, admin, tenant-admin, auditor) with least-privilege defaults.
- Just-in-time elevation — configurable; requires customer approval workflow.
- Session recording on privileged paths — configurable; stored in the audit log when enabled.
Data Protection
- AES-256 at rest — built-in on databases, object storage, and backups.
- TLS 1.3 in transit — built-in across all network paths.
- HSM / KMS integration — configurable; customer procures and custodies the HSM.
- Field-level encryption — configurable for explicitly marked sensitive attributes.
- Tenant isolation via row-level security — built-in in the Postgres schema.
Application
- Secure SDLC — SAST, DAST, and dependency scanning in the build pipeline.
- Signed container images — built-in per release.
- SBOM — built-in. Signed software bill of materials generated per release.
- Secrets management — secrets brokered via KMS in the reference architecture; no secrets in code or default config.
- Custom model sandbox — built-in. User-authored models run in isolated subprocess, no network, restricted PATH, CPU/memory limits, 30-second timeout; tenant-admin approval required before production use.
Audit & Monitoring
- Hash-chained audit log — built-in. Tamper-evident; customer has direct read access.
- SIEM export — configurable. Platform emits structured events; customer operates the SIEM.
- Anomaly detection — customer-operated via the customer SIEM or observability stack.
- Alerting / SOC integration — customer-operated. Platform is designed to integrate with the customer SOC; Kaiko Studios does not operate a 24/7 SOC on the customer's behalf in sovereign deployments.
Section 10
Compliance Alignment
The platform is designed to support enterprise and government audit programs. Kaiko Studios is a startup; we do not yet hold the certifications below. The architecture is aligned with their principles, and certification is delivered through customer-driven deployment engagements rather than presented as a pre-existing stamp. Statements about certification in this document are forward-looking.
UAE IA (aligned)
NESA / SIA (aligned)
UAE PDPL (aligned)
ISO 27001 (aligned)
ISO 27017 (aligned)
ISO 27018 (aligned)
SOC 2 (aligned)
NIST 800-53 (aligned)
FIPS 140-3 (HSM integration)
| Standard | Scope | Current Status |
|---|---|---|
| UAE Information Assurance | Government information systems | Architecture aligned; formal attestation via deployment engagement |
| NESA / SIA Standards | Critical infrastructure protection | Architecture aligned |
| UAE PDPL (Federal Decree-Law 45/2021) | Personal data protection | Data minimisation and residency primitives built in |
| ISO 27001 / 27017 / 27018 | ISMS, cloud services, PII protection | Aligned with principles; formal certification available as an optional parallel workstream at customer request |
| SOC 2 Type II | Security, availability, confidentiality | Aligned with principles; audit engagement available as an optional parallel workstream at customer request |
| NIST 800-53 | Federal security control families | Aligned with applicable control families |
| FIPS 140-3 | Cryptographic module validation | Platform integrates with FIPS-validated HSMs procured by the customer |
Honesty note: as a startup, we are not yet certified to ISO 27001 or SOC 2 Type II. The architecture is designed to support these controls. Both are long, audit-driven processes (typically 6–12 months for a SOC 2 Type II observation window; 12–18 months for ISO 27001 ISMS implementation and certification) and are not included in the core pilot timeline. Certification can be run as an optional parallel workstream at the customer's request, with separate scope, budget, and timeline agreed up front so it does not block the pilot go-live.
Section 11
Operational Security
| Area | Platform Practice · Customer Integration |
|---|---|
| Change management | Production changes go through peer review, automated tests, and security scans. Customer-side approval workflows can be integrated at deployment. |
| Patch cadence | CVE notifications issued to customers; severity-based update cadence. OS and infrastructure patching is the customer's responsibility in sovereign deployments. |
| Vulnerability disclosure | Published responsible-disclosure policy with defined triage SLAs. Relevant findings are communicated to affected customers. |
| Incident response | Platform-side triage, forensic artefacts, and vendor notification workflow. Designed to integrate with the customer SOC; the customer operates 24/7 response in sovereign deployments. |
| Penetration testing | Supports customer-directed pen testing and independent third-party reviews. Kaiko Studios runs pre-release security testing on the platform itself. |
| Red-team exercises | Supports red-team workflows; scope and execution are customer-coordinated. |
| Personnel | Kaiko Studios staff with platform access are screened per internal policy; customer can request attestation and, where required, additional vetting as part of the engagement. |
| Training | Internal security training for engineers. Customer-side user training is delivered as part of onboarding. |
Section 12
Continuity & Resilience
Continuity properties are configurable targets, not contractual SLAs at the platform layer. The reference architecture and operating procedures are designed to meet enterprise-grade targets when deployed on appropriate infrastructure and operated by a capable team.
| Capability | Reference Target | How It Is Achieved |
|---|---|---|
| High availability | Pilot target ~99.5%; 99.9%+ achievable when deployed multi-node across AZs in a hardened reference topology | Multi-node cluster per tier; zero-downtime rolling updates |
| Recovery Point Objective (RPO) | Configurable; ~15 minutes typical | Continuous encrypted backup replication to customer DR site |
| Recovery Time Objective (RTO) | Configurable; ~4 hours for full service | Pre-staged DR environment; tested failover runbook |
| Backup retention | Customer-defined | Encrypted with customer-held keys; stored per customer policy |
| DR testing | Customer-scheduled | Joint drill with customer operations team; post-drill report |
| Graceful degradation | Core advisory remains usable under partial outage | Continuous monitoring can pause without affecting historical reports |
Section 13
Deployment Process — Phased Rollout
Deployment is sequenced so both parties can validate at each gate before proceeding. Each phase has defined exit criteria jointly agreed with the customer security team.
Discovery & Threat Model — Joint workshop with customer security team: classify data, define threat model, finalise deployment topology and maturity level, and confirm LLM and external data source preferences. Platform defaults (Kimi K2.5, Brave Search) can be swapped for customer-approved alternatives; the substitution is scoped here and adds development time to Phase 3 proportional to the replacement chosen
↓
Infrastructure Provisioning — Customer procures and racks hardware; Kaiko Studios provides reference configurations and hardening guidance
↓
Platform Deployment — Install containerised platform; configure HSM integration; wire customer identity provider; enable SIEM export pipeline
↓
Security Validation — Independent pen test, configuration audit, cryptographic review. Joint sign-off gate with the customer security team before any data is loaded
↓
Data Migration & Go-Live — Load grounding data; run validation simulations; phased user onboarding; first advisory output
↓
Hypercare & Handover — Intensive support window; operational training for the customer team; transition to steady-state with the agreed support model
Security Validation is a joint gate: the deployment does not progress to data migration until the customer security team has reviewed and signed off on the pen-test report and configuration audit. No customer data is loaded before that gate is passed. Timing note: pen-test vendor booking begins in Phase 2 and the test runs in parallel with late Phase 3 platform deployment to avoid blocking go-live. A ~2-week remediation window is budgeted between report delivery and go-live. Similar parallelisation applies to UAE data-access authorisations and compliance mapping — dependencies that sit outside our direct control are identified early and tracked as scheduling risk items.