Perimeter, sandbox and egress gateway
The perimeter, sandbox and egress gateway define exactly where Mickai touches the outside world and on what terms. When a workload genuinely needs connectivity, such as a research task or a browser session, it runs inside a sandboxed cell behind an allowlisted egress gateway, with an optional operator-selected VPN, rather than being given open access to your network. Nothing reaches an external destination without passing the per-tenant egress firewall, so the boundary between your regulated data and the internet is a single, audited, operator-controlled chokepoint.
Even a system built for zero egress sometimes has to do work that touches the outside world, such as reading a public web page, running an OSINT query or driving a browser, and the danger is that this connectivity becomes an open door through which regulated data can leak or a hostile payload can enter. In a cloud stack the customer cannot see or control the network egress of the model host, so there is no way to prove that a research task did not also transmit sensitive context, and untrusted content is pulled straight into the same environment that holds the tools. The correct control is to confine connected work to a sandboxed cell that is isolated from the regulated data plane, and to force all outbound traffic through a single allowlisted gateway that the operator controls and that records every connection. Mickai does exactly this: the sovereign browser and connected studios run in a sandbox behind an egress gateway with an operator-selectable VPN, Trust Agent enforces a per-tenant egress firewall so nothing reaches an untrusted domain without authorisation, and every crossing of the boundary is sealed to the Open Audit Record. The regulated core stays air-gapped while the small amount of genuinely necessary connectivity is contained, allowlisted and evidenced.
The 5 controls in this domain, each enforced by construction on hardware you own and mapped to the subsystem that provides it.
Sandboxed Connected Workloads
Connected work such as web browsing, research and OSINT runs inside a sandboxed cell that is isolated from the regulated data plane, so untrusted external content is never pulled into the same environment that holds sensitive data and acting tools. This confines any hostile payload to a controlled space where it cannot reach the regulated core, which is the correct posture for the small amount of genuinely necessary connectivity a sovereign system needs. The sandbox is opt-in per workload and its state is auditable. It keeps the regulated core air-gapped while still allowing controlled outside work.
Allowlisted Egress Gateway
Every outbound connection from a connected workload passes through a single egress gateway that permits only allowlisted destinations, so the boundary between your data and the internet is one audited chokepoint rather than a diffuse set of open connections. An attacker or an errant task cannot reach an arbitrary domain, because anything not on the allowlist is refused at the gate. This gives the operator a provable answer to where data could and could not have gone, which a shared cloud host cannot provide. The gateway records every permitted crossing to the audit record.
Per-Tenant Egress Firewall
Trust Agent, the foundational routing primitive, enforces a per-tenant egress firewall that inspects and classifies every request by sensitivity tier before it can leave, so no data reaches an external destination without being authorised for that tenant. This means the egress control is not a single shared setting but a boundary drawn separately around each tenant, which prevents one tenant's connectivity from becoming another's leak. Every decision the firewall makes is sealed to the Open Audit Record. The per-tenant egress firewall is anchored in the filed Trust Agent patent.
Operator-Selectable VPN
When connectivity is required, the sandbox can route its traffic through a VPN the operator selects, so the exit point and the route are under the operator's control rather than a vendor's. This lets an organisation choose jurisdiction and provider for the small amount of outbound work it permits, and change it as policy requires, without exposing the regulated core. The VPN applies to the sandboxed cell only, so it never carries regulated data from the air-gapped plane. The selection and its use are recorded alongside the egress decisions.
Boundary Crossing Audit
Every time traffic crosses the perimeter through the gateway, the event is sealed to the Open Audit Record with the destination, the tenant and the authorisation that permitted it, so egress is not merely controlled but fully accountable after the fact. This gives a regulator or an internal auditor a complete, tamper-evident picture of exactly what left the boundary and why, which converts connectivity from an unknowable risk into a reviewable log. The record is signed under the operator key, so it cannot be quietly amended. It is the same audit substrate used across the whole SIOS.
The advantages hold across every control domain, and they are architectural, not promotional. The third-party cloud-exposure vector is removed; your own physical, insider and compliance controls remain yours.
The data never leaves your hardware, so no third party and no cloud-provider employee ever sees it. What happens in the server room stays in the server room.
You own the compute and the capability, so the system runs independent of the internet and of any cloud vendor's pricing, terms, or availability.
The data never crosses a geographical or digital border because it never leaves the building, which removes the cross-border-transfer and third-party-processing friction of UK GDPR, Schrems II, and the sector rules. You keep your own obligations.
Fine-tune and run retrieval on your deepest archives to build a hyper-customised co-pilot, with no risk of your proprietary edge training a public model or leaking.
After the hardware and licence, queries cost essentially electricity. A capital asset you own and depreciate, instead of volatile per-token cloud bills.
There is no third-party cloud path, so no competitor and no vendor insider can scrape, intercept, or subpoena your prompts or your fine-tuned weights from the internet. The trust vault is closed by architecture.
You own the software snapshot on your own hardware, so a change to a cloud vendor's terms, a model deprecation, or an outage cannot reach you. The system stays predictable and auditable on-premise as the rules evolve.
How does Mickai handle work that genuinely needs the internet?
Connected work such as web browsing, research and OSINT runs inside a sandboxed cell that is isolated from the regulated data plane, so untrusted external content is never pulled into the same environment that holds sensitive data and acting tools. All outbound traffic from that cell passes a single allowlisted egress gateway the operator controls, and every crossing is sealed to the audit record. The regulated core stays air-gapped while the small amount of necessary connectivity is contained, allowlisted and evidenced.
What is the egress gateway?
The egress gateway is the single operator-controlled chokepoint through which all outbound traffic from a connected workload must pass, and it permits only allowlisted destinations. An attacker or an errant task cannot reach an arbitrary domain, because anything not on the allowlist is refused at the gate, which gives the operator a provable answer to where data could and could not have gone. Every permitted crossing is recorded to the Open Audit Record.
How is egress controlled separately for each tenant?
Trust Agent enforces a per-tenant egress firewall that inspects and classifies every request by sensitivity tier before it can leave, so the egress control is a boundary drawn separately around each tenant rather than a single shared setting. This prevents one tenant's connectivity from becoming another tenant's leak, and every firewall decision is sealed to the audit record. The per-tenant egress firewall is anchored in the filed Trust Agent patent, the foundational routing primitive in the portfolio.
Can we choose how connected traffic leaves the network?
Yes. When connectivity is required, the sandbox can route its traffic through a VPN the operator selects, so the exit point and the route stay under the operator's control rather than a vendor's. This lets an organisation choose jurisdiction and provider for the small amount of outbound work it permits and change it as policy requires. The VPN applies only to the sandboxed cell, so it never carries regulated data from the air-gapped plane, and its use is recorded alongside the egress decisions.
Is every crossing of the perimeter recorded?
Yes. Every time traffic crosses the perimeter through the gateway, the event is sealed to the Open Audit Record with the destination, the tenant and the authorisation that permitted it, so egress is fully accountable after the fact. A regulator or an internal auditor gets a complete, tamper-evident picture of exactly what left the boundary and why. The record is signed under the operator key, so it cannot be quietly amended.
Why is this safer than a cloud research or browsing tool?
In a cloud stack the customer cannot see or control the network egress of the model host, so there is no way to prove that a research or browsing task did not also transmit sensitive context, and untrusted content is pulled straight into the environment that holds the tools. Mickai instead isolates connected work in a sandbox, forces all outbound traffic through one allowlisted operator-controlled gateway, and seals every crossing to an audit record you hold. Connectivity becomes contained, allowlisted and evidenced rather than an open door.
Review the perimeter, sandbox and egress gateway controls with us.
Briefings are for organisations weighing a sovereign, on-premise deployment. Tell us about your estate and threat model and we will walk the controls, the attestation surface and the deployment that fits.