The engine gateway is the part of this factory that decides where a task runs: on a local model, on a cloud agent, or as a handoff a human carries by hand. Every task declares a privacy level in its front matter, and the router reads a policy file to learn which engines that level blocks. local-only blocks every cloud engine. That was the whole point of building the thing: a machine-local task should not be able to leave the machine.
Write local_only instead of local-only, though, an underscore where a hyphen belongs, and the router I had been trusting for three weeks would look up the typo in the policy, find nothing, conclude that nothing was blocked, and route the task to whichever engine the rule preferred. Including a cloud engine. For the task whose author had just asked, as explicitly as the system allows, for it to stay home.
The actual problem: silence where an error should be
Nothing about this failure announced itself. Every test I had written used correctly spelled privacy levels, because I wrote the tests and I know how to spell my own vocabulary. The gate passed all of them. The failure mode only exists at the seam between a human’s fingers and the machine’s string comparison, and no happy-path test walks through that seam.
The mechanism underneath is a bug class, not a one-off: a lookup that treats a missing key as an empty result. The router asked the policy “what does this level block?”, got back an empty list because the key did not exist, and an empty blocklist is indistinguishable from a level that genuinely blocks nothing. The gate did not fail. It answered a different question than the one it was asked, confidently, in a way that meant “no restrictions.”
What actually caught it was an expert-panel review: a multi-role critique of the design docs against the running code, with the findings verified by executing the scripts rather than reading them. The panel’s security seat asked the question my tests had not: what happens on a value that is not in the policy at all?
What worked: fail closed, and hunt the accomplice
The fix itself was small. An unrecognised privacy value now stops the router with exit code 1 and a message listing the valid levels. A typo went from silently meaning “no restrictions” to loudly meaning “fix your spelling.” The risk got a number (RISK-0010), a test matrix pinned the behaviour for every level plus the typo case and the empty case, and the same session closed the risk it had opened.
The more interesting find was the accomplice. The same review pass noticed that one of the adapters carried its own hardcoded privacy == 'local-only' check, a second, private implementation of the same policy. It happened to agree with the router that day. It shared the exact typo-fragility, and it contradicted the design principle that the routing policy is the only authority on privacy. Duplicated policy logic does not double your protection; it doubles the number of places the same mistake can hide. The duplicate got deleted and the adapter now delegates to the one real gate.
The part worth stealing
Go find a config-driven gate you own, feed it a misspelled value, and watch what it does. Access rules keyed on environment names, retention rules keyed on data classifications, routing rules keyed on privacy levels: anywhere a string indexes into a policy, the unknown-key branch is the security posture. If that branch returns an empty set, your gate’s real behaviour on the worst day is “allow”, and nothing in your test suite will ever tell you so, because you spelled everything correctly in the tests too.
What Next
Cloud Egress Is a Runtime Property
Next in Governance Without Killing the Joy: the same gateway learns that whether a task's content leaves the machine is a property of how an engine runs, not whose name is on it, and that an automation flag can never consent to egress.