Prepared for customer security and procurement review. Every control below is one that exists today; section 10 is the list of what does not.
LAST UPDATED 19 AUGUST 2026
Brekfuz is an enterprise knowledge platform. It connects to an organisation’s Gmail, Google Calendar and Slack, indexes that content, and allows authorised users to query it and receive answers grounded in their own organisational records.
The platform therefore processes sensitive material, and has been engineered accordingly. This document sets out those controls, and states plainly which controls are not yet in place.
Brekfuz requests read-only permissions: gmail.readonly, calendar.readonly and admin.directory.user.readonly.
The platform cannot send, reply to, forward, edit, move or delete anything in your Gmail or Calendar, and it never sends mail from your address or on your behalf. No write permission exists to revoke, because none is requested.
Slack is the one surface where Brekfuz writes, and it writes only as itself. The application holds a narrow permission set: read message history in channels it has been granted access to, post replies and reactions in those channels, and resolve user names and email addresses. Every post is attributed to the Brekfuz app — it cannot post as a user, send direct messages from a user’s account, or edit or delete anyone’s messages. Brekfuz is installed directly by your workspace administrator and is not distributed through the public Slack App Directory.
Access can be revoked at any time from your Google Account or Slack administration console, without involving Brekfuz.
This is the principal control in a multi-tenant platform and has received corresponding engineering investment.
Every table holding customer data has row-level security switched on and forced, so the database refuses to return another customer’s rows even if our application code asks for them incorrectly. This covers 81 of 84 tables in our main database and 25 of 26 in our memory service. The three exceptions hold no customer content.
All three of our services run a check when they boot and refuse to start if row-level security is off on any table, or if the database account they’re using is capable of bypassing it. A scan also runs against the live database catalogue, so a newly added table cannot quietly slip through.
Each customer’s search data lives in its own physically separate namespace, not in a shared index filtered by a query.
Calls between our internal services carry a signed token tied to a specific customer, request and payload. Gmail content is encrypted with the customer’s identifier built into the encryption itself — a record copied into another customer’s account will not decrypt.
We run automated tests against a real database using a restricted account, which confirm that one customer cannot read or write another’s data even with the safety filters removed from the query.
Where it’s enforced in code instead: two surfaces — our Slack webhook handler and our graph database — enforce separation in application logic rather than at the database layer. We’re closing that gap; see section 10.
In transit: everything leaving our network uses TLS.
Gmail content: encrypted by Brekfuz before it’s written to the database, using AES-256-GCM envelope encryption with keys in AWS Key Management Service. Keys rotate annually. Email addresses are stored as one-way cryptographic fingerprints rather than in readable form, and a database rule rejects any Gmail record that isn’t properly encrypted.
Stored credentials: encrypted the same way.
Everything else: protected by the storage-level encryption our cloud providers apply, plus the separation controls above.
BREKFUZ DOES NOT CLAIM END-TO-END ENCRYPTION. THE PLATFORM DECRYPTS CONTENT IN MEMORY IN ORDER TO INDEX IT AND TO RESOLVE QUERIES.
Deletion is among the platform’s more mature controls.
Any customer administrator can request erasure for a specific person. The request requires a second administrator to approve it before it runs. Once approved, we remove that person’s content from our primary database, our search index and our graph store, track each of those independently, and issue a signed deletion certificate recording what was removed.
Closing an account removes the organisation’s content from our systems.
Backups are held for disaster recovery and overwritten on their normal cycle; deleted content can persist in a backup until that completes.
We do not currently have automatic time-based deletion. Content stays indexed until it’s deleted on request or the account closes. If your policy requires a fixed retention period, tell us and we’ll agree one contractually.
Application and primary database in AWS US East (Ohio). Search index in Google Cloud US Central. All AI providers are US-based.
EU and UK data residency is not available today. For UK/EU customers, our Data Processing Agreement includes Standard Contractual Clauses covering the transfer.
Customer content is sent to OpenAI for answer generation and search indexing, to Cohere for re-ranking results, and optionally to Anthropic. The full list is on our subprocessor page.
Brekfuz does not train any models. These providers do not train on data submitted through their APIs under their standard terms. Separately, Google’s Limited Use rules prohibit us from using Gmail content to train or improve any generalised AI model, and we comply — see our Privacy Policy.
We are formalising written zero-retention commitments with each provider — see section 10.
We have documented procedures for isolating a compromised integration, revoking credentials and rotating secrets.
We commit to notifying affected customers without undue delay and within 72 hours of confirming a security incident involving their data, with what we know, what we’ve done, and what we recommend.
Report a suspected vulnerability to support@brekfuz.com.
Disclosure. In May 2026, Composio — a vendor that manages some of our tool connections — disclosed a security incident affecting connected accounts. We executed our containment procedure, revoked and reissued credentials, and reviewed the affected connections. Enterprise customers can avoid this dependency entirely by connecting Google Workspace directly, as described in section 9.
Connect Google Workspace using domain-wide delegation. Your own Workspace administrator grants access with credentials your organisation controls, and those credentials are encrypted and bound to your domain.
This removes any third-party broker from the connection to your email and calendar, and keeps the grant fully under your admin’s control. We recommend it for every enterprise deployment.
We disclose these proactively rather than leave them to be surfaced during a security questionnaire.
| Control | Status |
|---|---|
| SOC 2 | Not commenced. Brekfuz will commit to an audit timeline contractually and will accept a right-to-audit clause in the interim. |
| Penetration test | Not yet commissioned. Automated security scanning currently gates every build. |
| MFA on admin accounts | In progress. |
| Automatic retention limits | Not implemented. Deletion is performed on request. |
| EU data residency | Not available. Covered contractually by Standard Contractual Clauses. |
| Internal access logging | We log every change to customer data in a tamper-evident record. We’re extending this to cover internal read access. |
| Cyber liability insurance | Being procured. |
WE LIST WHAT’S BUILT, NOT WHAT’S PLANNED. IF A LINE ON THIS PAGE STOPS BEING TRUE, IT COMES DOWN THE SAME DAY.
support@brekfuz.com — security questions, vulnerability reports, and privacy and data requests.
Brekfuz is available to meet with your security team and to complete your standard security questionnaire.
We are available to meet with your security team and to complete your standard security questionnaire.
Ask us anything Back to the site FOUND SOMETHING WE GOT WRONG? SUPPORT@BREKFUZ.COM · WE ANSWER FAST