Architecture & security
Written for the person who has to sign it off.
If you are reviewing us, this page is for you. It states where data goes under each configuration, what is recorded, and how you can verify the claims rather than take them on trust.
Deployment topologies
Three shapes, chosen during the assessment. They differ in one respect that matters more than the rest: whether anything crosses your network boundary.
Where data goes
The honest answer depends on which configuration you choose, so here are all of them. We would rather you saw the distinction than have us imply the strongest claim always applies.
| Configuration | Prompts & documents | Third party in the path |
|---|---|---|
| Local inference on your hardware | Never leave your network | None |
| Hosted inference in your environment — a model API you have approved | The prompt and the context sent with it reach that provider | That provider only, under your agreement with them |
| Hosted by us, reading your systems — you grant scoped read-only access | Read on demand and held only in memory and in the model’s context. No copy at rest on our side | Us, in transit, plus the model provider |
| Hosted by us, with a copy — you replicate data to us | Stored on our infrastructure for the agreed retention period | Us, as your data processor, plus the model provider |
In the first two configurations there is no telemetry path back to us at all, and where a deployment must have no egress whatever, the tunnel component runs inside your own account so no third party — including us — sits in the traffic path. The third is different by design: if we host it, we process your data, which is why it comes with a data processing agreement, a named retention period and a breach-notification commitment rather than a handshake. Pick the row that matches your obligations, not the one that sounds strongest.
Reaching internal systems
The systems worth connecting to are usually the ones that accept no inbound connections. Rather than asking for an exception, the agent reaches them from the inside out.
- Direction
- The client always dials outward, over a port your network already permits. Nothing needs to listen for inbound connections on your side.
- HTTP tunnelling
- A persistent bidirectional gRPC stream over HTTP/2 and TLS, forwarding to a local service. The public edge can be deployed inside your account.
- Reverse SOCKS5
- For reaching a private network more broadly: a SOCKS5 listener on one peer while the other dials targets inside the private network. Carried over TLS with yamux, or QUIC, so one lost packet stalls only its own stream.
- Tool access
- Internal capabilities are exposed to the agent as tools, over Model Context Protocol clients using stdio or streamable HTTP. You choose what is exposed; nothing is discovered automatically.
Encryption in the messaging surface
Where a deployment includes the chat surface, the hub that routes messages is designed so that operating it grants no ability to read them. Queued messages for offline recipients are stored as ciphertext and flushed in order on reconnect.
- Key agreement
- X3DH and PQXDH.
- Message keys
- Double Ratchet for one-to-one conversations.
- Groups
- Sender keys, rekeyed when membership changes, so a removed member cannot read what follows.
- Metadata
- Sealed sender.
- Verification
- Safety numbers, so two people can confirm out of band that no key was substituted.
- Devices
- Each linked device holds independent signing and message keys, and can be revoked individually.
What gets recorded
Session history, agent decisions and tool calls are persisted to disk on the host running the deployment. In the two configurations you run — your hardware or your cloud account — that host is yours, so the records are subject to your retention schedule and your access controls, and we hold no copy. Where we host it, they sit on our infrastructure instead, under the retention period named in the data processing agreement.
What is retained, for how long, and who may read it are configuration decisions we make with you during Deploy, not defaults you inherit.
Verifying any of this
Everything above is a claim, and you have no reason to accept claims from a firm you have not worked with. Three ways to check.
- Test it yourself
- Included, and the most convincing of the three: run the deployment on a network you control and watch what leaves it. We will help you instrument that at no extra cost, because it is the check we would want in your position.
- Source inspection
- Available on request, under NDA, and quoted as a priced option — preparing a review environment takes engineering time and papering it takes legal time. If your review process requires reading code, raise it early and we will quote it.
- Escrow
- Available on request, arranged with a third-party escrow agent. The agent’s fees and our setup time are quoted and passed through, priced per agreement, so ask early enough for it to sit inside the budget.
The egress check, recorded
Three minutes of the first option, run on our own network: an agent answers questions against a clinical database on local inference, then every network socket that query opened is sampled and the check fails if any of them reached a public address. It states its own limits too — the script watches one machine, so a reviewer should watch the inference host as well.
Served from this domain, not an embed — no third-party player, no tracking.
Finish
Bring your reviewer to the first call.
If you already know what your security review will ask, send the questions ahead and we will answer them in writing.