Security

Who this page is for

This page is for the person who has to decide whether to trust Botseon with their organisation's data: a security reviewer, a technical founder, or an administrator setting the service up for the first time. It names what we protect, how, and where the protection stops. Where something is planned rather than built, we say so rather than describe it as a defence.

What we protect, and from whom

Four things matter most: the records your bots create (conversations, messages, memories and the files a bot works with), the credentials a connected account gives a bot access through, the record of what a bot did and why, and the computer each bot works on.

We design against four kinds of risk. Another organisation on the same service, reading or changing your data by mistake or on purpose. A bot run that has read something it should not trust, such as an email or a web page written by someone outside your organisation. A connector or extension that behaves differently from what it declares. And someone with direct access to the database, such as an operator, a lost backup, or a stolen credential.

Keeping every organisation's data separate

Every row of data belongs to exactly one organisation, and the database enforces that boundary itself rather than relying on application code to remember it. A query that does not clearly say which organisation it is asking about returns nothing at all, by default, rather than everything. A member is separated the same way from a colleague in the same organisation: a bot never reaches further than the person it is acting for.

A bot never writes to your data directly. Every change goes through one validated path, and that path is what keeps a record of who did what. Access control and this separation are checked by automated tests on every change we make, not only reviewed by eye.

Encryption and where keys live

Data is encrypted in transit and at rest. The sensitive parts are encrypted under a key held separately for each organisation, so that destroying one organisation's key makes what it protected permanently unreadable without touching anyone else's data. Each organisation's key is itself stored in the database, encrypted under a master key that is kept outside the database.

Secrets and credentials

A connected account's access token is held further back than your ordinary content: it is reached through its own protected path, by a narrow piece of code written for exactly that purpose, and a bot never sees the token itself. The token never reaches the computer a bot works on, and it never reaches the model that writes a bot's replies.

We scrub a secret out of what we store before we encrypt it, not after, whenever we recognise its shape, so the plain text never reaches storage in the first place. That scrub is a floor, not a guarantee: a secret in a shape we have not catalogued can still slip through, which is why we keep widening the list rather than claiming it is complete.

A record that cannot be rewritten quietly

Every run a bot makes produces a record: who asked for it, which bot acted, what happened, and why. That record can only be appended to, never edited, and each entry is tied to the one before it so that changing an old entry would be detectable. We check that chain on a regular schedule and treat a broken one as a failure to investigate, not noise to ignore.

That check still has real limits. It is tamper evident, not tamper proof: someone who could delete whole entries at once, rather than altering one quietly, could still remove history outright. We say so rather than overstate what the record protects against.

When a bot reads something it should not trust

A bot run that has read an email, a web page, or anything else written by someone outside your organisation is treated differently for the rest of that run. While that is true, the bot cannot use a standing, pre-approved rule to send, spend, delete, install, sign in, or run a command on your behalf. Any one of those still needs a person to say yes, for that run.

The same caution applies to what a bot remembers while in that state. Rather than writing a new memory immediately, the bot queues what it would like to remember and asks a person to confirm it once the run finishes. A memory written this way is marked with where it came from, and it stays marked even after it is approved, so a later run that relies on it is treated with the same caution rather than being allowed to compound unnoticed.

Human approval before a consequential action

Before a bot sends a message, spends money, deletes something, installs anything, or signs in anywhere, it asks. The request names the tool, what it would affect, the account it would act as, and why, with anything sensitive in the request itself hidden from view. An automatic check can help decide whether a standing rule should apply, but it can only let a rule you already wrote release an action; it cannot approve anything on its own, and it cannot refuse anything either, since a request it is unsure about is still sent to a person.

Certain actions can never be covered by a standing rule at all, however it is written: spending money, signing in somewhere, deleting something, and anything that decides something about a specific person. Those always ask, every time.

Reviewing connectors and extensions before they run

Before a connector or an extension is made available at all, it has to pass a fixed set of checks: that it declares what it can do truthfully, that it cannot reach the network outside the one path we control, and that it cannot leak a credential through its own result or error message. The checks run automatically, on the code as written, every time anything changes.

What our build pipeline can reach

The systems that build and test our code hold no production credential. The handful of credentials they do carry are scoped narrowly, available only to one step under one condition, and checked by a script that refuses anything that looks like it reaches further than that.

Certifications

We do not hold a certification such as ISO 27001 or SOC 2, and we do not claim one. If that changes, we will publish the certificate here rather than describe ourselves as certified in advance of it.

What this page does not cover

A reviewer should know what is out of scope here, as plainly as what is in it.

• A deliberate change made by someone with the access to make it. Separation between organisations stops an accidental reach across the boundary; it does not stop someone with legitimate administrative access from choosing to disable a safeguard they are trusted to manage. That is why such a change goes through review.
• A managed key store outside our own process. Today the key store runs inside the same deployment it protects. A separate, independently operated key service is planned, not built.
• A person who approves a request without reading it. Nothing here can defend against that, and we design the requests to be short and specific rather than assume they always are.
• A home-hosted deployment run on someone else's own computer, with their own keys. This page describes the service we run. A self-hosted installation is configured, and defended, by the person running it.

If you have a question this page does not answer, write to us at the address in Contact.