Slaunt security model for agent developers - Slaunt

Isolation

Workspace and project scope come from the OAuth token and are enforced by row-level security in the database, so a request can’t reach another workspace’s data by changing arguments. MCP sessions are bound to the user and client that created them. Thread boundary values and native thread IDs are stored only as scoped hashes.

What’s stored

Data	Stored	Not stored
Context events	Summary (≤20 words), tags, actors, provenance link	Transcripts
Lifecycle	States, activity text, progress, spend estimate
Codex lifecycle hooks	Event metadata	Prompts, tool I/O, replies; `cwd` and `transcript_path` are discarded
Chats	Prompts, final replies, tool I/O	Only if capture hooks or `chat_capture` are used

Chats

Chat content is the most sensitive data Slaunt holds, so it’s handled separately:

Encrypted per event with AES-256-GCM. This is server-side encryption: the backend and authorized workspace viewers can read it; it isn’t end-to-end.
Before encryption, known secret formats are redacted: bearer and provider tokens, JWTs, credentialed URLs, private keys and structured secret fields. A secret typed as plain prose may not be recognized.
Reasoning fields are dropped.
Chat content never feeds Context extraction, analytics or session replay.

If you’re building a capture bridge, filter out system prompts and anything workspace members shouldn’t see before sending it.