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 inference provider you choose, so here is both cases. We would rather you saw the distinction than have us imply the stronger claim always applies.
| Configuration | Prompts & documents | Third party in the path |
|---|---|---|
| Local inference — Ollama or vLLM on your hardware | Never leave your network | None |
| Hosted inference — 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 |
There is no telemetry path back to us in either configuration. Where a deployment must have no egress at all, the tunnel component runs inside your own account, so no third party — including us — sits in the traffic path.
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 — that is, on your infrastructure, subject to your retention schedule and your access controls. We hold no copy.
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.
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.