Zero-trust: what I actually enforce, and what I only designed

June 28, 2026 Deep Dive Security Zero-Trust Honesty

Most security write-ups blur the line between what's enforced in code and what's on a slide. For a defense-grade console that line IS the deliverable — so here's mine, drawn explicitly. Naming the gap is the point.

The fastest way to lose a security reviewer's trust is to claim a control you can't point to in the code. So this post does the opposite of a marketing page: it draws the line between enforced, designed-but-not-wired, and roadmap — and puts the gap in writing.

Zero-trust here follows the public references everyone cites: NIST SP 800-207 and the DoD Zero Trust Reference Architecture. The premise is simple and unforgiving: the link is hostile, and nothing is trusted because it "came from the drone." Trust is established per session, per message, per command — never assumed.

That's the principle. Ang totoo, iba yun sa reality (the truth is, that's different from reality) — so here's mine, split three ways.

Why write the gap down

Two reasons, and they're the same reason from different angles.

A senior reviewer is going to find the boundary between real and aspirational whether or not I mark it. If I've marked it, that's a point in my favor — it reads as someone who knows the difference between architecture and enforcement. If I've hidden it, the first uncomfortable question torpedoes everything else I claimed.

And for me: the table is a worklist. "Designed-but-not-wired" is exactly the set of things to turn into "enforced," in priority order. The honesty isn't just ethics — it's the backlog.

A security claim you can't point to in the code is marketing. The architecture is real and pervasive, several controls are genuinely live, and the rest is written down as designed — not done. Drawing that line is not a weakness in the story. It is the story.

The enforced / designed / roadmap breakdown

Same password as the other GCS posts — or request access below.

Enforced today ✅ LIVE

These aren't aspirations — they're in the codebase and a reviewer can verify each one.

The renderer is untrusted. The desktop UI runs with contextIsolation, sandbox, and nodeIntegration: false. It never receives a device handle or a wire address — the connection endpoint is kept in the main process and is deliberately not part of the data sent to the UI. The only door between them is a typed bridge. The least-trusted surface gets the least access.
The engagement gate is structural, not procedural. You cannot construct an effector-engagement command without an authorization token carrying legal authority and two-person consent. It's a property of the type, so the compiler refuses the unauthorized case — there's no runtime check to forget or bypass. This is the single control I'm most deliberate about.
Commands are capability-gated at the boundary. Every command is checked against the capabilities the connected asset actually declares, in every adapter — a ground rover can't be told to take off, by construction.
Supply chain is gated in CI. A dependency-license allowlist, a production-dependency vulnerability audit, and an SBOM all run before merge. What ships is known and checked.
Air-gapped by default. No network egress at all unless you explicitly opt into a connected posture. The default build can't phone anywhere.

Designed, but NOT yet wired 🟡 DESIGNED

This is the part most projects quietly omit. These are specified — there's a written design — but they are not enforcing anything yet, and hindi ko sasabihin na tapos na (I won't say they're done).

The command pipeline (authorization → safety → rules-of-engagement → airspace → sign → send). The architecture exists and the UI even shows a pipeline status strip — but today the send path goes straight from the bridge to the adapter. That status strip is indicative, not proof. Wiring the stages so every command actually traverses them is the next real piece of work, and it's the backbone the rest of this list hangs off.
Link cryptography — mutual authentication, message signing, anti-replay, fail-secure. Fully specified in the comms-security design. The first real-device adapter currently does the connect/acknowledge handshake but not the signing. Until that lands, "the link is hostile" is a principle the transport doesn't yet back up.
The egress allowlist for the connected (non-air-gapped) posture — designed, not built, because the connected posture itself is still a future option.

Roadmap ◯ NAMED

Role-based access control with per-command re-authorization for the safety-critical command kinds.
An event-sourced recorder with audit-on-deny — every input, every decision, append-only and replayable.

The honest table lives in the repo and gets updated as 🟡 turns into ✅. Next up: wiring the command pipeline, so the status strip stops being a promise and starts being a proof.

Build log entry. Apache-2.0. Part of the multi-domain GCS build log.