Skip to content
KENNAN · DISPATCH · 2026.06.28 · NYC · LON · FRA

Security · Kennan AI

How Kennan handles MNPI, from the infrastructure layer up.

Built on GCP, with per-org isolation enforced at three layers and vendor data paths constrained by contract. The public posture is laid out below; the SOC 2 review packet is available under DPA.

The five sections below cover the underlying infrastructure, how one tenant is isolated from another, who sees what data, what we inherit from the cloud provider, and what we commit to on our own. For review materials, DPA execution, or vulnerability disclosure: security@kennan.ai.

§ 1 · Substrate

What this product runs on.

At launch, GCP — and only GCP — sits in the MNPI data path. Every infrastructure layer has a port interface, so deploying into a customer's own VPC (Phase 4) is a configuration change rather than a codebase fork.

Compute

GCP Cloud Run · Gen2 microVM

Hardware-VMM isolation between instances — the same primitive Google uses for App Engine and Cloud Functions inside its own multi-tenant fleet. The boundary holds even if the kernel-layer sandbox is escaped.

Application database

Cloud SQL on GCP

At launch, managed Postgres on Cloud SQL: regional HA, private IP, encryption at rest. Row-Level Security is enforced at the database layer today; details under Isolation.

Object storage

Google Cloud Storage

Every object key carries a per-tenant prefix (org/{org_id}/workspace/{workspace_id}/). AES-256 server-side encryption by default.

Secrets

GCP Secret Manager

Credentials are pulled at deploy time. Integration API keys (Bloomberg, MCP servers, other vendor APIs) are held only by pointer, and never appear in the application database or in logs.

Identity

Clerk

JWT-validated on every request. SOC 2 Type II + ISO 27001. Our database stores a mirror keyed by Clerk user ID — no password material on our side.

Models

Anthropic Claude + OpenAI GPT

At launch, enterprise tier on both vendors with Zero Data Retention: prompts, tool calls, and outputs are discarded after the request and never used for training.

§ 2 · Isolation

Three layers of isolation, enforced five ways.

Tenant separation lives in the application, in the database, and in the physical substrate — three independent layers, the five concrete mechanisms below. Each would catch a missing scope filter on its own; they exist together because a cross-tenant leak in financial work isn’t a bug ticket, it’s an incident report.

01
Scoped query builder · application layer. Every query passes through a typed scope — org or workspace. Raw database access outside the builder is a contract-test failure, caught at CI before the change ships.
02
Postgres Row-Level Security · database layer. Every multi-tenant table carries an RLS policy. FORCE ROW LEVEL SECURITY extends enforcement to the table owner — required on managed Postgres. On the enforcing (direct) connection, a query missing its scope filter returns zero rows; on the pooled connection the scoped query builder (layer 01) is the guarantee. The two postures are defense-in-depth — neither is relied on alone.
03
SET LOCAL app.current_org_id · connection layer. Direct-pool queries set the connection-scoped org context; Postgres enforces RLS predicates against it. End-to-end tested with a real database against synthetic two-org fixtures (cross-tenant-isolation suite).
04
Per-tenant object prefix · GCS. Every object key lives under org/{org_id}/workspace/{workspace_id}/, so the tenant boundary is visible in the path itself. A missing or wrong prefix is treated as a P0 incident, not a code-review nit.
05
Per-execution container · sandbox. Cloud Run Gen2 microVM, fresh container per execution. No state reuse between turns. Hardware-VMM boundary between any two tenants’ code, on top of the kernel-layer sandbox inside the instance.

§ 3 · Data path

Outside parties in the data path.

Outside vendors touch the product at five points in its data path — a couple of them served by two vendors apiece, named in the row. Each operates under contractual constraints, which we name explicitly in the rows below rather than gesturing at.

Anthropic Claude API · OpenAI API

LLM prompts, tool calls, and outputs during a request.

At launch, enterprise tier on both vendors with Zero Data Retention: prompts and outputs are discarded after the request and never used for training. We use two vendors because the agent core runs parallel Claude and GPT bundles.

Landing AI ADE · LlamaParse

Document text during parsing — only the documents you upload, only at parse time.

At launch, a signed DPA with Zero Data Retention and a no-training commitment. EU-region option for GDPR-sensitive engagements. In Phase 2 we move to a self-hosted parser on our own Cloud Run, so documents stop leaving GCP altogether.

Clerk

User identity — name, email, SSO claims.

SOC 2 Type II + ISO 27001. Sees authentication state, not tenant business data.

Google Cloud Platform

Everything on the substrate — compute, storage, database, secrets.

Google Cloud DPA. ISO 27001 / 27017 / 27018, SOC 1 / 2 / 3, FedRAMP High, HIPAA BAA, PCI DSS, C5, IRAP. Encryption at rest by default; CMEK available for enterprise customers.

Vercel

Frontend HTML, static assets, route metadata.

Standard DPA. Business data is fetched directly by the browser from the API server (also on GCP); Vercel’s CDN edge never caches tenant data.

§ 4 · Compliance

Compliance posture and ongoing commitments.

GCP’s own compliance program covers the cloud infrastructure. Our own audit and the contracts we commit to on top are listed in the cells below. Anything not covered here is the kind of thing we’d walk through under DPA.

Substrate compliance

Inherited from GCP

ISO 27001 / 27017 / 27018. SOC 1 / 2 / 3. FedRAMP High. HIPAA BAA. PCI DSS. C5. IRAP. Encryption at rest by default, with CMEK available for enterprise customers.

Application-layer controls

SOC 2 Type II · in progress

Our own controls audit is underway. In the meantime we can share an interim review packet under DPA: three-layer isolation evidence, secret-handling posture, vendor data-path attestations, and the vulnerability-disclosure process.

Data-handling commitments

DPA · ZDR · EU residency option

At launch, a DPA on request and Zero Data Retention with both LLM vendors and the document parser, plus EU-region document parsing for GDPR-sensitive engagements. Already in force: MCP credentials live only in Secret Manager, with just an opaque pointer stored in the application database.

Customer-VPC deployment

Port-swap architecture · Phase 4

Every infrastructure layer (compute, Postgres, object storage, secrets, MCP credentials) has a port interface. Deploying into a customer’s own GCP, AWS, or Azure tenancy is a configuration change rather than a codebase fork. The customer’s compliance team then reviews their own infrastructure, not ours.

§ 5 · Contact

Reaching security.

One inbox handles review packets, DPA execution, security questionnaires, and vulnerability disclosure. It’s monitored by someone on the team, and you’ll usually hear back within a day.

Security · DPA · disclosures

security@kennan.ai

For SOC 2 review materials, DPA + ZDR contract requests, and vulnerability disclosures. Please describe the in-scope workflow and the institution you’re reaching out from.

For sales, press, careers, or the founder’s direct line, see the full contact menu.

If you need the review packet that sits behind the DPA, get in touch and we’ll share it.