Security and data
Trust model
What whoever controls borc systems can do: us, or anyone who got into our cloud account or the central database.
| Can | Cannot |
|---|---|
| See which companies are customers, with plan and version | Enter an instance as a user: platform issues no credentials for instances |
| Read numeric metrics: requests, latency, GPU | Read users, documents, conversations, file names |
| Forge or revoke a licence | Install software: releases are signed with a key that never sits in the cloud |
| Offer an already signed version or MCP server | Switch on features that send data out: those are enabled only from the instance panel |
| Issue a certificate for an instance name, only in the borc technical domain mode | Hijack the instance name when it sits on the customer own domain |
The company network is not the trust boundary
Being reachable only from the LAN or the VPN is not enough, for four reasons.
- Everyone inside the network is there: employees, VPN consultants, any infected PC. With forgeable credentials, any of them would get in as the CEO.
- For support we often have VPN access to the customer: our credentials plus our network access would be complete access.
- In the technical domain mode borc controls DNS for the name and could point it at its own server with a valid certificate.
- Customer security questionnaires ask whether the vendor can access the data, and "only if it is inside your network" is not accepted as an answer.
One trust point cannot be removed: we write and update the software, and a malicious release signed by us could read data. The countermeasures are verifiable: an offline signing key, reproducible releases, images pinned by digest, and manual approval of updates for those who ask.
Data egress
The system holds private data, untrusted content and egress channels at the same time. A hidden instruction inside a document must not be able to use them.
| Channel | Rule |
|---|---|
| Web search | Off by default. Because every question starts with a search in internal sources, web search is available only in conversations set to "no internal source", and the interface says so. As an alternative the administrator can allow the mode where every query is shown and confirmed. |
| MCP tools that write or egress | Every call is shown with its full parameters and requires confirmation. Egress addresses live in the signed offline catalogue; the machine firewall blocks the rest. |
| External model | The administrator chooses it in the administration panel, with a warning that document passages leave towards the vendor. |
| Images and links in answers | The page never loads external images: an image carrying data in its URL would be an egress. External links show the full address before opening. |
Signed updates
The signing key never sits in the cloud: platform can only offer.
- The manifest with version, images by digest, updater hash and MCP catalogue is signed on a laptop. The updater accepts only manifests signed with that key.
- No downgrades: the updater refuses any version lower than the installed one and lower than the minimum written in the last manifest. The only way back is a local rollback after a failed update.
- The signed list of published versions expires after 30 days: if the instance does not see a valid one in time, it reports it in the administration panel.
- An update window per customer and, optionally, manual approval: it applies to everything, security fixes included.
- Before every release with migrations the database is copied (ZFS snapshot or pg_basebackup) and, if a service is not ready in time, the previous version comes back.
Remote support
It opens only from the instance, on request, time-boxed and recorded. The recording belongs to the customer.
- The administrator opens support in the administration panel, with a duration between 1 and 8 hours and a reason.
- The updater starts an outbound tunnel: no port open to the internet, no inbound connection.
- sshd accepts the support user only with an SSH certificate signed by the support CA, valid inside the window. The CA is trusted only during the session: added on open, removed on close.
- SSH stays encrypted end to end: the tunnel carries bytes it cannot read. That is why no cloud-side command log is used.
- The session recording (asciicast format) lives on the machine and plays back from the administration panel, with who and when. At expiry sessions close themselves.
Backups and deletion
Every night an age-encrypted pg_dump lands on the customer network share. The public key sits on the machine, the private one is held by the customer: a plaintext copy would bypass every permission.
Deleting a user deletes conversations, links and personal tokens, and leaves a trace with an internal identifier only, in two places: on the machine and in a file outside the backups. After a restore the worker replays the deletions from that file.
Network connections of the machine
No inbound connection from the internet.
| Direction and target | Port | Why |
|---|---|---|
| Inbound from company PCs, on the LAN or the VPN | 443 | Interface and API |
| Outbound to platform.borc.ai | 443 | Licence, version, numeric metrics, certificate challenge |
| Outbound to registry.borc.ai, R2 and official registries | 443 | borc images and the updater binary; Postgres, vLLM and docling by digest |
| Outbound to Let's Encrypt and Hugging Face | 443 | Certificate for the instance name; model weights at install time and on model change |
| LAN to the file server or NAS | 445 | Network shares, share permissions and local groups over RPC |
| LAN to the domain controller | 636 | Users, groups and domain login (LDAPS) |
| Outbound to Microsoft 365 or Google Workspace | 443 | Corporate login and personal sources, only when configured |
| Outbound to external model, web search and support tunnel | 443, 7844 | Only when switched on in the administration panel; the tunnel only during an open support session |
Where data lives
Who is the controller, who is the processor and for what.
Users, sessions, documents, index, conversations, attachments, personal tokens and the activity log live on the customer machine, with encrypted copies on its NAS. borc has no access.
Technical metrics of the instance and the active user count live in borc central database: aggregated and numeric, never per person. Company name, contacts and invoices are contract data.
The data processing agreement is limited to support and maintenance, with the measures: offline release signing, manual update approval on request, time-boxed and recorded support access. The customer informs employees and reviews usage and activity log with its own adviser.