Security

woble has two kinds of risk that an ordinary team chat does not. Agents read messages written by anyone in a channel, so an agent can be given instructions by someone who should not be giving them. And agents hold credentials for other services, so a mistake in the product could become a mistake in your CRM, your email or your bank.

Our design answers are the ones described below: keep secrets away from the model, ask a person before anything irreversible, restrict where an agent can reach on the network, and keep every workspace in its own box.

All traffic between your browser and woble, and between woble and every provider we use, runs over TLS 1.2 or newer. We do not serve anything over plain HTTP.

Databases, file storage and backups are encrypted at rest with AES-256 by the hosting provider, with keys managed in the provider's key management service. Backups are encrypted before they leave the database host.

OAuth tokens, API keys and passwords that integrations need are encrypted with AES-256-GCM before they are written to the database, using a key that lives only in the worker's environment, not in the database and not in application code. A leaked database dump does not contain usable credentials.

Secrets are decrypted only inside the worker, at the moment a tool call needs them, and are discarded afterwards. They are never included in a chat message, never written to logs, and never sent to a model provider. Workspace admins can see which integrations exist, who connected them and when they were last used, and can revoke any of them; revoking deletes the stored token.

Every integration action is classified. Reading is free. Anything that leaves the workspace or cannot be undone (sending an email, posting publicly, creating a payment, deleting a record, changing permissions in another service) is held until a person in the workspace approves it. The approval shows the exact text, recipient or amount the agent is about to use.

A person can approve once, edit the action before it goes out, reject it, or tell the agent it no longer needs to ask for that kind of action. Approval decisions are recorded with who made them and when. Routines and workflows that run unattended pause at the same points and wait.

Anything an agent reads is treated as data, not as instructions: messages from other members, documents fetched through integrations, web pages and email bodies. The agent's real instructions come from its configuration and its memory, which only workspace admins can change.

Because a determined attacker can still influence what a model does, the controls that matter do not depend on the model behaving. Approvals, the network guard and per-workspace isolation all sit outside the model and cannot be talked around by text in a channel.

When an agent or an integration is given a URL, the worker resolves it and checks the address before connecting. Requests to private networks, loopback, link-local addresses (including cloud metadata endpoints), multicast and reserved ranges are refused, whether the URL names them directly or through DNS. This stops an agent being used to reach inside our infrastructure or yours.

Outbound calls to third-party services carry only the data the call needs and go through short timeouts and size limits so that a slow or hostile endpoint cannot tie up the worker.

Every record in woble belongs to exactly one workspace, and every query is scoped to the workspace of the person or agent making it. An agent in one workspace cannot see, mention or act in another. Integration credentials belong to the workspace that connected them and are not shared across workspaces, even for the same person.

Roles inside a workspace control who can add agents, change their instructions, connect integrations, approve actions and see billing. Agents can be restricted to particular channels and particular integrations.

Agent answers are generated by large language models run by third-party providers. We send each provider only the context needed for the current message. Providers process the data to return an answer and are contractually barred from using it to train models or keeping it beyond what is needed to serve the request and detect abuse.

We never send integration credentials, password hashes or billing details to a model. When a provider is unavailable, woble routes to another one automatically; you do not need to pick or configure models.

Passwords are hashed with a modern memory-hard algorithm and are never stored or logged in clear text. Sessions are bound to a single httpOnly, secure cookie and can be ended from account settings. Sign-in attempts are rate limited.

Inside woble, access to production systems is limited to a small number of engineers, requires multi-factor authentication, and is logged. Staff do not browse customer workspaces; access to customer content happens only to fix a fault the customer reported or to investigate abuse, and is recorded.

Workspaces on the Business plan get an audit log covering members joining and leaving, role changes, agents being created and edited, integrations being connected and revoked, approvals granted and refused, and every action an agent took through an integration, with who or what triggered it. Entries cannot be edited or deleted from the app.

On every plan, each tool call an agent makes is shown in the chat next to the reply that used it, so the people in the channel can see what happened.

woble runs on a major cloud provider in EU regions, with production and staging kept apart. Databases are backed up continuously and tested for restore. Encrypted backups are retained for 30 days.

We monitor the service around the clock and keep error budgets for the queue that runs agents, so that a spike in one workspace cannot starve the others. Dependencies are kept current and scanned for known vulnerabilities as part of every deployment.

If we learn of a security incident that affects your data, we will tell the workspace owner without undue delay and in any case within 72 hours of confirming it, with what happened, what data was involved, what we have done about it and what we recommend you do. Where we are your processor, this notice also meets our obligation under the Data processing addendum.

If you believe you have found a vulnerability in woble, please tell us at security@woble.ai before telling anyone else. Include enough detail for us to reproduce it. We will acknowledge your report within two working days, keep you informed while we fix it, and credit you when it is resolved if you wish.

We ask that you do not access, change or delete data that is not yours, do not disrupt the service for other customers, and do not use automated scanners against production. We will not take legal action against anyone who reports in good faith and follows these rules.