Security overview
Permissions are never bypassed.
BeBrief is built around one invariant: a user can only receive answers derived from documents they're actually permitted to access. This isn't a UI-layer filter — it's enforced at the vector search level.
The two-layer ACL model
Layer 1 — Admin flag
The is_admin flag on the user record controls access to the Admin UI (/admin). Admin sign-in requires Google or Microsoft OAuth. Admins manage connectors, users, and tenant settings.
Layer 2 — Document ACLs
Every document in the vector store carries an acl_allow payload field. At query time, user identity is resolved to a set of ACL grants, and the vector search is filtered to only documents where acl_allow intersects the user's grants.
ACL format reference
Document grants (stored per chunk in the vector store)
"public" Any authenticated org user can access
"confluence_space:ENG" Any user linked to this Confluence space
"confluence_user:{accountId}" Specific Confluence account holder only
"confluence_group:{name}" Members of a named Confluence group
"slack_channel:{channelId}" Members of a specific Slack channel
User identity grants (resolved at query time)
user.acl_grants = [
"public",
"user:[email protected]",
// Slack channels Alice is a member of
"slack_channel:C0123ABCD",
"slack_channel:C0456EFGH",
// Confluence access
"confluence_space:ENG",
"confluence_space:PRODUCT",
"confluence_user:5b109f2e9f8...",
"confluence_group:engineering",
]
// Vector search filter:
// doc.acl_allow INTERSECTS user.acl_grantsGrants are resolved just-in-time at each query and kept current. Permission revocations propagate rapidly — users lose access within one permission-sync cycle, with no window where a stale grant persists.
Just-in-time permission resolution
Most systems compute and cache permissions upfront. BeBrief resolves them at the exact moment of each query — against live data from your connected sources.
No pre-computed access lists
Permissions are not assumed from a snapshot. Every query triggers a fresh resolution of the user's identity and their current grants.
Revocations take effect rapidly
Remove a user from a Confluence page or Slack channel and the change propagates on the next permission-sync cycle — not hours or days later.
Fail-closed by default
When BeBrief cannot resolve permissions, it defaults to treating content as restricted. Access is never assumed — it must be explicitly granted.
Identity, not platform privilege
The org admin who installed BeBrief does not automatically gain access to restricted content. Access is tied to the user's own identity, resolved through email matching.
JIT resolution flow (per query)
User sends a message to @BeBrief in Slack
BeBrief resolves the user's email and linked Confluence account ID
Current Slack channel memberships are fetched and added to the user's grant set
Confluence page-level restrictions are intersected with the user's grant set
Vector search executes with the resolved grants as a hard ACL filter
Only permitted documents reach the LLM — restricted content never appears in answers
Access is tied to the actual document owner — not whoever manages the platform
When Confluence restricts a page to a specific user, that restriction references a Confluence account ID. BeBrief resolves this to a real person by fetching your complete Confluence user directory and matching by email address.
A page restricted to [email protected] will only surface in answers to the BeBrief user whose registered email is [email protected] — not to any org admin, not to anyone who merely has administrative access to the platform. There is no privilege escalation path through platform administration.
Ephemeral delivery for restricted content
When an answer is derived from restricted documents, BeBrief delivers it as an ephemeral Slack message — visible only to the querying user, never stored in channel history.
Posted in channel
None
All context documents have "public" in their ACL. The full answer is visible to everyone in the channel.
Ephemeral only
✅ reaction
One or more context documents require specific ACL grants. Only the querying user sees the answer. A ✅ reaction on the query confirms delivery.
Permission message
Ephemeral
Restricted content exists and matches the query, but the user's identity lacks the required grants. BeBrief informs the user they don't have access — never reveals document content.
Zero data egress
BeBrief runs LLM inference on our own managed servers. Your documents are never sent to OpenAI, Anthropic, or any other AI provider — and never will be.
- Embeddings generated on BeBrief-managed servers
- LLM inference on BeBrief-managed servers
- No OpenAI / Anthropic / Google AI API calls
- No data sent to any third-party AI company
- Bring Your Own Storage — coming soon
- Enterprise: custom deployment options available
Data flow
Multi-tenant isolation
Each organization is isolated at the data layer — not just the application layer.
Relational database
Row-level security enforced at the database layer. All records are scoped per tenant — no application-level filtering required.
Vector store
Separate vector collection per tenant. Cross-tenant queries are architecturally impossible, not just access-controlled.
Object storage
Separate storage bucket per tenant for raw indexed content. Isolated at the infrastructure level.
Permission cache
Cache keys namespaced by tenant. Permission grants are scoped per tenant and never shared.
Confluence identity auto-linking
BeBrief automatically links Slack users to their Confluence identities using email matching — no manual configuration required.
Permission-sync fetches all Confluence users from your connected Atlassian site (requires read:user:confluence scope).
Users are matched by email address to BeBrief's internal user records.
Matched users get an IdentityMapping record linking their BeBrief user ID to their Confluence accountId.
At query time, the Confluence accountId is included in ACL resolution, granting access to page-restricted documents.
Vulnerability Disclosure
Reporting a security issue
If you believe you've found a security vulnerability in BeBrief, please disclose it responsibly. We review every report and respond within 5 business days.
How to report
Send an email to [email protected] with the subject line "Security Disclosure". Please include a description of the issue, steps to reproduce, and any relevant screenshots or logs.
Scope
In-scope: authentication and authorisation bypasses, cross-tenant data leakage, injection vulnerabilities in API endpoints, permission enforcement failures. Out of scope: denial-of-service attacks, rate limit bypass without data access, issues in third-party dependencies with no demonstrated impact.
Our commitment
We will acknowledge your report within 5 business days, keep you informed of our progress, and notify you when the issue is resolved. We will not take legal action against researchers who report issues in good faith.
Recognition
We do not currently operate a paid bug bounty programme. Researchers who responsibly disclose valid vulnerabilities will be acknowledged by name (if desired) once the issue is resolved.
Security questions?
We're happy to walk through the architecture with your security team.
[email protected]