Command Trust

Commands are authenticated end-to-end, independent of mTLS transport. The SOC Backend signs; the Gateway forwards opaque bytes; the agent verifies. This survives the gateway’s mTLS termination — a compromised or curious gateway cannot forge a command.

Sequence

The trust chain

• Anchor (offline). An Ed25519 anchor key signs the trust bundle. Minting happens with a standalone offline ops tool; the anchor private key never touches any online service. Its public key is pinned in the installer and stamped into the enrollment payload (AGENT_COMMAND_ANCHOR_PUBLIC_KEY_BASE64).
• Trust bundle. An anchor-signed list of currently-valid command-signing public keys with a monotonic u64 version. The SOC backend ingests a pre-signed bundle (COMMAND_TRUST_BUNDLE_BASE64), validates at startup that it advertises the active signing key, and republishes it on each enrollment to endpoint.enrollment-responses. The gateway forwards it down the Control Channel as a TrustBundle frame. The agent accepts a new bundle only if its version increases (anti-downgrade) and its anchor signature verifies, then hot-swaps it (commands/trust_bundle.rs).
• Command. Ed25519-signed by the SOC backend’s in-process signing key (services/signing.rs LocalSigner, id k1), embedded as sig_key_id. The agent’s commands/verifier.rs checks the signature against the keys in the current bundle before dispatch.

Verification & dispatch

commands/dispatcher.rs runs a command only after verifier accepts it. A bad signature returns CommandResult status SIG_ERROR; other rejections map to TARGET_REJECTED / EXPIRED. Accepted commands proceed to Remediation. The canonical signing form (canonical_bytes) is byte-identical across backend and agent — guarded by a frozen cross-repo parity test — so a signature computed on the backend verifies on the endpoint.