Safety Architecture & Validation Status
A KVM can send input while the operating system is unavailable, so mistakes can affect the whole machine. The Comet prototype supports screen reading and input. The MCP server implements tier gates, stale-frame checks, dry run, an out-of-band approval step for media and power actions, and an owner-only hash-chained audit log. These controls have mock tests; only read-tier MCP operation has real-device evidence. They do not sandbox an agent or cover every access path.
Core Principle: Screen text is untrusted
Screen content can contain instructions aimed at an AI agent. The design requires the agent to treat that content as data and to use an independent operator instruction before taking consequential action. Enforcement of this rule is planned.
Implemented MCP capability tiers
The operator chooses read, input, media, or power capabilities at server startup. Effect classification treats reboot keystrokes as power operations. Read-tier use was checked on the real Comet; input, media, and power gates were checked against a mock. The input tools also ran once on the real Comet through an in-process test client, typing three letters at a login prompt and clearing them; that run kept no audit file and is listed on the usage page, not counted as a hardware test of the tier. No physical ATX power controller is established by these tests.
Implemented controls and remaining work
MCP controls include stale-frame references (every input retires the frame it aimed at and returns a fresh observation), an out-of-band approval step for media and power (a person runs an approve command in a real terminal; tested on a mock only), a typed phrase mode that is not a human gate, a kill switch, rate limits, dry run, digit re-entry, and a hash-chained owner-only audit log. Session recordings redact typed text when a password prompt is seen or the screen cannot be read. These controls reduce specific risks; they do not guarantee safe actions.
The server marks itself non-dumpable, so another process of the same user cannot attach a debugger to it or read its environment, which holds the KVM password. An optional sandbox wrapper hides the home directory and makes the file system read-only for the server; it does not restrict the network. Independent reviews of the code and of the gates found faults, among them a repeated modifier that let Ctrl+Alt+Delete past the gate on the NanoKVM and Ctrl+Alt with the keypad Delete passing as plain input. Each was reproduced on a mock and fixed with a test. The keypad chord has not been tried on a real target.
A server controller can tie seeing to typing. On the one Dell iDRAC9 we ran, the account that may take a screenshot can also open the interactive console. Bootscry's driver never sends input there, but the credential allows it (iDRAC first runs).
Showing that a real client displays the approval prompt to a person, elicitation (not built), approval for typed keyboard input (tier only today), physical validation of non-read MCP tiers, and safety across future channel drivers remain open. Screen and console text is untrusted data; a model may still follow malicious instructions. Direct CLI or service access does not inherit every MCP gate.
See the research agenda and physical-board evidence and its intervention limits.
What we do not claim yet
We do not call Bootscry isolated, air-gapped, zero trust, tamper-proof or compliant with any framework. We do not say it works offline, that approval is human approval (no real client run has shown a person saw the prompt), or that input, media or power tiers are tested on hardware. We use no certification word. Each claim has a gate that has not passed. The list and the gates are on the threat model page.