Beta
Trust
Bokeh works on material that is not ours: your scripts, your footage, your generations. This page says what the system does with them. Everything below describes behaviour that exists in the code today — not policy we intend to adopt.
You bring your own keys
Generation runs on API keys you supply for the providers you choose. Bokeh does not resell model access, mark up generation, or route your work through accounts you cannot see. Your keys, your provider accounts, your spend — visible per generation, per section, and per project inside the app.
Department-facing screens never show a key, a base URL, or a raw model identifier. Key entry lives in one settings surface, reachable only by the people who set the project up.
Keys are encrypted, and stay server-side
A key you save is encrypted immediately (libsodium sealed-box) and only the ciphertext is stored. The database revokes the ciphertext column from every browser-facing role, so no client — including yours — can read it back. The only thing the app will ever show you is the last four characters.
Decryption happens server-side at the moment a job is dispatched to a provider, and nowhere else. Key operations are excluded from the activity feed by a central rule, so the feed cannot leak that a key exists, let alone its value.
Honest limit: the master encryption key currently lives in server configuration, not a cloud KMS. Moving it to a managed KMS is on the pre-production hardening list, and this page will say so when it has happened — not before.
No training on your material
Bokeh does not train models, fine-tune models, or build datasets from your scripts, breakdowns, images, or footage. The evaluation corpus we use to measure the breakdown engine is built exclusively from material Bokeh holds the rights to, and the code that touches training-adjacent tooling refuses anything else by default — unlisted material is treated as yours, full stop.
What Bokeh cannot promise for you: the AI providers you connect receive your prompts and reference media under your account and their terms. Choose providers whose data policies you accept; Bokeh sends them nothing except what your generations require.
Deleting a project deletes it
Project deletion removes every stored file first — the script source, every reference image, every take, every export bundle — and only then removes the database rows, which cascade through scripts, scenes, breakdowns, entities, generations, shots, takes, audio, comments, and the activity history. If any stored file cannot be removed, the deletion stops and tells you, rather than reporting success while bytes remain.
Deletion is producer-only and requires typing the project title. There is no soft-delete copy retained.
Contributors see their sections, and nothing else
A contributor — a freelancer you bring in for one department — can read their assigned sections and the scenes their entities appear in. Not the full script. Not the risk register. Not other departments' work, other people's conversations, cost figures, or the project roster. This is enforced in the database as row-level security, not hidden in the interface: a contributor querying the API directly gets the same denials the screens do.
That boundary is covered by automated tests that sign in as a real contributor against the real database and assert both directions — what they can reach, and what they cannot — across every surface in the product, including shots, takes, audio, generation media, and export bundles.
Every decision is on the record
Every mutation in Bokeh flows through one command path that writes an activity row: who tagged what, who approved, who sent back and why, what was generated and selected and exported. A project's history can be reconstructed chronologically from that log — and when you delete the project, the log goes with it.
Not yet true, stated so you don't have to wonder: an external security review of the key vault, auth, and row-level security is planned before launch and has not happened yet. Bokeh is in beta.