Evidence that survives the people who hold it. Including us.
Stratl is built on three properties, not on one cloud: a key service that signs but never releases a private key, storage that keeps every version and gives our service no way to delete, and a timestamp from someone who is neither you nor us. Everything on this page follows from those.
Your systems
agents, SDKs, capture points- Original content
- Ingest keys (write-only)
Stratl service
API, search index- Fingerprints and metadata
- Chain heads and checkpoints
Your custody
key service and object storage, in your chosen region- Signing key, never exportable
- Signed records, every version
- Content, if you send it
Outside parties
timestamp authority, any verifier- Timestamp tokens
- The public key and the checks
- records, fingerprinted on your side
- read access for ingest keys
- sign this
- write this
- read this back
- export the key
- delete anything
- change a policy
- one fingerprint of each checkpoint
- the public key, in every bundle
- any record, content or identifier
Our service can do four things to your custody. Here are the five it cannot.
Security starts with what the service is not allowed to do. Its permissions on your key and your storage are written down in an access policy, and this is that policy in plain words.
- Ask the key service to sign
One request, one signature. The private key never leaves the service that holds it.
- Read the public key
So it can be published and packed into every bundle.
- Write records, checkpoints and content
Under the workspace's own prefix. Writing again keeps the earlier version.
- Read them back
To build the bundles, notices and packs you ask for.
- Export, copy or wrap the private key
The permission does not exist, and the key service does not offer it for this key type.
- Delete, disable or re-policy a key
Not granted to the service.
- Delete a stored object or version
Not granted to the service. Storage keeps every version.
- Make anything public
Public access is blocked at the storage level.
- Put raw content in the search index
The index accepts fingerprints and metadata only.
Every use is on the record. The key service logs each signing request in its own audit trail, which we do not control. Each request is also noted by Stratl, with what was signed and the provider's request id, and sealed at every checkpoint into a signed key-usage record in your stream, so the log lives with the evidence and verifies offline.
A copy of our database gives an attacker nothing to sign in with.
There are no passwords. Every secret that touches Stratl is either stored as a one-way hash or not stored at all.
keyed hash (HMAC) of email and codenothing usable: cannot be reversed or replayedSHA-256 of the token, plus user agent and IPcannot forge a cookie from the hashSHA-256 and the last four characterscannot reconstruct a key; a leaked key can only writenothing: only the public key and the key's idno copy exists to steal, here or anywherethe fingerprint in the index; originals only if you send them, in your custodythe index reveals no contentChange one record and everything after it says so.
Each record carries the fingerprint of the one before it. Every hour, or every thousand records, a signed checkpoint seals them all and an outside authority stamps the time. Try it.
- DEC-…48211sha256:e393…prev —signed
- DEC-…48212sha256:198a…prev e393signed
- DEC-…48213sha256:129a…prev 198asigned
- DEC-…48214sha256:8ab4…prev 129asigned
- DEC-…48215sha256:8385…prev 8ab4signed
- DEC-…48216sha256:b4b3…prev 8385signed
Chain intact. Every record's fingerprint is what the next one expects, and the checkpoint covers all six.
Seven things that could go wrong. Which layer answers each.
Including things that could go wrong with us. Filled dots are the layers that hold when that threat happens. Pick a row to read what happens.
| Threat | Workspace scoping | Write-only keys | Non-exportable signing key | Versioned, delete-proof storage | Hash chain and checkpoints | Outside timestamp | Offline verifier |
|---|---|---|---|---|---|---|---|
What happensIts fingerprint and signature no longer match, the next record names the old fingerprint, and the sealed checkpoint still holds the original.
What happensThey cannot export or replace a key, cannot delete through the service, and cannot move a timestamp issued by someone else.
What happensThey gain what the service has: signing requests and writes. Not key export, not deletion, not the rewriting of sealed history.
What happensThe holder can write, never read. Forged records carry their time and key in the chain. Revoke the key and writes stop.
What happensTen-minute codes, five attempts, five codes per address per window, sixty seconds between sends, stored as keyed hashes.
What happensEvery query is scoped to one workspace. A foreign record answers exactly like a missing one.
What happensRecords stay in your custody. Every bundle carries its key, proof and timestamp. The verifier needs nothing from us.
The last check does not need our permission.
Every control above could fail and you would still be able to tell. The verifier runs on your machine, needs no account and makes no network calls. Each check is reported on its own, so a partial failure looks like exactly that.
Published standards only
RFC 8785 canonical JSON, SHA-256, ES256, RFC 7638 key ids, RFC 6962 Merkle trees, RFC 3161 timestamps. Nothing is ours to trust.
Three languages, one answer
Python, TypeScript and Go hash the same fixtures identically, proven on every change.
Bundles carry their own proof
The public key, the checkpoint, its timestamp token and a manifest travel inside the archive. Nothing has to be fetched.
Roles the design needs, and who fills them today.
The record format, the verifier and the integrity design are the same whichever provider sits underneath. This is the only place on the page where providers are named.
Custody region live today: India (AWS ap-south-1). The search index runs in one location for all workspaces; if its metadata must stay in a particular country for you, Stratl is not ready for that workload yet.
In place, and not yet, on one list.
A security page that only lists strengths is marketing. This list is reviewed on a date and says what is missing, so you can decide what to put on Stratl today.
- in placeTLS everywhere
Between you and the app, the app and the API, the API and every provider.
- in placeEncryption at rest
Server-side encryption on every stored object. Versioning on. Public access blocked.
- in placeSignatures verified before write
Every signature from the key service is checked locally against the public key before anything is stored.
- in placeSecrets never in the repository
Credentials arrive as environment variables or secret references. Production refuses to start with a default secret.
- in placeLint and tests on every change
Python, TypeScript and Go, plus a conformance check that all three hash records identically.
- in placeContent never logged
Logs carry paths, identifiers and errors. Never prompts, outputs or payloads.
- not yetSOC 2 or ISO 27001 attestation
Planned. Until then, this page is the control description.
- not yetIndependent penetration test
Before the first enterprise contract.
- in placeDependency and secret scanning in CI
Every change is scanned for leaked secrets and for known vulnerabilities in Python, JavaScript and Go dependencies. Dependabot opens the upgrade. Coordinated disclosure is described in SECURITY.md in each repository.
- not yetSingle sign-on and SCIM
Not built.
- in placeEach key use written as a record
Every signature request is noted, with what was signed and the provider's request id, and sealed at each checkpoint into a signed key-usage record in your stream. You can verify every use of your key offline and match it to the provider's audit log.
- in placeYour own key service and storage
Take custody from the portal: your bucket and your key on AWS, Google Cloud or Azure. Stratl keeps only the permission to sign and to write, proves it cannot delete before anything moves, and the hand-over is a statement signed by both keys.
Our advice during early access. Start with a staging agent or a low-risk workflow. Export bundles for anything you must keep. The early access page lists everything else that is unfinished.
Found something? Tell us before anyone else.
Write to hello@stratl.ai with "Security report" in the subject. A person reads it. Please do not include customer data, and do not test against workspaces that are not yours.
What we promise
- A human reply, and a fix or a plan within a stated time.
- Credit by name if you want it, once the fix is out.
- No legal action against good-faith research that follows these rules.
- If your report shows customer data was exposed, every affected workspace is told.
What we ask
- Test only against your own workspace.
- Do not read, change or delete data that is not yours, and stop as soon as you can prove the issue.
- No denial of service, spam or social engineering of our people.
- Give us reasonable time to fix before you publish.
What security teams ask.
Does the design depend on one cloud?
No. It depends on three properties: a key service that signs but never releases private keys, object storage that keeps every version and gives our service no delete permission, and a timestamp authority independent of both of us. Today those are provided by AWS KMS, Amazon S3 and a public RFC 3161 authority. The record format, the verifier and the integrity design do not change when the provider does.
Where exactly is my signing key, and who can use it?
Inside the key service, in the custody region you chose, as one key per workspace. It cannot be exported by anyone. The Stratl service holds a permission to sign and to read the public key, and nothing else. The provider logs every use.
Can Stratl read my prompts and outputs?
Only if you send them. The SDK fingerprints content on your side. If you also send the originals so they can be re-hashed later, they go to your custody storage under their fingerprint, never into the search index. Our operators look only when you ask for help.
What if the key service is unavailable?
Nothing is written. Signing happens before a record is chained and stored, and a failed or unverifiable signature stops the write. The SDK spools the record locally and sends it again later.
What if the timestamp authority is down?
The checkpoint is still signed and stored, marked as awaiting a timestamp, and the timestamp is retried on later runs. The verifier reports a missing timestamp as a failed check, not a warning.
Can I delete records?
Not through the service, and neither can we through it. A person at Vyana Compute carries out deletion when you ask, and only for records your workspace's retention policy says are past retention. A legal hold, placed on a decision or on everything about a subject, blocks deletion of what it covers until it is lifted; placing and lifting are themselves signed records in the chain. If the storage has a retention lock, locked versions cannot be removed until the lock expires.
Is there a bug bounty?
Not a paid one yet. We do promise a human reply, credit if you want it, and no legal action against good-faith research that follows the rules on this page.
Verify it yourself.
Record one decision from a real agent, export the bundle, and run the verifier on a machine with the network unplugged. That is the whole argument.