1. The book that knew its own rules

Neal Stephenson’s The Diamond Age returns as the recalled work because the Young Lady’s Illustrated Primer operates within a designed pedagogy: it can adapt, but only within boundaries that protect the child. The desktop’s trust engine must be similar: autonomous but governed by immutable rules that ground can inspect and update.

This entry asks what autonomous trust boundaries need from the desktop.

2. Policy engine

The platform needs a policy engine that can evaluate every command and autonomous decision against signed rules. The engine should:

  • load pre-approved maneuver windows and command-class policies from ground;
  • verify the cryptographic signature on every policy update;
  • reject any command that violates active policy, even if it is correctly signed;
  • log every policy decision with the rule that was applied;
  • support atomic policy updates so that partially loaded rules cannot be exploited;
  • provide a safe-mode fallback when policy is missing, expired, or conflicting.

The policy engine is the boundary. It must be small enough to audit and robust enough to fail closed.

3. Cryptographic infrastructure

Trust boundaries need hardware and software support:

  • Secure key storage: keys for command verification should live in a trusted platform module or hardware security module where feasible, or in protected memory with integrity checks.
  • Signature verification: every command, policy update, and software image must be verified before use.
  • Freshness checks: counters, timestamps, or nonces must prevent replay.
  • Key rotation: the platform must accept new keys and gracefully retire old ones.
  • Revocation: compromised keys or ground stations must be disableable.

For small satellites, a full HSM may be too heavy, but the intent can be approximated with verified bootloaders, protected key stores, and carefully partitioned software.

4. Fail-safes and containment

When trust cannot be established, the platform must default to safety:

  • Safe mode: suspend non-critical commands, stabilize attitude and power, and await ground contact.
  • Command quarantine: buffer suspicious commands for later analysis rather than executing or dropping them silently.
  • Subsystem isolation: disable a subsystem that is issuing anomalous commands or behaving outside policy.
  • Rate limiting: throttle command acceptance after repeated authentication failures.
  • Last-known-good policy: revert to a previous policy if a new one fails verification.

These fail-safes must themselves be protected from spoofing. A forged “enter safe mode” command should not be distinguishable from a legitimate one unless it is properly authorized.

5. Telemetry and accountability

Trust requires evidence. The platform must log:

  • every command received, with signature validity, freshness, and policy result;
  • every autonomous decision, with the policy window and sensor data that justified it;
  • every key rotation, revocation, and fallback event;
  • every safe-mode entry and exit;
  • every anomaly detected by intrusion detection.

Logs should be stored in a tamper-resistant cyclic buffer and downlinked at the earliest opportunity.

6. What this changes

  • Autonomous trust boundaries are implemented by a policy engine, cryptographic infrastructure, fail-safes, and logging.
  • The policy engine must be able to reject correctly signed but out-of-policy commands.
  • Fail-safes must be protected from spoofing and must default to safety.
  • The next entry will close the autonomous trust boundaries wondering arc and record the decision.