Security & Compliance

This page is the summary. Each section below has a page of its own:

Lifeboat’s strongest security property is architectural: it is deployed on infrastructure the customer owns, so prompts, completions, model weights, and usage data never leave the environment — including in fully air-gapped installations with no outbound connectivity at all. This is what Iterate.ai means by true AI sovereignty: the model, the data, and the audit trail all stay in one place, under one owner.

How is access controlled?

Administrative access — token-based sessions with four roles (superadmin, admin, operator, viewer), hashed password storage, and per-source-address rate limiting on sign-in attempts.
Inference access — bearer API keys issued per consumer, validated on every request, and revocable independently of any deployment change. Keys can be paused rather than deleted, which is useful during an investigation.
Sensitive value handling — a new key’s secret is displayed exactly once at creation and only a prefix is shown thereafter; an administrator can reveal a stored key, and that reveal is itself written to the audit log.

How are secrets protected at rest?

Stored credentials — Hugging Face tokens and revealable key material — are encrypted at rest. The threat this addresses is explicit: plaintext disclosure from a database backup, an exported row, or a decommissioned disk. It does not defend against an attacker who has already achieved code execution on the control plane, because the control plane must be able to decrypt at runtime. Deployments requiring hardware-backed key custody should run the control plane on confidential-computing infrastructure.

How is fleet communication secured?

Every control-plane-to-node call carries a shared cluster secret, so a node agent will not accept lifecycle commands — start a server, stage a model, kill a process — from an unauthenticated source on the network. Node agents are intended to sit on a trusted internal network segment behind that check.

How is the container hardened?

The image runs as a non-root user, is built multi-stage so build toolchains are absent from the runtime layer, and is based on a minimal supported Linux base. The build pipeline includes an optional CVE scan that can fail the build on high or critical findings, and images are published under a versioned tag for provenance. File-deletion operations are path-restricted to approved model directories, so a malformed or malicious request cannot reach anything else on disk.

What is audited?

Every administrative action: sign-in, sign-out, failed sign-in, and permission denials; server create, modify, and lifecycle changes; model registration, download, and deletion; API-key and credential-vault operations including reveals; user and role changes; cluster changes; configuration changes; and node registration. Records include the acting user, action, target, timestamp, and source address, and are filterable in the UI or exportable through the API for SIEM ingestion.

Using the audit log

Audit records who did what, when, and to which object — sign-ins, server starts and stops, model registration and deletion, key creation and every key reveal, user and role changes, configuration changes, licence activation.

It also records decisions Lifeboat made on its own, which is the part most worth knowing about, because these change how a server behaves without anyone touching a setting:

Entry	Meaning
`server_backend_autoswitched`	The engine was changed at start because the other one could serve those weights and this one could not.
`server_is_embedding_autodetected`	The model was identified as an embedding model and every generation-only setting was stripped.
`server_tool_call_parser_corrected`	The configured tool-call parser did not match what the model’s own chat template proves it emits, and was corrected. Without this, tool calls fail silently.

If a server behaves differently from how it is configured, search the audit log for its name before suspecting the configuration.

Answering “who changed this?”

Filter by target — a server name, a model, a user — rather than scrolling. Entries are append-only and are not editable from the console at any role.

Retention and export

Entries live in the data directory, so persist that volume or the log is lost with the container. Mount the log path to a host volume for retention beyond the container’s life, and ship it to your existing log platform if you need it correlated with anything else; Lifeboat does not duplicate a SIEM.

Confidential computing

Protects weights and prompts in use, by running inside a confidential virtual machine with the GPU in confidential mode. It is a licensed capability, not a configuration flag: requesting it without the entitlement leaves it dormant and says so.

Three modes: off; auto, which detects, attests and reports but never blocks a server from starting — safe to leave on everywhere; and require, which refuses to start a server on a host that does not attest.

Both halves are required, and each is checked:

CPU — Intel Xeon with TDX, or AMD EPYC with SEV-SNP, and the workload running inside the confidential VM.
GPU — NVIDIA H100, H200, B100/B200, GB200/GB300, or RTX PRO 6000 Blackwell Server Edition, in confidential mode.

Not sufficient, and these are the ones people get wrong:

Desktop or workstation CPUs (Core i9, Ryzen) — neither technology.
Intel TME. It appears in lscpu and looks like the right thing. It is not TDX and gives no trusted environment.
Bare metal instead of a confidential VM — the CPU may support it, but nothing is attesting.
The RTX PRO 6000 Blackwell Workstation or Max-Q editions, as against the Server edition.
AMD GPUs, at all. An EPYC SEV-SNP host satisfies only the CPU half. Lifeboat detects this and stands the feature down rather than refusing every server start on a host that could never attest — so require on an AMD host does not brick it.

The License page reports which half is missing rather than a bare failure. A state other than attested is correct behaviour on hardware that cannot attest, not a fault.

Encrypted model weights are a further step: weights are encrypted at rest and the key is released only while the host attests, decrypted into memory the hardware encrypts, and discarded when the server stops. Model architecture and tensor names stay readable — the engine must read them to build the model before any key exists — and tensor data does not. Local-node only in this release.

What is deliberately out of scope?

Lifeboat is an inference engine with an operational control plane, not a governance platform. These are intentional scope boundaries, each with a standard answer:

Not in Lifeboat	Where it belongs
Enterprise SSO / SAML / OIDC on the control plane	Front the control plane with VPN, bastion, or reverse-proxy authentication. Native SSO is on the roadmap.
Network ingress filtering and WAF	Infrastructure layer — security groups, network policies, NGINX/Envoy, or a cloud WAF
Data-loss prevention, guardrails, or content filtering on inference traffic	AgentWatch deployed in front of Lifeboat
Per-tenant budgets, quotas, and multi-tenant key isolation	AgentWatch
TLS termination in default deployments	The organization’s reverse proxy, or Lifeboat’s own TLS option when supplied a certificate and key

How does this map to compliance frameworks?

Lifeboat is deployed software rather than a service, so certification applies to the customer’s deployment and the controls around it, not to a vendor-hosted instance. What Lifeboat contributes to an audit is the technical evidence: enforced role separation, authenticated inference access, encryption of stored secrets, a complete and exportable administrative audit trail, and — most consequentially for data-residency and sovereignty requirements — the fact that no prompt, completion, or model artifact leaves the deployment boundary.

Sources and references

Governance and DLP layer: AgentWatch overview.
Deployment hardening steps: Deployment.