Where the data sits
On your machine. Customer records, message history, configuration, documents and the audit log live in one Postgres cluster on the node, and nothing copies them anywhere else.
The machine does not need to be reachable from the internet for any of this to work. Every channel opens its own connection outward, so a node can sit entirely inside your network. That is covered in more detail on install and requirements.
What is recorded
Two tables are append-only, enforced by the database itself: every message, and every event. Nothing in the system edits them through the normal path, including an administrator.
Permission changes are written into the same log as the work. Granting a tool, creating a rule, putting an agent under a rule: each is an event next to the messages it later affects. So the record of what an agent was allowed to do sits beside the record of what it did, in one place and in order.
This is the part to check when you stop reading and start evaluating. Ask to see the event log on a running node.
What leaves the machine
The complete list:
| Goes out to | Why |
|---|---|
| Your model provider | The model call. This is the one that always happens |
| Your mail server | Reading and sending mail on the mailbox you gave it |
| Any chat platform you connected | Reading and sending on that channel |
| Google, if you connect it | Whatever scope you approve when you connect it |
Nothing is sent to us: no telemetry and no copy of your data on our side.
What we do keep, if you want us to keep it, is a way in for support: an administrative login and a metrics endpoint scoped to us. Both are ours to hold and yours to revoke, and on a node where you bring your own model keys and revoke them, we have no connection to your machine at all.
The Google row is worth one more sentence, because it is the one people wave through. The connector asks for a scope and you approve it in your own Google account. Read what it asks for before you press the button, the same as you would for any other application, and narrow it if you want it narrower.
Keys
Provider keys and channel credentials are held on the node, not in the prompts and not in the agent files. An agent reaches a service through a tool, and the tool holds the credential. So an agent can use a mailbox without being able to read the password for it, and rotating a key is one change in one place, not an edit across every agent that uses it.
Retention
Nothing is deleted. Messages, events and documents are kept until someone removes them deliberately. There is no scheduled cleanup, and the product does not currently run one for you.
For an append-only record that is arguably the right default, and it is certainly the safer one: a system that quietly dropped a customer conversation you needed six months later would be worse than one that keeps it. But it is a decision you inherit rather than one you made, so it belongs on this page rather than in a settings screen you never open. A node left alone accumulates, and the disk figure on install is a starting point.
If a retention period is a requirement on your side, say so during setup and it gets built into your install as a scheduled job. It is not something you can switch on yourself today.
Backups
The product does not ship a backup tool. There is a written procedure and it has been rehearsed, but running it is a decision someone has to make. If you would rather that were automatic, say so during setup and it becomes part of the install.
What this page does not claim
No third-party security audit has been done. No penetration test has been done. The claims above are about how the system is built and are checkable by reading it, which is not the same thing as having been attacked by someone competent and having held. Treat them accordingly.