Secrets an agent writes into its workspace are included in checkpoints.
A checkpoint is a copy of a running machine, so anything the agent writes inside it is copied too. The gateway holds the provider key outside that machine; it cannot hold a secret the agent creates in its own workspace.
isolation boundary
Host key store
Gateway-managed provider credentials are held outside the guest. Keys or other secrets that a user or agent writes into guest memory or workspace can be captured by a checkpoint.
key custody matters · hardware-backed key management remains planned
Provider key → GatewayGateway
Scopes model access to the session and records usage. Historical tests cover billing idempotency and replay; provider behavior and client retries have separate limits.
session-scoped access · dated historical evidence
Virtual key → GuestMicro-VM guest
The agent, its filesystem, its tools. Hardware-virtualized, one tenant, no shared kernel. Sees the per-session virtual key only; the gateway-managed provider key never enters a guest, image, or snapshot.
reaches the model only through the gateway · no egress-allowlist gate yet
Workspace state → CheckpointCheckpoint store
Saved guest state is stored with per-account encryption described by the historical tests. The gateway-managed provider key never enters a checkpoint; any secret an agent writes into its workspace IS part of that workspace and is captured by checkpoints.
account-deletion tests are historical; current deployment is not independently verified
The guest is the only place your agent's code runs. The gateway-managed provider key never enters it, so a stolen checkpoint yields a filesystem and a conversation, not a way to spend your money; any secret your agent writes into its own workspace is part of that workspace and is captured by checkpoints. Every checkpoint chunk is encrypted under your account's key, so a stolen checkpoint without that key is ciphertext.
Where a real gate exercised a rule, the chip reads gated and links to the record on Proof. Where none has, the chip says policy or roadmap, because an unwatched rule is a policy, not a proof.
A provider key is never written into a guest.
Gateway-managed provider keys stay outside the guest. This does not exclude secrets you or your agent put into the workspace or memory.
A checkpoint cannot contain the gateway-managed key, because that key never enters the guest.
Gateway-managed provider keys stay outside the guest. User- or agent-written secrets can be captured in checkpoints. The historical test exercised this boundary; it does not establish every later deployment.
Virtual keys are scoped to one session.
A guest receives a virtual key naming one session, and the gateway meters every call made with it. Budget scoping is enforced in the gateway code; no gate watches it yet.
Humans never handle a virtual key.
They are minted and injected by the gateway. No screen displays one and no process asks for one. Policy, enforced in code; no gate yet.
Planned: provider-key revocation that checkpoints and parks the session.
Designed behavior for the hosted service: revocation lands at the gateway and the session checkpoints and parks. Roadmap, not yet built.
Staff access controls require current implementation evidence.
Consent, owner notification and audit logging are published commitments. A complete implemented staff-access control is not established by the available record; do not infer it from the checkpoint tests.
The KeepState engine runs only on KeepState infrastructure. Verified execution, checks, recovery, and settlement, can be attached to agent work running in your environment, with limitations declared per environment. Sessions run on the KeepState fleet, which makes these rules the product, not an appendix. Same register as key handling: a rule with a gate names it; a rule without one says policy, because an unwatched rule is a policy, not a proof.
What we store
Three things: the workspace you chose to send when you started the session, the checkpoints (saves) of your sessions as content-addressed chunks, and the event ledgers. Nothing is collected from your machine beyond what you named, and the exact rules are documented per flag in how sessions run.
Encryption
In transit, TLS on every path between the ks command, the console, and the fleet. Historical checks report per-account checkpoint encryption and platform encryption for service records. Current deployment is not independently verified; credential erasure depends on the documented key-custody conditions.
Retention and deletion
Retention and deletion policy v1.0 · approved 2026-09-09. This policy was approved on 2026-09-09 and published as final on 2026-09-14. The commitments below remain in force as published. Implementation gaps are stated separately and do not amend the policy. The matrix itself is the table below, and it is the only retention answer this site publishes.
Support access
Nobody at KeepState opens a customer session as a matter of course. The standing rule is: access only with your explicit consent on a named session, logged in the same ledger you can read. A break-glass path with owner notification and expiry is the hosted design, labeled roadmap until gated.
Retention and deletion policy v1.0 · approved 2026-09-09
Legal holds are not currently supported; retention proceeds as stated unless law requires otherwise.
This policy was approved on 2026-09-09 and published as final on 2026-09-14. The commitments below remain in force as published. Implementation gaps are stated separately and do not amend the policy.
A cell reading "not stated in v1.0" is a question this version does not answer. It is printed rather than filled, because filling it would be inventing policy; it is answered in a versioned reissue, never in place.
| category | retained | deletion | backups | evidence |
|---|---|---|---|---|
| Checkpoint content | while the account exists; no automatic expiry | deletable by the customer, per session; the key is destroyed on account deletion | encrypted, and unreadable once the key is destroyed; backup retention 30 days | account deletion: er-1c-green, er-1c-prod-green; per-session deletion: er-1s-green (bench); served in production since 2026-10-06 (docs/deploy-2026-10-06.md) |
| Provider credentials | same as checkpoint content | same as checkpoint content | same as checkpoint content | account deletion: er-1d-green, er-1d-prod-green |
| Ledgers and billing aggregates | 7 years, under legal obligation | the identity is tombstoned on deletion | not stated in v1.0 | tombstone: er-1c-prod-green |
| Service logs | 30 days | not stated in v1.0 | not stated in v1.0 | no gate yet |
| Support tickets | 2 years | not stated in v1.0 | not stated in v1.0 | no gate yet |
| Console audit log | 2 years | the identity is tombstoned on account deletion | not stated in v1.0 | tombstone: er-1c-prod-green |
| Account data | while the account exists | deleted on account deletion, except the tombstone id and the billing aggregates already covered above | not stated in v1.0 | account deletion: er-1c-prod-green |
| Telemetry | 13 months, then deleted | first-party, cookieless, and carries no identifiers, so there is nothing to tombstone | not stated in v1.0 | no gate yet |
What the rows rest on, and what no implementation carries yet. The production deletion facts below are the EVIDENCE for the matrix, not a second policy; the gaps ride with them so the commitment is never read without them.
Historical evidence: account deletion made the tested checkpoint backup unreadable in a synthetic production check. This proves the tested account-deletion behavior, not per-session deletion or every possible backup.
Historical evidence: stored provider credentials were protected per account and a tested database backup became unreadable after deletion. This depends on keeping account keys outside the database backup set and removing independent key copies.
Historical evidence: account deletion removed personal identity fields while retaining the tombstone needed for ledger consistency. Ledgers and billing aggregates have a separate retention commitment.
Evidence: deleting a session erases the checkpoint content only that session held, served in production since 2026-10-06; sessions saved earlier were re-sealed on 2026-10-10 so it covers them. Content a surviving fork shares stays that fork's. A production check through the customer deletion route is still owed. Stopping or killing a session does not delete its stored content.
Implementation gap: no automatic expiry job is established for these categories. The 30-day backup and service-log periods and the two-year support-ticket period remain policy commitments; current evidence of procedural enforcement is not available.
Legal holds are not currently supported; retention proceeds as stated unless law requires otherwise.
The matrix is rendered from the retention record; the same table appears on the Privacy Policy and in the DPA.
The full asset/boundary/control model, with each control’s evidence and remaining gaps stated separately, is the threat model.
| Surface | Protection today | Deletion and retention | Planned |
|---|---|---|---|
| In transit | TLS on every path between the ks command, the console and the fleet. | Nothing is retained in transit. | None. |
| Checkpoint content at rest | Historical production checks report per-account checkpoint encryption. Current deployment is not independently verified by those tests. | Retained while the account exists, with no automatic expiry. Deleting a session erases the content only it held, in production since 6 October 2026; a production check through the customer deletion route is still owed. Historical account-deletion tests are separate. | None. |
| Provider credentials | Gateway-managed provider keys are held outside the guest. User- or agent-written secrets are a separate boundary. | Same as checkpoint content: destroyed with the account key. | Planned: provider-key revocation that checkpoints and parks the session. |
| Event ledgers and billing aggregates | Platform disk encryption on the fleet hosts. | Retained seven years under legal obligation; identity tombstoned on deletion. | None. |
| Agent-written workspace secrets | None. A secret the agent writes into its workspace is inside the machine, so it is inside the checkpoint. | Follows checkpoint content. | Not planned as a guarantee. Content scanning is not a control we offer. |
In transit
Protection today: TLS on every path between the ks command, the console and the fleet.
Deletion and retention: Nothing is retained in transit.
Planned: None.
Checkpoint content at rest
Protection today: Historical production checks report per-account checkpoint encryption. Current deployment is not independently verified by those tests.
Deletion and retention: Retained while the account exists, with no automatic expiry. Deleting a session erases the content only it held, in production since 6 October 2026; a production check through the customer deletion route is still owed. Historical account-deletion tests are separate.
Planned: None.
Provider credentials
Protection today: Gateway-managed provider keys are held outside the guest. User- or agent-written secrets are a separate boundary.
Deletion and retention: Same as checkpoint content: destroyed with the account key.
Planned: Planned: provider-key revocation that checkpoints and parks the session.
Event ledgers and billing aggregates
Protection today: Platform disk encryption on the fleet hosts.
Deletion and retention: Retained seven years under legal obligation; identity tombstoned on deletion.
Planned: None.
Agent-written workspace secrets
Protection today: None. A secret the agent writes into its workspace is inside the machine, so it is inside the checkpoint.
Deletion and retention: Follows checkpoint content.
Planned: Not planned as a guarantee. Content scanning is not a control we offer.
| surface | at rest | in transit |
|---|---|---|
| Checkpoints | per-account encryption recorded in historical production tests | historical production check; current deployment not independently verified |
| Event ledgers | platform encryption at rest; a separate retention policy applies | identity tombstoned on deletion; retained 7 years, under legal obligation |
| Provider keys | per-account credential protection in the recorded tests; keys remain outside the guest | historical deletion tests passed under stated key-custody and backup-separation conditions; hardware-backed key management is planned |
| This site and the console | static pages over HTTPS; the hosted API is ctl.keepstate.ai over TLS | one region today (Europe) |
| Backups | The available record does not establish a scheduled backup tier. Backup erasure depends on key custody and independent copies. | policy: encrypted, and unreadable once the key is destroyed; backup retention 30 days; historical erasure results apply only under their stated conditions |
Per-organization keys, rotation schedules, and customer-held root keys are the hosted design, labeled planned. No number about them appears here until a gate measures one.
KeepState holds no third-party security certification today. There is no SOC 2 report, no ISO 27001 certificate, no published external penetration test, and nothing under HIPAA or FedRAMP.
When one exists it is named here with its date and its auditor, and not before. No badge appears on this site until the certificate exists. There is no reserved slot waiting to be filled, because a reserved slot is a claim.
Report anything that looks like a way past the boundary. We commit to answer within one business day, to fix or explain within thirty, and to publish the finding with your name on it unless you ask us not to. Commitments, not measurements; there is no history to measure yet.
security@keepstate.ai A signed disclosure key is being published. Until it is live, no fingerprint appears here, because a fingerprint that verifies nothing is a hazard, not decor.
The honest version of a threat model names what it does not cover. These are the three places we consider ourselves most exposed today.
exposure 1
We wrap images, we do not audit their contents beyond signature and provenance. Community-wrapped images carry more risk than the two we gate, and the compatibility matrix says which is which. Guests reach the model only through the gateway (the gate-3 path); a formal egress-allowlist gate does not exist yet, and we say so.
exposure 2
If your agent writes a secret to disk, that secret is in every subsequent snapshot, and it stays there for as long as your account holds those checkpoints: the approved policy keeps checkpoint content while the account exists; no automatic expiry. Checkpoint secret scanning is not built and is not offered as a guarantee. Gateway-managed keys stay outside the guest, but user- or agent-written secrets do not. Treat a workspace as a place secrets do not belong.
exposure 3
That is a real procurement risk and we will not argue otherwise. What we offer instead is the claims file, the findings archive, and a security pack you can read without talking to anyone. Judge us on published evidence rather than on a badge we have not earned.
Every control named on this site, with the deployment state derived from the same capability source that Proof and the threat model render. A control with no assertion covering it says so here rather than borrowing the result of an unrelated gate.
Gateway-managed provider credentials stay outside the guest. Secrets written into guest memory or workspace can be captured by a checkpoint.
Evidence register dated 2026-10-23; recorded deployment: enabled in production. Current deployment not independently verified.
Historical production checks report per-account checkpoint encryption and account deletion that made the tested saved content unreadable. Continued protection depends on key custody; this is not evidence of per-session deletion.
Evidence register dated 2026-10-23; recorded deployment: enabled in production. Current deployment not independently verified.
Hardware virtualization isolates each session guest. Historical lifecycle tests cover the tested runtime and architecture; they do not constitute a penetration test or proof against shared-host attacks.
Evidence register dated 2026-10-23; recorded deployment: enabled in production. Current deployment not independently verified.
Built and running in production: opening a customer's session content needs a typed reason, lasts an hour, lands in the customer's own audit trail and sends a security email, and the admin console's gates (ad-1 to ad-4, under ADR-022) proved it on the bench, sabotage runs included. Outside such a window the content is refused.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
Built and running in production: every write a staff member makes through the admin console is logged with who, what and why, and the admin console's gates (ad-1 to ad-4, under ADR-022) proved it on the bench, sabotage runs included. No dedicated public gate covers staff access outside the admin console.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
Built and running in production: staff hold roles, and a support role cannot reach owner actions, as the admin console's gates (ad-1 to ad-4, under ADR-022) proved on the bench, sabotage runs included. Mandatory review of production changes is a process with no dedicated public gate.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
Historical deletion tests report that deleting the tested account did not damage the other tested account. This limited scenario does not establish isolation against every attack.
Evidence register dated 2026-10-23; recorded deployment: proven, not enabled in production. Current deployment not independently verified.
Built and running in production: every customer route requires a signed-in account and acts only on the sessions that account may reach, by the least role each route names. No dedicated public gate covers authentication or session ownership.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
Built and running in production: a restore, wake or fork is accepted only from an account with a role on the session, checked like every other customer route. No dedicated public gate covers it.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
A separate hosted self-serve export API is not established by the available evidence. Published data-return and audit rights remain as stated in the legal documents.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
The published 24-hour breach-notification commitment remains as written. Current implementation evidence for the response process is not available; missing evidence does not suspend the commitment.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
The published commitment not to train models on session contents remains as written. Current implementation evidence is not available; provider processing is governed by the applicable provider terms.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
The versioned subprocessor list and its stated notice periods remain binding. The register is an editorial policy record, not a technical test.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
Review the workspace before upload: user- or agent-written secrets can enter checkpoints. Documentation of that boundary is not an upload-integrity test.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
Checkpoint secret scanning is not built and is not offered as a guarantee. Keep secrets out of guest memory and workspace.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
The gateway is the supported path for model calls. A general guest egress allowlist is not established; do not treat this as protection against all workspace exfiltration.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
The status page publishes timestamped service checks and incident summaries. Coverage of every service and a staffed response rotation are not established by the available evidence.
Evidence register dated 2026-10-23; recorded deployment: production state unavailable. Current deployment not independently verified.
The legal documents, each versioned, and the claims file are readable now, with no form and no call first. A versioned public security summary is available for download. No restricted evaluation pack is currently offered.
keepstate.ai · the durable agent session cloud