Kraterion
SOSecurity & ownership

Your data.
Your logs.
Your exit.

Files, run records, and memory are encrypted before they leave you and stored in a project you own. We can't read them, we can't alter them, and you can revoke our access in one step.

You hold the keysSealed at uploadRevocable by structure
bucket.support-docs
Key custody
You hold
Data keygenerated on device · per file
9c4a8b21f0e7c2
Key wrapthreshold split · 2-of-3 key servers
2-of-3 shares
Policy · who can decrypt
team@acme-co.com
read · write
kr_share_test_3f4d…01ab
read · origin acme-co.com
ex-employee@acme-co.com
revoked · t+0
Platform holds
ciphertext
2.1 MB · opaque
cannot decrypt
without your keys
0
plaintext bytes leave your device
Encryption is the default
TLS 1.3
in transit
Modern ciphers only
2-of-3
key servers must agree
No single point of trust
90 days
access log retention
Audit-ready
01The shift

Same files. Different perimeter.

Typical S301 · before

They hold the keys.

provider.s3·/iam/access-keys
Access keys · provider-managed3 active
  • AKIA7C4D8E1C…3Fread-onlyactive
  • AKIA92AC6712…A1read-writeactive
  • AKIA1A8B4C5D…99adminactive
Revoke via support ticketdisabled

Manual process · SLA 2-5 business days

  • Keys live inside the provider boundary.
  • Revoke is a support ticket, not a property.
  • Exit means copying everything out — at $0.09/GB egress.
Kraterion02 · after

You hold the keys.

app.kraterion.com·/keys
Your keys · scoped per agentyou hold
  • kr_test_3f4d8e1c…a2read-onlyactive · revoke
  • kr_test_92ac6712b1…7cread-writeactive · revoke
  • kr_share_test_1a8b4c…99agentactive · revoke
Revoke per agent · enforcedone click

Keys stop being issued immediately — by structure, not policy.

  • Keys live with you. Plaintext never crosses the wire.
  • Revoke is a policy property — enforced, not promised.
  • Exit through any S3 client — at ~9× lower egress than AWS.
02Four claims

What ownership
actually means here.

01

You can leave anytime.

Files are stored as plain bytes addressed by a stable ID. Any S3-compatible client can pull them. You don't need our tools to leave us.

02

Sealed before it leaves you.

Files are encrypted on your device before they ever reach the platform. The platform sees only encrypted bytes.

03

Revocable access — enforced, not promised.

When you remove access, the decryption keys stop being issued. The ciphertext sitting on disk becomes unreadable to the revoked party.

04

A verifiable audit log.

Every artifact — upload, indexing run, agent answer, citation — is bound to a uniquely-IDed, version-tracked record. Anyone can independently verify the history.

Bridge

Plaintext never leaves
the laptop.

03How sealing works

Encrypted before it leaves you.

Encryption happens on your device. We store only what we can't read.

Envelope encryption · client-sidephoto-final-v3.jpg
policykekdek
  • 1
    Data key
    Generated on your device — encrypts the file
  • 2
    Key wrap
    Wraps the data key so only policy can release it
  • 3
    Policy
    Your access policy gates the key

Sealing is handled by Seal; the access policy that releases the keys is enforced on Sui — so revoking access is a property of the system, not a support request.

04How revocable access works

Policy is the gate. Not a promise.

When you revoke access, the system stops issuing the keys needed to decrypt. Existing ciphertext doesn't have to be deleted to be unreadable to a revoked party.

01
Define a policy

Who can decrypt; under what conditions.

02
Key servers enforce it

Independent servers check the policy on every request.

03
Request access

Authorized clients receive key shares; unauthorized clients receive nothing.

04
Revoke

Remove access — key servers stop issuing shares. Existing ciphertext stays unreadable.

Policy · bucket.support-docs
// stored as a public, verifiable record
policybucket.support-docs {
allow team@acme-co.com read, write
allow kr_share_test_3f4d… read (origin: acme-co.com)
allow ex-employee@acme-co.com read
// revoked 2026-05-12 · ciphertext now unreadable to this party
}
05Verifiable audit log

A tamper-evident history.

Every artifact has a uniquely-IDed, version-tracked record. The history is independently verifiable.

Manifest IDVerDigestActorActionTime
upload_a4f2c8…v129c4a8b21f0e7c2…you@acme-co.comPut object2026-05-20 14:02:11
index_run_91…v74d2f0e9c7b81a…systemIndex bucket2026-05-20 14:02:14
agent_answer_22…v34f1ab3a0e7c2f…support-agentCite chunk2026-05-20 14:02:18
citation_07…v2fa0012a4e7c2f…support-agentBind source2026-05-20 14:02:18
access_grant_3…v1a1b2c3d4e5f6a…you@acme-co.comGrant team-read2026-05-20 13:58:42
06Compliance

Plain English.

Encrypted in transit

TLS 1.3 with modern cipher suites.

Access logs

Server-side access logs retained for 90 days.

SOC 2

In progress — on the roadmap.

HIPAA / PHI

Not currently suitable for regulated personal data (HIPAA / PHI).

Building toward EU AI Act, GDPR, or ISO 42001? See how Kraterion fits AI governance.

Trust by structure

Storage that earns trust
by structure, not promise.

Sealed before upload. Revocable by policy. Verifiable end-to-end.

v 0.1 · testnetAll systems normal