Platform
One customer, one cluster, one identity domain, one evidence trail
Everything is configuration of established open source projects, kept in Git, so your reviewers read the same files we deploy.
Architecture of one customer deployment
Target architecture. The status of each part is in the table below; the lab runs the cluster, Flux, SPIRE and signed evidence today.
Your environment
Your cloud account, bare metal, on-prem or air-gapped site.
Your cluster (Talos Linux)
Nodes with Secure Boot, TPM-sealed disks and no inbound port, attested to SPIRE (TPM or cloud identity).
SPIRE
Issues a SPIFFE ID per agent.
OpenBao
Releases secrets per identity.
Keycloak
Signs in people with CAC/PIV or passkeys and approves actions.
Agent sandboxes
One agent per sandbox, identity spiffe://tenant…/onet/SOC, tasks from O*NET.
Signed evidence
An in-toto statement per task, sources cited, cosign-signed, verifiable offline.
Git repository
The desired state; Flux reconciles the cluster from it.
Security officer
Reviews identities, evidence and approvals.
Assurance profile
Chosen per cluster.
How it works
Your security officer chooses an assurance profile
Who holds the keys, how nodes are attested, how people sign in, how long audit is kept, which tasks need a human. See assurance profiles.
A cluster is built from code
In the place your contract names. Talos boots with Secure Boot, seals its disks to the TPM, and opens no inbound port. Flux keeps it equal to a Git repository.
Each agent gets an identity, not a password
SPIRE attests the node and issues the agent a SPIFFE ID; OpenBao releases secrets only to that ID.
Agents do tasks drawn from O*NET occupations
Chosen from the catalog. Tasks that need a license produce drafts for a licensed human; physical high-risk tasks need approval.
Every task leaves a signed, cited record
Anyone holding the public key can verify it, offline, with cosign.
Components and status
| Layer | Open source project | Status | Notes |
|---|---|---|---|
| Cluster | Talos Linux, provisioned with OpenTofu | Available | Lab: Secure Boot, LUKS2 disks sealed to the TPM (software TPM in the lab), no inbound port, destroyed and recreated from code. |
| GitOps | Flux | Available | The cluster state is a Git repository; changes are commits, reconciled by Flux. |
| Workload identity | SPIRE / SPIFFE, one trust domain per customer | Available | Lab: SPIFFE ID spiffe://canary.reti-infra.com/onet/15-2041.00 for one seeded agent. Customer node attestation (TPM, cloud) is in development. |
| Identity view | Tornjak | In development | Running in the lab, reachable only by port-forward; no sign-in yet. |
| Secrets | OpenBao, authenticated by SPIFFE identity | In development | Lab uses a static seal; customer key custody (KMS, HSM, Shamir) is set by the assurance profile. |
| Signed evidence | in-toto + DSSE + cosign | Available | Task records verify offline with cosign (synthetic example). Rekor transparency log: planned. |
| Assurance profile | JSON Schema, one object per cluster | In development | Schema and examples validate; wiring into provisioning is in progress. |
| Sign-up and trial | Backstage templates, Kratix, tofu-controller | In development | Trial resource type exists in the lab; the portal is not reachable yet. |
| Human sign-in | Keycloak: CAC/PIV, passkeys, FIPS mode | Planned | One realm per customer; action approval by CIBA to the approver's device. |
| Agent runtime | agent-sandbox on gVisor or Kata | Planned | One agent per sandbox. |
| Authorization | Kyverno, OpenFGA | Planned | Admission policy and customer → agent → task permissions. |
| Air-gapped delivery | Zarf, Hauler, Harbor or zot | Planned | Lab already pulls every image through its own registry cache. |
Available = proven on our lab clusters as of 2026-10-24. Nothing is deployed for customers yet. The lab's TPM is a software TPM: disk sealing is real, attestation is only as good as the host.