Security you can check, not just read about.

Interlok's job is proof, so its own security has to be provable too. Here is how records are signed, what is stored, and how to check it without us.

Signing and keys

Every workspace has its own ECDSA P-256 signing key. Every record is signed and linked to the one before it by hash, so an edit, a deletion or a gap breaks the chain.
Keys Interlok holds are encrypted at rest with AES-256-GCM under a separate key-encryption key.
You can hold your own key for approvals. A determination then carries a signature made in the approver's browser that Interlok cannot make.
Each hour, a signed Merkle root over new records is published on a public feed, so a later rewrite of history would not match.

Who can decide

Held actions are decided by a person whose identity is verified through your identity provider (Okta or Google).
An agent can never approve an agent. The verifier refuses a determination written by anything but a person, and refuses an outcome written by a person.
If Interlok cannot reach its database, a connection fails closed by default: the tool call fails rather than running ungoverned.

What we store, and what we never store

Tool arguments are hashed on every decision. What is kept in readable form passes through your policy's redaction rules first.
Model prompts and completions are hashed on arrival and never stored. Inference receipts sit outside the model call path.
Outcome records carry a status and hashes, never what a tool returned.
Records from another gateway drop request headers, except the correlation header you configure; a test fails the release if a planted secret reaches a record or a log line.

Checking our work

The verifier is open source (Apache-2.0) and runs offline: in your browser at /verify or with npx @interlok/cli verify. The browser and the command line run the same code and must agree.
A bundle carries the whole contiguous chain for its range, so a missing record shows, even when its content is withheld.

Where it runs

The application runs on Vercel; data lives in Supabase (Postgres). Every response carries strict transport security, and only Interlok's own pages may frame the console.

Compliance status

Interlok does not have a SOC 2 report yet. We are preparing for one and will share our controls, and what this page describes, on request. Interlok's evidence maps to your frameworks; that mapping is not an audit opinion.

Report a vulnerability

Email hello@interlok.io with "Security report" in the subject. Please give us a chance to fix an issue before disclosing it.

Signing and keys

Every workspace has its own ECDSA P-256 signing key. Every record is signed and linked to the one before it by hash, so an edit, a deletion or a gap breaks the chain.

Keys Interlok holds are encrypted at rest with AES-256-GCM under a separate key-encryption key.

You can hold your own key for approvals. A determination then carries a signature made in the approver's browser that Interlok cannot make.

Each hour, a signed Merkle root over new records is published on a public feed, so a later rewrite of history would not match.

Who can decide

Held actions are decided by a person whose identity is verified through your identity provider (Okta or Google).

An agent can never approve an agent. The verifier refuses a determination written by anything but a person, and refuses an outcome written by a person.

If Interlok cannot reach its database, a connection fails closed by default: the tool call fails rather than running ungoverned.

What we store, and what we never store

Tool arguments are hashed on every decision. What is kept in readable form passes through your policy's redaction rules first.

Model prompts and completions are hashed on arrival and never stored. Inference receipts sit outside the model call path.

Outcome records carry a status and hashes, never what a tool returned.

Records from another gateway drop request headers, except the correlation header you configure; a test fails the release if a planted secret reaches a record or a log line.

Checking our work

The verifier is open source (Apache-2.0) and runs offline: in your browser at /verify or with npx @interlok/cli verify. The browser and the command line run the same code and must agree.

A bundle carries the whole contiguous chain for its range, so a missing record shows, even when its content is withheld.