Documentation
The appliance
The appliance is the ARC1 Gateway as one deployable unit for one organization’s Kubernetes cluster, built so a platform team can verify what it installs before it installs it.
What it is
The appliance packages the ARC1 Gateway, with its LLM proxy and its inspection service, as a Helm chart for one organization. It is connected: it reports to the customer’s own ARC1 hub, which it does not include, and it uses the customer’s database, vault and certificates. It is not a virtual machine image, a hardware product or a disconnected deployment.
How it is built
- Pinned images
- Every image is named by its digest, never by a tag.
- Signed configuration
- The gateway’s configuration is signed and the chart pins the public key. At start, the gateway checks the organization, its own identity, the validity window and a revision number that may only rise.
- Least privilege
- Containers run as a non-root user, with read-only root file systems, no added capabilities and no service-account token.
- Egress
- The gateway may reach only destinations listed by address and port, and there is no route to the whole internet. Network policy cannot match host names, so a provider’s address change needs a controlled update.
- Inspection
- Microsoft Presidio runs as its own deployment with no egress at all, not even DNS, and its models are built into the image.
- Management
- Health and readiness answer on a separate port that requires a client certificate.
- Supply chain
- Release images are signed with Cosign and carry a CycloneDX software bill of materials and SLSA provenance as attestations.
Install and roll back
The runbook dry-runs everything first: the chart is linted and rendered, the server checks the objects without creating them, and Cosign verifies every image’s signature and attestations. The install is atomic. It then reads back and exports its evidence with the hash of every file. A rollback keeps the approved configuration and the gateway’s volume, and the revision check refuses to start on an older configuration. No hub or database migration runs during an appliance upgrade or rollback.
What we have verified LAB
On 22 October 2026 we installed the appliance on a local K3s cluster running Kubernetes 1.33.5 on ARM64. A fresh install came up ready. An upgrade and a rollback restored the configuration revision and the outbox. The inspection service could not reach an outside address, and no packet left it. An oversized request was refused, and the refusal’s signed receipt verified. Cosign 2.6.0 signatures and Syft 1.33.0 bill-of-materials attestations verified by digest against a local registry.
Not yet established: a managed cloud cluster, AMD64 nodes, throughput, TLS ingress, high availability, disconnected operation, dispatch to a live provider, and the recall of external DLP on real data.
Where it stands
| Capability | State | Evidence |
|---|---|---|
| The gateway’s Helm chart in the released product | LAB | Built, not yet run in a customer tenant. |
| The appliance chart, signed configuration, egress limits and release signing | LAB | Local K3s install, 22 October 2026; awaiting release. |
| Fleet, connections, routes, limits and secrets pages for the gateway | LAB | Built; awaiting release. |
| A signed appliance image in a registry | NEXT | No signed image in a registry has been verified. |
| An appliance running on Google Cloud and enrolled in Fleet | NEXT | Planned. |
LIVE: in the released product and running on our hosted production deployment, with synthetic data. LAB: built or being built, and run only in our lab or against a vendor’s documented interface. NEXT: designed, not yet built. How we use these words.