Security overview

November 4, 2026. For your IT and risk teams. To keep a copy, print this page or save it as a PDF.

The security pack: this overview, our subprocessors, the data processing agreement, the terms of service and the privacy policy. We answer security questionnaires by email at contact@kolophi.ai.

Your firm's own install

• Each firm's Kolophi install runs on its own virtual machine in Google Cloud's us-central1 region, in Iowa, with its own data disk and its own address under kolophi.ai. No two firms share a server, a disk or a database.
• Each install has its own identities: its own Microsoft app registration and its own Google service accounts. A firm's approval of read access is therefore given to its install alone and can't be used to reach another firm's systems.
• The servers use Google's Shielded VM features: secure boot, a virtual TPM and integrity monitoring.
• The install's secrets, such as its Microsoft app secret and Google key, are kept in Google Secret Manager under the install's name, readable only by that install's server, and loaded into memory when it starts. Credentials your firm enters for a source, such as an iManage service user, are kept in files only Kolophi's own process can read, never in its database or audit log.

Network and encryption

• Only HTTPS reaches the server. Plain HTTP is redirected, and certificates are issued and renewed automatically. Pages are sent with HSTS and headers that block framing and content sniffing.
• Google Cloud encrypts the server's disks and backups at rest.
• Kolophi's database overwrites deleted content, so destroyed records don't linger in free space.

Access to your systems

• Kolophi asks only for read access: Microsoft's read-only Graph permissions, a read-only iManage service user, Viewer on Google Drive folders. It never changes or deletes anything in your systems.
• Before anything is copied, Kolophi lists names, sizes and dates only, and a named person at your firm approves which areas it may read. Areas added later wait for approval.
• For Exchange, your administrator limits Kolophi to the mailboxes you name with an application access policy.
• Revoking the approval or removing the service user cuts Kolophi off at once.

Who can see what

• People sign in with their Microsoft work accounts, and only after one of your administrators adds them. Sessions end after 2 hours idle or 12 hours at most.
• Roles decide who may review, place holds, approve destruction or sign it off. Ethical walls hide a screened matter's records from the people screened, everywhere in Kolophi, including search and research answers.
• AI assistants your people connect to Kolophi get tokens that expire after an hour, see only what that person may see, and can be disconnected at any time.

The AI model

• To classify, describe and screen documents, Kolophi sends their text to Claude, a model made by Anthropic, through Google Cloud's Vertex AI, under Kolophi's Google Cloud agreement. Text is sent unredacted, because screening for sensitive information means reading it.
• Google's terms for Vertex AI say it won't use customer data to train or fine-tune models without permission, and Anthropic's commercial terms say it doesn't train its models on customer content. Google may keep prompts for a limited time to detect abuse, under its own policies.
• A client marked "no AI" is never sent to any model. Its records are reviewed by your staff.
• Every model call is recorded with its token counts, and every proposal with the text it quoted, so a person can check why Kolophi proposed what it did.

Records and evidence

• Original files are stored unchanged, with a SHA-256 checksum checked on demand.
• The audit log is append-only and hash-chained, so a change to any past entry shows. Destruction certificates are fingerprinted the same way.
• Destruction needs approval from your records manager and a separate sign-off from legal, and rechecks holds, open matters and client objections at the moment of signing.
• Kolophi never deletes from your systems. Each certificate lists the originals for your administrator to delete, and each later sync records which are gone.

Backups

Each install's data disk is snapshotted daily, and each snapshot is kept for 30 days. A record destroyed in Kolophi can remain in those snapshots until they expire, which its certificate states.

When your firm leaves

When your subscription ends at your request, the control plane destroys your install at once: the server, its disks, every snapshot, the secrets, the service accounts with their permissions, the Microsoft app registration and the address. It then asks each provider again whether each item still exists, and only when every one is confirmed gone does it issue a certificate of destruction, signed with Kolophi's Ed25519 key. Anyone can check a certificate against the public key at kolophi.ai/.well-known/kolophi-certificates.pub.

If a payment fails instead, the server is stopped and nothing is deleted for 30 days, so an expired card can't destroy a firm's records.

Kolophi's own access

We don't read your firm's files. Kolophi staff reach an install's server only for support you ask for, to keep it running, or where the law requires, and only through Google Cloud's identity-checked access. Kolophi's own audit log doesn't yet record that access; we're adding it.

Incidents

If a breach affects your firm's data, we'll tell your administrators within 72 hours of confirming it, with what we know, and help you meet your own obligations. Report a suspected vulnerability to contact@kolophi.ai.

Certifications

Kolophi doesn't yet hold a SOC 2 report or ISO 27001 certification. Google Cloud, which hosts every install, holds both. Kolophi isn't offered under a HIPAA business associate agreement.