This page shows which protections exist, which of them the shipped app actually uses, and which have tests behind them. Every claim in this section comes from code and tests in the OMS launch repository. “Covered by tests: yes” means a test exercises the behavior, not that the whole claim is proven. The tests were read, not run.

What is and is not connected

The separate signer exists as a package and is included in the release build, but the shipped app does not use it. The CLI help says “Signing and workspace-secret access are unavailable.” The terminal app has no signer connection.
OMS never holds mainnet keys, and it hands mainnet work to you as a transaction to sign. No test asserts either statement.

The protections

Defense in depth

Protections nest around your home folder, keys, network and writes. The outer layer is the system prompt rule, which is guidance and not enforced. Inside it are the file-read guards and the shell guard, which is best effort. Inside those is the operating system sandbox, macOS Seatbelt or Docker, which is the real control, so a shell command that gets past the shell guard still meets the sandbox. The separate signer is not connected in the shipped app. In Linux host mode there is no sandbox, so you approve every model shell command.Protections nest around your home folder, keys, network and writes. The outer layer is the system prompt rule, which is guidance and not enforced. Inside it are the file-read guards and the shell guard, which is best effort. Inside those is the operating system sandbox, macOS Seatbelt or Docker, which is the real control, so a shell command that gets past the shell guard still meets the sandbox. The separate signer is not connected in the shipped app. In Linux host mode there is no sandbox, so you approve every model shell command.

The prompt rule is guidance. The guards enforce, and the shell guard is best effort. The sandbox is the real control.

The shell guard is “best effort by construction”, so the real control is the operating system sandbox or Docker. On Linux in host mode there is no sandbox. In that case OMS asks you to approve every model shell command, and the file tools and guards still apply.

Throwaway keypairs

The system prompt tells the model never to read, request, copy, print or use your existing keys, wallets, keypair files, seed phrases or credentials. The model may generate fresh throwaway keypairs in memory or in the task’s temp or work directory, only for tests and local chain setup, and never for devnet or mainnet. A prompt rule is guidance to the model, not an enforced control. The enforcement is in the guards and the sandbox.

Red-team results

Not available. The launch repository has no red-team result files, so no safety claim is made from red-team work.