Security & trust.

Architecture

Bruno runs in three independently scaled tiers:

• Widget - a small JavaScript bundle loaded from our API host. It renders inside a Shadow DOM on your site, talks to our API over HTTPS / WSS, and is fully isolated from your page's CSS and globals.
• API & workers - the backend services that handle authentication, knowledge ingestion, embeddings, retrieval, model orchestration, and billing.
• Storage - a managed encrypted database (with vector search for embeddings) for structured data, managed object storage for uploaded files, and a managed in-memory store for sessions and job queues.

All public traffic is HTTPS / WSS in transit. Service-to-service traffic inside our infrastructure is private-network only.

Consent & safety rails

Bruno's hybrid actions are gated. Several invariants are enforced in the widget itself, not just the server:

• Explicit consent for every action that mutates the page. The visitor sees a consent card with the action type, target description, and reason.
• 3-second preview - Bruno highlights the target element before performing the action so the visitor can cancel.
• Password fields blocked - the action runner refuses to fill, click, or interact with any input of type password.
• Same-origin only for navigation. Cross-origin links are explained in chat instead of clicked.
• "Allow all this session" is opt-in - never pre-selected. It expires when the panel closes.
• Hard cap on multi-page continuations (5 hops by default).
• Activity gating - the assistant pauses when the panel is closed; it cannot operate "in the background".

Encryption

Encryption at rest and in transit is on by default:

• In transit: HTTPS (TLS 1.2+) for all public traffic, WSS for chat sockets.
• At rest: database storage is encrypted at the volume level by our hosting provider. Uploaded files are written to managed object storage with server-side encryption enabled by default.
• Secrets: API keys, session-signing keys, and database credentials are stored in a managed secret store and never logged.

Tenant isolation

The fundamental tenant in Bruno is the website, not the user. Every read and write is scoped to a website ID, enforced at the application layer:

• Conversations, knowledge, embeddings, prompts, and billing are all keyed by website.
• Background jobs carry the website ID in their payload and re-check authorization before reading.
• The widget is bound to a single embedKey; the API verifies that the requesting origin is allowed for that key.

Knowledge bases never cross-contaminate across websites - even within the same customer account.

Data flow

For each turn:

1. The widget extracts a redacted page summary (title, headings, visible interactive elements, same-origin links). Form values are not extracted.
2. The widget posts the visitor's message and the page summary to the API.
3. The API retrieves the most relevant chunks from your knowledge base (vector + lexical) and assembles a prompt.
4. The prompt is sent to our model gateway for inference. We record the request id and token counts for billing; full prompts and replies are kept only as needed to operate the Service.
5. The model's response is streamed back to the widget. If the model proposes an action, the widget shows a consent card and the visitor decides.

The model gateway we use is contractually bound not to use your data for model training.

Data deletion

You stay in control of your data:

• Knowledge files. Delete a file in the dashboard and its content and embeddings are removed from our database and object storage.
• Websites. Deleting a website from your dashboard cascades through its conversations, messages, knowledge files, and embeddings.
• Account-level requests. To delete your account, or to request deletion or export of a specific visitor session, email help@bruno.support and we'll action it within a reasonable timeframe.
• Backups. Provider-managed backups are retained briefly for disaster recovery and are encrypted at rest. Data restored from a backup is removed again on the next normal cycle.

We don't yet expose self-serve retention windows or audit-log exports. When we add them they'll be documented here, in the dashboard, and in our Privacy Policy.

Access control

• Production access is restricted to a small number of Bruno engineers on a need-to-debug basis.
• Strong, unique passwords and short-lived session tokens are required for all internal tooling.
• Tenant scoping is enforced at the application layer: every read and write is keyed by website ID, including background jobs.

GDPR alignment

Bruno is built with European privacy regulations in mind:

• You are the controller for visitor messages and uploaded knowledge; Bruno is the processor. Our DPA spells this out.
• You can request export or deletion of any specific visitor session by emailing help@bruno.support.
• Data is processed in regions documented in our Subprocessors page. Standard Contractual Clauses apply where transfers are involved.

Authentication

• Customer dashboard accounts use email + password. Passwords are stored using a modern, memory-hard hashing algorithm with per-user salts.
• Sessions use short-lived signed access tokens with rotating, single-use refresh tokens stored in an HTTP-only cookie scoped to /v1/auth.
• Brute-force and credential-stuffing protection are enabled at the API edge via per-IP rate limiting on signup, login, and refresh.

Reporting security issues

If you believe you have found a security issue in Bruno, please email help@bruno.support with a clear description and steps to reproduce. We respond within 3 business days, will not pursue legal action against good-faith research, and will credit you in our changelog if you'd like.