A workspace is a data boundary
Company-owned records carry a workspace identifier. Application queries are tenant-scoped and PostgreSQL row-level security provides defence in depth.
Loading Beetl…
Plain-language data care
Your organisation's knowledge is the reason Beetl is useful. Caring for it means limiting access, making processing understandable, keeping people in control and being honest about what is implemented today.
The data journey
Data care is not one lock icon. It is a sequence of decisions and checks that should remain understandable from end to end.
Your team chooses what to write, upload, import or connect. Beetl does not silently reach into unrelated company systems.
Every workspace request starts with trusted identity and membership. Roles determine which actions are available.
Search, recommendations and Beetl assistance work with the authorised knowledge needed for that task—not the complete company estate by default.
Recommendations stay separate from editing and publication. People inspect the evidence and decide what changes.
Workspace owners can export data, configure supported retention periods and request deletion through an audited lifecycle process.
Implemented safeguards
These statements describe application behavior in the product, not a future security wishlist.
Company-owned records carry a workspace identifier. Application queries are tenant-scoped and PostgreSQL row-level security provides defence in depth.
Membership and role checks happen on the server. Public knowledge queries return only published content from explicitly public knowledgebases.
Private files require an authenticated workspace member and are served with private, no-store caching. Public delivery is limited to authorised published uses.
Approved connector credentials are encrypted with authenticated AES-256-GCM encryption and bound to their connector context before storage.
Important administrative, publishing, connector and lifecycle actions produce audit records so material changes can be investigated.
Uploads carry security-scan state, private storage is required for deployment, and unsafe content is never treated as trusted instructions.
When you ask Beetl for help
Beetl first resolves the exact workspace and knowledgebase, checks visibility, and retrieves authorised published sources. Selected excerpts are marked as untrusted content before they are sent to the configured model provider.
Beetl requests that response storage be disabled for its AI requests. This does not guarantee zero provider retention: monitoring records and other provider-held data follow the applicable provider terms and settings. Generated answers and retrieved private content are excluded from ordinary product logs. Questions and selected source-version identifiers may be retained; writing and learning features can also save generated drafts and provenance in the workspace.
Provider processing, regional availability and any legally required provider monitoring are reviewed as part of a production agreement. Beetl does not train its own model on your workspace knowledge.
Retention, export and deletion
Owners can configure supported retention periods for analytics, feedback, learning progress, evidence and Beetl interaction records. Learning responses, evidence and certificates have separate rules; legacy learning progress remains pending verified migration. A setting does not guarantee deletion of every related record. Backup, provider and operational-log periods require separate verification.
Workspace owners can create a structured export before a deletion request. The signed link expires after 10 minutes, uses private no-store delivery and rechecks owner membership at download time. The archive includes workspace JSON, assessment responses, learning evidence metadata, certificate records and safe uploaded file bodies. Unsafe or unscanned files are listed but excluded. A completion receipt lists file checksums; a missing file fails the download. Provider copies, backups and separately retained records still require a separate privacy-rights process.
Organisation deletion requires an owner request, confirmation and cooling-off period. Once a confirmed request is due, the lifecycle job removes eligible tenant database records and queues private-object cleanup. Failed cleanup remains queued for retry. Global account records, lawful retention exceptions, provider copies and backups need separate handling; deleting a workspace is not proof that every copy has been erased.
Email Heinzhambrock@gmail.com for access, correction, deletion or a privacy complaint. Tell us the request type and relevant workspace, without attaching passwords, identity documents or unnecessary private content. Organisation-controlled records may require your organisation's instructions. You may also contact the relevant data protection authority; contacting Beetl first is not a condition of doing so.
Production operations
Before customer data is admitted, Beetl's production readiness process requires HTTPS, restricted database networking, private object storage with encryption at rest, managed encrypted backups, monitoring, incident ownership and a tested restore procedure.
The final provider, processing region, backup window and approved retention terms are deployment decisions. They should be stated in the customer agreement rather than hidden behind a generic badge.
NEXT STEP
Tell us what your organisation needs to validate—data location, providers, retention, deletion, access control or implementation architecture.
