Your accounts. Clear permissions. Visible actions.
How BriefWork protects your accounts and records your work.
What this means for you
- Connect services individually and remove BriefWork's access when you choose.
- Review the exact work before a send, publish or campaign launch.
- See who approved an action and what the provider confirmed in your work history.
- SOC 2 certification and SSO/SAML are not available today.
Disconnecting a tool stops future BriefWork actions through that connection. Work already running in the provider account may need to be stopped there separately.
Security details
Credentials
The planner never receives a decrypted credential. Connections store a handle, not a secret, executors resolve it through a credential broker at the moment of the call. The component deciding what to do and the component holding the keys are deliberately not the same component.
Per-workspace tokens are encrypted at rest and never written to logs. You can revoke any connection yourself. Disconnecting removes BriefWork's stored credential and prevents future BriefWork execution through that connection. It does not claim to revoke the token inside the provider or stop work already running there; those provider-side controls remain available in the provider account.
Workspace access
Row-level security is enabled, but it is defence in depth and not the boundary, the server uses a service role, and a service role bypasses RLS. Saying otherwise would be the kind of claim that sounds reassuring and is not true.
Signed sessions resolve the current workspace from membership, and every state-changing account, connection, audience, approval, and settings path checks the required workspace role before it writes. Cross-tenant authorization and database-isolation tests run in the project test suite. RLS is there so that a leaked anonymous key is not also a data breach.
The audit log
Every action the agent takes is written to an append-only log with the actor, the risk class, the state before and after, and a hash chained to the previous entry. Append-only is enforced by database permission and trigger, not by convention: updates and deletes raise an exception rather than being merely discouraged.
The database has a separate, 30-day retention boundary for raw provider evidence when a workflow elects to store it. Current connector paths generally retain the redacted audit summary and provider identifiers rather than copying full request and response bodies into that evidence table.
What the hash chain does not prove
It proves entries have not been altered in isolation. It does not prove we did not rewrite the whole chain. Optional external anchoring can publish one signed daily chain head, without audit payloads, and records success only after acknowledgement. It proves that published prefix existed; it does not make the rest of the chain tamper-proof.
Not built yet
- SOC 2. Evidence collection runs from launch. The report does not exist yet, and mid-market customers who need one should wait for it.
- SSO and SAML. Not built. This is the other half of why mid-market is deferred.