Security
Everything here describes the product as it's built today, and anything unfinished is marked. Send this page to a client when their security questionnaire arrives.
The four denials
No model is immune to prompt injection, so we don't rely on asking: we limit what the agent can reach. Here are four things the system refuses to do, and how finished each one is.
The agent's container can reach only the model API, through an allow-list proxy, and our tool proxy. Eight probes run on every deploy, and the deploy fails if one gets through.
Not yet: blocking and testing DNS exfiltration.
Tool and Slack tokens stay encrypted in the control plane. The agent holds only a 15-minute pass to the tool proxy, which adds the real token on the way out.
Not yet: catching a key someone pastes into a message.
Approving will mint a signed record bound to the draft's fingerprint. A missing approval, or a single changed byte, will be refused.
Today: the agent holds no channel credential, so the worst a prompt injection gets you is a draft nobody approved.
Separate storage and one encryption key per brain, with access scoped to the client it belongs to. Credentials for one brain have no permission on another brain's storage or key.
Also per brain: Slack app, agent container, tool connections and sessions.
Security, honestly
We won't claim a security property the product doesn't have. Use this list for your clients' questionnaires.
Being evaluated: encryption keys held by you.
Internal security review completed, fixes merged.
Why not a chat tool?
| Question | Chat tool, one project per client | Brainstead |
|---|---|---|
| Where client material lives | One shared workspace, kept apart by folders and naming | Its own storage and its own encryption key |
| Who can post on the client's channels | Whatever you've connected it to | Not the agent. It holds no channel credential and writes drafts only |
| Access to your tools | Whatever was granted when it was connected | Read-only by default; write is a per-tool switch, logged |
| The client's voice | Pasted into each brief | Kept in the brain: their site, brand files and skills |
| Unsupported claims | Up to the reviewer to spot | Marked [NEEDS-FACT] in the draft, with notes for the reviewer |
In a dedicated cloud solution: each client has its own storage, encryption key and secrets. Model calls go to the frontier model you choose.
Each brain has its own storage and its own key, and one brain's credentials have no permission on another's. Sessions, tool connections, Slack apps and agent containers are per brain too.
It has no credential to post with. What it writes is a draft in a queue. Once signed approvals ship, publishing will also require an approval bound to that exact draft.
Today, only the brain's owner. Anyone else gets "not found", so the brain's existence isn't even confirmed. Roles for the rest of your team and view-only access for clients are in development.
A frontier model by default, or the one your client chooses, on their own subscription or API key. The key is write-only: no screen or API shows it again.
Its agent is stopped, every stored version of its files is deleted, its tool connections are removed, and its encryption key is scheduled for deletion. Each step is logged.
A brain is plain markdown files: knowledge, brand voice and skills. They're yours, in a format any tool can read.
It isn't immune to prompt injection: it limits what an agent can reach and puts a person before anything goes out. It isn't a publishing or scheduling tool. And it isn't certified yet: no SOC 2, no pentest.
Ask us in a demo, or write to hello@brainstead.si. If we haven't built it, we'll say so.