Security
Is my unpublished work private?
Short answer: yes. Here is the mechanism rather than the reassurance — what actually stops a script, a draft or a channel key reaching anyone else.
Defense in depth
Four answers, and what is behind each
Your voice is made here
Speech is generated on our own machines. A script you have not published is never sent to a speech vendor, because there is no speech vendor in the path.
One workspace cannot see another
Every piece of work carries the workspace it belongs to, and the database itself refuses a query that reaches outside it — not the application. That distinction is the point: application code can have a bug, and this stops a bug becoming a leak. The rules are checked against the live database every time the schema changes, not only against a test copy.
Your channel keys are yours
The token that lets Rookery publish to your channel is sealed with AES-256-GCM under a key belonging to your workspace alone, wrapped by Google Cloud KMS. A fresh random IV on every write, integrity checked on every read, and the workspace id bound into the encryption itself — so a copy of the database does not open it.
Closing your workspace deletes the work
Not just the login. The records and the files both go — you type the workspace name to confirm, and nothing is removed until you have.
Publishing tokens
Sessions, not secrets
RookeryOS never asks you for a developer token and never stores a raw API key. You authorise the connection with the platform itself, and what comes back is sealed with a key belonging to your workspace before it is written down.
- AES-256-GCM authenticated encryption, a fresh random IV every time
- A data key per workspace, wrapped by Google Cloud KMS
- Your workspace id bound into the encryption, so the key opens nothing else
- The API holds no credential that could read another workspace
- 1 · You authorise the channel with the platform
- 2 · It returns a token; the raw value is never logged
- 3 · Your workspace key is unwrapped by Cloud KMS
- 4 · Sealed with AES-256-GCM and a fresh random IV
- 5 · Stored sealed; the auth tag is checked on every read
- → Your workspace id is part of the encryption, so no other key opens it
Operating principles
Safe by construction
A new password ends every other session
Changing it does not just change it. Every sign-in that existed before stops working, on every device — which is the whole point, because the usual reason to change a password is that somebody else may have it. You are handed a fresh session so you are not signed out by your own action.
Playback links expire
A link to your video is a bearer credential: anyone holding it can play the file. So they are minted for minutes rather than forever, and every one is re-checked against your workspace at the moment it is signed — not when the record was written.
Uploads and finished work are kept apart
What you upload lands in one bucket and what plays back is served from another. Nothing crosses until it has been processed, so bytes that arrived from a browser are never served as though we had made them.
This page summarizes the platform's security architecture. For implementation detail, see the Security Model documentation .
Security questions?
We're happy to walk security and compliance teams through the architecture in detail.