Trust

A security product that overstates itself is worse than none.

Law 10 says security claims must be testable. That obliges us to publish the limits alongside the capabilities, in the same detail, on the same page — not in a footnote after you have already installed it.

Current status

Every boundary is built. One Apple approval is outstanding.

BitShout's containment boundaries are complete, and every one of them passes its full test suite on real hardware in our lab — filesystem, network, execution, capabilities, fail-lock, evidence and Vault isolation. Apple has granted every entitlement the product needs except one. The Endpoint Security client entitlement is submitted and in review.

System extension installationcom.apple.developer.system-extension.installLets the host app install the two system extensions

Approved

Network Extension · content filtercontent-filter-provider-systemextensionPer-flow network authorization through NEFilterDataProvider

Approved

Virtualizationcom.apple.security.virtualizationVault Mode virtual machines on Apple silicon

Approved

Endpoint Security clientcom.apple.developer.endpoint-security.clientFilesystem and execution authorization at the OS boundary

In review with Apple

Until that last approval lands we cannot complete production runtime verification of the filesystem and execution paths on customer machines — so the list below still does not claim it. That is a statement about what we have proven in production, not about whether the mechanism works. Everything else on this page stands on its own evidence.

Built and verified

A deterministic, non-LLM policy engine across filesystem, network, execution and capability domains
Process identity, code-signing identity, audit tokens, lineage and containment sessions
Canonical filesystem resource identity with symlink resolution and device/inode evidence
Byte-level network endpoint classification and source attribution
Execution target identity covering binaries, scripts, interpreters, shells and exec replacement
A narrow grant model with revalidation on every use, expiry, and revocation
Local stdio MCP brokering with exact tool registration and broker-owned credential custody
Protection health, Panic Lock, tamper-evident state validation and recovery gates
Hash-chained local security evidence with redaction, retention, query and export
Vault Mode isolation verified live on Apple silicon under Virtualization.framework

Not claimed yet

Production runtime filesystem and execution enforcement: The Endpoint Security adapter is built and its policy path is proven, and the full suite passes on real hardware in our lab. Production runtime denial additionally needs the Endpoint Security entitlement, which is in review with Apple, so we do not claim it yet.
Remote MCP transport and OAuth brokering: HTTP and streaming HTTP endpoint identity are modelled in the domain. Live remote transport is not part of the proven path.
Kernel-level fail-lock response: Lock behaviour is proven at BitShout service, policy, authorization and broker decision points.
Notarized production packaging: Signing identity, entitlements and the release gate all exist. Notarized distribution follows the last entitlement approval.
Enterprise evidence collection and remote attestation: Deliberately out of scope for the initial roadmap.

Honest labelling

Two words that are never swapped.

When BitShout's policy engine decides an operation should not happen, that is a policy denial. When the operating system actually refuses the operation through a BitShout-controlled authorization path, that is an OS denial. They look identical in a screenshot and they are not the same security claim.

The interface labels them separately. So does the audit log, so does every export, and so does the schema underneath. The word "blocked" is reserved for the second one.

Policy Denied≠OS Denied

Local-first

What BitShout touches, and where it stays.

Policy, grants, credentials, evidence, diagnostics and containment decisions remain on your Mac by default. An audit trail must not become a second privacy problem, so redaction runs before anything is written, not before it is shown.

Processed: Subject identity, process identity and lineage, code-signing metadata, relevant filesystem paths and resource identity, network endpoint metadata, execution target metadata, authorization requests and grant scopes, capability identifiers, Vault runtime manifest metadata, component health, and redacted evidence.
Not processed: File contents for the purpose of policy evaluation, and packet payloads for the planned network filtering model.
Not transmitted: Nothing. There is no mandatory remote telemetry and no automatic diagnostic upload. Export is an action you take.
Not exposed: Reusable credentials. They remain broker-owned and are never handed to a protected app or a Vault guest.

See the privacy policy for the site itself, which is a static site with no accounts, no forms and no analytics beyond ordinary server logs.

Passive by default

Launching BitShout does not change your machine.

Normal startup installs nothing, activates no system extension, retrieves no credential, mutates no security state, starts no virtual machine, and asks for no password. The verified requirement is stated as a number:

0 password prompts during passive launch

Everything privileged happens in Settings → Setup, in an explicit order, with each component showing whether it is installed, approved by macOS, active and verified — plus the specific next action if it is not.

Setup required is not the same as protection locked. A component that was never installed has made no protection claim to fail. A previously healthy component that disappears is a runtime boundary failure, and BitShout says which one it is looking at.