Direct answers, including the unflattering ones.

BitShout is an AI containment tool for macOS: an independent, deny-by-default security boundary between an AI-capable process — a coding agent, an MCP client, a local model — and the resources available to you. Filesystem, network, execution and capability authority are each denied unless explicitly granted, containment follows every child process, and every decision is recorded locally.

No, and deliberately not. BitShout contains AI applications; it is not one. Its policy engine is deterministic, versioned, ordinary code — the same inputs produce the same verdict every time. Using a language model to decide whether another language model should read your keys would reintroduce exactly the unpredictability the product exists to contain.

It means that for a contained subject, no matching allow rule results in denial — including for operations BitShout does not recognise. Authority is not inherited from your account; it is granted, narrowly, by an explicit human decision, and revalidated on every use.

Anything that runs as a process on macOS: coding agents such as Claude Code, Cursor, Codex, Copilot agent mode, Gemini CLI, Aider and Cline; desktop AI applications; MCP clients; and locally-run models wired to tools. BitShout identifies a protected subject by code-signing identity, Team ID, bundle identifier and executable identity rather than by name, so there is no supported-apps list and no dependency on a vendor shipping an integration. One nuance: an AI assistant that runs as an extension inside an editor is part of that editor’s process tree, so containing it means containing the editor rather than the extension on its own.

A sandbox restricts one process using platform mechanisms and is usually adopted voluntarily by the software being sandboxed. Containment is imposed from outside by you, covers a process and all of its descendants, separates authority into distinct domains, and ties every exception to a narrow, expiring, human-approved grant. Sandboxing is a mechanism; containment is an architecture that can use several mechanisms.

Not usefully. EDR is built to identify software doing things it should not do. An agent reading your SSH key is, to the operating system, a process you started opening a file you own — indistinguishable from you doing it. There is no signature for "this was a bad idea". You need a boundary that requires permission in advance, not a detector that reports afterwards.

For high-risk work you should, and that is what Vault Mode is. For everyday work the friction usually wins: containers on macOS are already VMs, people mount their credentials in anyway, and a workflow that is slow enough to be annoying gets abandoned. A native policy boundary is the one that stays switched on, and a security control you turn off protects nothing.

No. It occupies a layer most setups do not have — authority containment for AI processes at the endpoint. It does not replace disk encryption, OS updates, EDR, code review, or credential hygiene, and it is not a general host firewall.

In Guard Mode the agent runs natively — no virtual machine, no translation layer, no filesystem shim in the hot path. A containment decision is a policy lookup over already-resolved identity, measured in microseconds, in the same authorization path macOS already runs. Vault Mode carries normal virtual machine cost, which is why it is a mode you choose rather than the default.

Nothing privileged. Normal startup installs no component, activates no system extension, retrieves no credential, mutates no security state, starts no virtual machine and asks for no password. The verified requirement is written as a number: zero password prompts during passive launch. Everything privileged happens in Settings → Setup, explicitly.

No, if the grant model is doing its job. A grant can be scoped to one action, to the session, or to a duration, so a legitimate need answered once does not come back every thirty seconds. The friction concentrates at setup, which is where you want it — and confirmation fatigue is a real failure mode, so a design that produces it is a design that has failed.

Containment does not go with it. The window is a view onto state owned by a trusted background service and by the operating-system components it drives. If the UI closes, authority does not silently disappear — that is Law 4, and it is why the app is deliberately not the enforcement boundary.

It immediately stops new authority and suspends existing grants across every domain. Recovery is not a dismissal: it requires explicit revalidation of the components involved, and authority created before the lock does not silently resume afterwards.

Production runtime filesystem and execution enforcement, which needs the Endpoint Security entitlement now in review with Apple; remote MCP transport and OAuth brokering; kernel-level fail-lock response; notarized production distribution; and enterprise evidence collection or remote attestation. These are stated on the Trust page and repeated on every page where the capability is described.

Because Law 10 says security claims must be testable, and because a security product that overstates itself is worse than no security product — it produces confident behaviour based on protection that is not there. If a claim cannot be tested against the documented threat model, it does not appear.

A policy denial is BitShout deciding an operation should not happen. An OS denial is the operating system actually refusing it through a BitShout-controlled authorization path. They look identical in a screenshot and are not the same security claim. BitShout labels them separately in the interface, the audit log, every export and the underlying schema, and reserves the word "blocked" for the second.

No, and any product claiming to is overselling. Prompt injection is a property of how language models process untrusted text and will not be solved at the endpoint. What changes is the consequence: an injected instruction still has to become an operation, and that operation still has to pass a deny-by-default policy it cannot argue with.

No. Policy, grants, credential references, evidence, diagnostics and containment decisions stay on your Mac. There is no mandatory telemetry, no automatic diagnostic upload and no cloud analysis step. Exporting evidence is an explicit action you take, and the export is redacted.

It does not collect file contents for the purpose of policy evaluation, and the planned network filtering model does not require packet payload inspection. What it processes is the metadata a containment decision needs: subject and process identity, code-signing metadata, resolved resource identity, network endpoint metadata, execution target metadata, grant scopes, capability identifiers and component health.

Credential secrets referenced by the capability broker are held by the macOS Keychain and remain broker-owned. They are used to perform an approved operation and are never handed to a protected application or to a Vault guest. There is no raw token retrieval API and no "reveal secret" operation.

macOS 15 or later, on Apple silicon or Intel. Vault Mode requires Apple silicon. System extension approval requires administrator consent once, during setup. No network connection is required to run, and there are no third-party dependencies.

BitShout is at version 2.1.12. Apple has granted every entitlement it needs except one — the Endpoint Security client entitlement, which is submitted and in review. Everything is built and passes its full suite on real hardware in our lab. Rather than ship claiming enforcement we have not verified in production, general availability is held until that approval lands.

Not at present. The architecture is published in detail — ten documentation pages covering every authority domain, the threat model and the security laws — so the design can be evaluated on its merits rather than taken on trust.