Model Container Security¶

Last updated: 2026-07-22

Cortensor's model-security path starts with a practical boundary: model workers run in containers, and secure builds place a small gateway beside the model service. In the current minerv4 flow, that gateway gives the miner a way to rotate runtime credentials, check gateway reachability, and verify container-reported checksum data before treating a worker as trusted for gateway-protected execution.

The long-term direction is stronger than today's gateway check. The same containerized worker shape can evolve toward signed model manifests, build provenance, fail-closed routing policy, attestation-gated key release, and eventually TEE or confidential-GPU execution for private and high-assurance workloads.

Current layer gateway verification

Secure worker images include a gateway that authenticates access, rotates credentials, and reports verification data.

Miner check minerv4

The miner challenges the active model gateway and compares the returned checksum-derived verification hash.

Trust boundary not full TEE yet

Today's check is a runtime hardening layer, not hardware-backed enclave or confidential-GPU attestation.

Future path attestation + keys

Protected workloads should eventually receive private keys only when image, model, gateway, and TEE evidence match policy.

Status At A Glance¶

Layer	Status	Meaning
Containerized model workers	Current	Model runtimes are packaged as worker containers.
Gateway-enabled secure images	Current	Secure worker variants include a gateway process next to the model service.
Credential rotation	Current	The miner generates and rotates per-model runtime credentials.
Checksum challenge	Current	The miner verifies a seed/checksum-derived response from the gateway.
Signed model manifests	Planned	Model ID, runtime identifier, image digest, model hashes, gateway hash, and release version should be bound together.
Build provenance and SBOM	Planned	Secure images should be traceable to their build inputs and release process.
Attestation-gated key release	Planned	Private task keys should depend on approved runtime evidence.
TEE or confidential-GPU execution	Future	Hardware-backed execution should protect higher-assurance private workloads where practical.

Current Runtime Shape¶

flowchart LR
  Router["Router or session queue"]
  Miner["minerv4"]
  Manager["LLM worker manager"]
  Container["Secure model container"]
  Gateway["Gateway process"]
  Runtime["Model runtime<br/>llamafile or Ollama"]
  Result["Result, hash, or URN"]

  Router --> Miner
  Miner --> Manager
  Manager --> Container
  Container --> Gateway
  Container --> Runtime
  Miner -. "credential rotation and verification challenge" .-> Gateway
  Runtime --> Result
  Result --> Miner

The worker container carries two related services: the model runtime that performs inference, and the gateway that handles authenticated gateway traffic and verification data. The gateway is intentionally thin so the security control point can be hardened over time without changing the public model-selection mental model.

Component	Current responsibility
`minerv4`	Starts the model runtime path, manages model switches, and runs gateway checks when the gateway-enabled path is active.
LLM worker manager	Prepares and starts the selected containerized model worker.
Secure worker image	Packages the model runtime and gateway process together.
Gateway	Authenticates gateway traffic, encrypts gateway payloads, rotates credentials, checks model-service health, and reports verification data.
Model runtime	Runs the configured llamafile or Ollama-style model.
Runtime credentials	Per-model API keys, seed, and rotation key used for gateway authentication and challenge/response checks.

This description applies most directly to the gateway-enabled Docker-manager path. Dedicated-node and custom deployment modes should be checked against the active release before describing them as having the same security behavior.

Verification Flow¶

sequenceDiagram
  participant M as minerv4
  participant W as Worker manager
  participant C as Secure container
  participant G as Gateway

  M->>W: Prepare selected model worker
  W->>C: Start secure image with runtime credentials
  M->>G: Rotate master key
  M->>G: Rotate API keys and seed
  M->>G: Send encrypted verification challenge
  G->>G: Read checksum and combine it with current seed
  G-->>M: Return verification status and hash
  M->>M: Compare expected hash with gateway hash
  M-->>W: Continue only if verification succeeds

The miner does more than check whether the container is alive. It verifies that the active gateway has the expected live credentials and can produce the expected response for the selected model worker. If that challenge fails, the worker should not be treated as valid for protected workloads.

Protection Boundary Today¶

Helps with	How
Wrong or missing secure worker	Gateway-enabled runs expect a secure worker variant and a reachable gateway.
Stale default credentials	Runtime credentials are generated per model and rotated after startup.
Unreachable gateway	Verification fails if the miner cannot reach the gateway for the selected model.
Checksum mismatch signal	The miner recomputes the expected seed/checksum hash and rejects a mismatch.
Accidental public exposure	Normal worker setup binds model and gateway ports locally instead of publishing them as public services.
Model-switch drift	Prepared model switches trigger a new check for the active model before protected state is reported.

What Is Not Proven Yet¶

The current gateway layer is a meaningful hardening step, but it should not be described as complete attestation.

Not yet proven	Why it matters
Full image provenance	A checksum challenge is not the same as a signed, reproducible, externally verifiable image build.
Signed model-weight identity	Model ID, runtime name, image digest, weight hashes, gateway hash, and release version still need a signed manifest boundary.
Host trust	A normal container still depends on the host, Docker runtime, kernel, and deployment policy.
Hardware-backed TEE execution	Today's check does not prove the model ran inside an enclave, confidential VM, or confidential GPU environment.
Confidential GPU memory	Large GPU inference needs confidential-GPU support before model weights and runtime memory can be treated as hardware-protected.
Public attestation evidence	Dashboards and routers need a public-safe way to expose verification status without leaking sensitive operational details.

Hardening Roadmap¶

The secure-container path can strengthen one layer at a time. The goal is to turn today's gateway check into a broader evidence chain: what image was built, what model it contains, what code is protecting it, what runtime launched it, and whether protected keys should be released.

flowchart LR
  Today["Today<br/>gateway verification"]
  Manifest["Signed model manifest<br/>model ID + image digest + hashes"]
  Provenance["Build provenance<br/>SBOM + release metadata"]
  Policy["Runtime policy<br/>fail closed + public-safe status"]
  Attestation["Attestation-gated keys<br/>release after measurement match"]
  Confidential["Confidential execution<br/>TEE or confidential GPU"]

  Today --> Manifest
  Manifest --> Provenance
  Provenance --> Policy
  Policy --> Attestation
  Attestation --> Confidential

Phase	Goal	Public explanation
Signed manifest	Bind model ID, runtime identifier, image digest, model-weight hashes, gateway hash, and release version.	Users can see which artifact a node claims to run.
Build provenance	Publish SBOM and release provenance for secure gateway and model images.	Operators can trace how the image was built.
Runtime policy	Treat verification failure as a hard routing failure for protected workloads.	A model that cannot verify should not receive sensitive work.
Attested key release	Release private task keys only after the runtime presents acceptable evidence.	Data access depends on proof, not trust in a host label.
Confidential execution	Move sensitive workloads into TEE-backed, confidential-VM, or confidential-GPU environments where practical.	The execution environment becomes part of the trust proof.

TEE Direction¶

The current Docker packaging is useful because many confidential-compute workflows begin from a packaged application image and turn that package into a measured execution artifact. Cortensor can preserve the same operating model while tightening the trust model: a miner still runs a model worker, but protected workloads require stronger evidence before keys, encrypted prompts, or protected model material are released.

flowchart LR
  Task["Private task or protected route"]
  Policy["Security policy<br/>approved image + model + runtime"]
  Evidence["Attestation evidence<br/>measurement + identity"]
  Verifier["Verifier or key service"]
  Keys["Task or model keys"]
  Worker["Attested worker<br/>gateway + model runtime"]
  Output["Encrypted output or URN"]

  Task --> Policy
  Worker --> Evidence
  Evidence --> Verifier
  Policy --> Verifier
  Verifier -->|"match"| Keys
  Keys --> Worker
  Worker --> Output
  Verifier -. "no match: no keys" .-> Task

Direction	Good first fit	Notes
Nitro-style enclave	Attested gateway, secret handling, key release, signing, and compact control-plane workloads.	A practical bridge for protecting keys and policy decisions around model containers.
Confidential VM	Fuller node or worker stacks that need stronger host isolation while keeping a VM-shaped runtime.	Useful when the deployment needs normal service composition plus measured boot/runtime evidence.
Confidential GPU	Large LLM inference with protected model weights and runtime memory.	The long-term direction for high-value GPU model execution.
Confidential containers	Fleet packaging when the provider and orchestration stack support the required attestation model.	A natural continuation of the current containerized worker design.

Nitro-style systems are a bridge for the control point: secrets, signing, key release, and policy checks. Large LLM execution needs a broader confidential-compute stack, especially when GPU memory, model weights, and private inference data must be protected together. The target architecture is not just "run Docker in a TEE"; it is a measured path where image, model, gateway, runtime, and task policy all agree before protected data is released.

How To Describe It¶

Use	Avoid
Gateway-verified secure model containers	Fully trusted containers
TEE-ready architecture	Already TEE-secured
Checksum and credential-rotation challenge	Complete supply-chain proof
Attestation-gated key release roadmap	Guaranteed private inference
Confidential-GPU direction for large LLMs	Every Docker LLM can move directly into an enclave