Authority should
have boundaries.

The signing key stays with the vendor.

Production vendor keys belong outside the hosted control plane. The hosted service receives public verification material and signed artifacts. The operator must protect, back up and manage the signing key on the signing machine.

Approval is for a specific change.

Customers approve an exact deployment plan and execution window. The vendor signs the approved execution. A login, a kit download or an accepted image is not general permission to deploy.

Agents and brokers have different powers.

Customer agents do not receive Docker daemon access. A scoped broker on the customer host does need Docker access to perform the supported operation. Each broker is pinned to its customer’s engine; customers are not isolated merely by separate containers on a shared engine.

The broker and the host are privileged trust boundaries. This design does not eliminate the impact of a compromised host, hypervisor or Docker daemon.

Application data remains a customer responsibility.

Customer configuration and application data remain on the customer host. Application backup exports are encrypted; the key must be retained separately. Restoring an image is not the same as restoring a database, and recovery must be reviewed for the application.

Unknown does not become “successful.”

Durable operation records distinguish started, failed and uncertain execution. Interrupted work needs reconciliation against the host and signed journals before the existing operation is resolved. Automatic replay is not the default recovery strategy.

Review is still required.

Local isolation and failure tests are implementation evidence. They are not an independent security audit, compliance certification or production authorization. Independent review and real-host acceptance remain open release gates.