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.

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 — on the roadmap — 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

Managed Postgres on Cloud SQL, encrypted at rest. Row-Level Security is enforced at the database layer; 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 (data connectors, other vendor APIs) are held only by pointer, and never appear in the application database or in logs.

Identity

First-party auth + Google sign-in

Session tokens validated on every request. Passwords stored as scrypt hashes only; Google sign-in via OAuth 2.0 for accounts that prefer it. No third-party identity provider sits in the data path.

Models

Anthropic Claude + OpenAI GPT

In force today: 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.

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.

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.

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).

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.

Kernel-jailed execution · sandbox. Model-generated code runs on a dedicated Cloud Run Gen2 microVM runner, separate from the API server. Each execution is confined to its own unprivileged kernel jail, and the microVM’s hardware-VMM boundary separates the runner from the rest of the fleet. User code cannot reach the API server, the database, or another tenant’s execution.

§ 3 · Data path

Outside parties in the data path.

Every outside vendor that touches the product is named below — what it sees, and the contract that constrains it. Explicitly, rather than gesturing at “trusted subprocessors.”

Anthropic Claude API · OpenAI API

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

In force today: 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.

LlamaParse

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

In force today: a signed DPA with Zero Data Retention and a no-training commitment. A self-hosted parser on our own Cloud Run is on the roadmap, at which point documents stop leaving GCP altogether.

Serper (web search)

The search queries the agent issues during research — never your documents, prompts, or outputs.

Standard API terms. Queries travel under our platform key with no tenant identity attached; note that a query can name the subject of your research, so what the agent is asked to research is under your control.

Stripe

Billing identity — name, email, subscription state. Card details are entered on Stripe’s own checkout surface and never touch our servers.

PCI DSS Level 1 service provider, standard DPA. Sees billing state, not tenant business data.

Resend

Your email address and the content of transactional messages — verification links, receipts.

Standard DPA. Transactional email only; document content and workspace data never route through it.

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 · program underway

We're building toward a SOC 2 Type II report. In the meantime we 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

In force today: a DPA on request and Zero Data Retention with both LLM vendors and the document parser. Integration credentials live only in Secret Manager, with just an opaque pointer stored in the application database.

Customer-VPC deployment

Port-swap architecture · roadmap

Every infrastructure layer (compute, Postgres, object storage, secrets, integration 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, or careers, see the full contact menu.

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

Email security Talk to the team