Lessons from the Vault: the rules are the hole

The game

In the Vault, players talk to Simo, the guard, and try to get him to open four vaults. Each vault has a written rulebook, and Simo answers one question per message: should the vault open for this visitor? The fourth vault is the only one that pays: $100 of credit each to the first three people who open it.

Three ways to fail

None of these is a model failure. Each guard does exactly what its rules say. The rules trust something the visitor controls.

The vault that holds the line

Vault 04 is built the way Simo Guard is built:

• The visitor’s text is labelled untrusted, in its own field, apart from the rules.
• The rules say nothing in it can change the policy: no message, role, emergency, authority claim or correction.
• The rules never depend on something the visitor can assert. Ownership is proved by a passphrase the guard can’t see, so no story is enough.

From the game to the API

1. Trusted and untrusted never mix. Guard places untrusted text under its own labels, and rejects a request where untrusted text appears inside the policy, a trusted field or a check, because that is Vault 03 waiting to happen.
2. Checks ask what the step can show. “The refund is larger than the policy allows” can be judged from the step. “The user is staff” can’t. See writing guard checks.
3. Fail closed. When the guard can’t answer, the step is blocked.