---
title: "Security overview"
description: "What protects what, what is wired into the shipped app, and which claims have tests."
url: https://barestate.xyz/docs/security/overview
---

# Security overview

> What protects what, what is wired into the shipped app, and which claims have tests.

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

**Warning:**
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

| Mechanism | What it protects | In the shipped app | Tests |
|---|---|---|---|
| [Signer](https://barestate.xyz/docs/security/signer) | Keys, from the model | Not connected | Yes, as a component |
| [File-read guards](https://barestate.xyz/docs/security/file-read-guards) | Key folders and the pinned verifier | Yes | Yes |
| [Shell guard](https://barestate.xyz/docs/security/shell-guard) | The same paths, from shell commands | Yes, best effort | Yes, with four known gaps |
| [Sandbox](https://barestate.xyz/docs/security/sandbox) | Home folder, keys, network, writes | macOS Seatbelt, or Docker. None on Linux host mode | Yes for Seatbelt, partly for Docker |
| [Credentials](https://barestate.xyz/docs/security/credentials) | Your provider keys and OMS token | Yes | Mostly |

## 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.](https://barestate.xyz/docs/images/diagrams/security-layers-light.svg)

*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.