BitShout is independent, self-funded, and built by a small team on macOS for macOS. It exists because a specific gap kept going unfilled: everyone shipping AI agents was addressing what the model would say, and nobody was addressing what the process could reach.
Run a coding agent on a developer's Mac and watch what it actually has. Your SSH keys. Your cloud credentials. Every repository on the disk, including the client work. Your browser's session cookies. Your VPN and everything behind it. Not because anything is misconfigured — because the agent is a process you started, and processes get everything you have.
That has been true of every program since the beginning, and it was survivable while programs did what their source code said. An agent's next action is generated at runtime, from input that anyone who can file a GitHub issue can influence. The old bargain — inspect the software, then trust it — has nothing left to inspect.
There was no product for this. There was not even a settled word for it, which is why defining the category was part of the work rather than marketing around it.
These are not aspirations. Each one has removed something from the roadmap that would have been easier to ship and easier to demo.
Every security control that lives inside an AI application is enforced by the component an attacker is trying to influence. That is not a boundary; it is a preference with good intentions. BitShout is a separate, privileged component precisely so the contained process has no standing to argue with it.
It would be trivially easy — and quite marketable — to have a language model classify whether a request looks dangerous. It would also be non-deterministic, unauditable, and attackable through exactly the channel the product exists to contain. The policy engine is ordinary code with a version number.
The most common lie in security software is a word doing double duty. "Blocked" is reserved for an operating-system denial through a BitShout-controlled path. A policy decision reads "Policy Denied". Those two strings are never interchangeable, in the interface, the audit log, the exports or the schema.
A security product that overstates itself is worse than no security product, because it produces confident behaviour based on protection that is not there. Where a capability depends on an Apple entitlement still under review, that is written in the same paragraph as the capability — not in a footnote.
The formal version of these is the ten security laws, which every phase of the architecture is written against.
The source is not public today. The architecture is: ten documentation pages covering process identity, filesystem, network, authorization, execution, the capability broker, fail-lock, evidence, Vault isolation and production hardening — each stating what it identifies, what it decides, what it refuses to infer, and what it does not claim.
That is deliberate. A security design should be evaluable on its merits rather than taken on trust, and the parts that matter for evaluation are the model and its boundaries, not the line count.
Vulnerability reports, disclosure coordination, and anything you believe breaks a stated boundary. These get read first.
security@bitshout.appQuestions about data handling, evidence storage, or the privacy policy.
privacy@bitshout.appProduct questions, corrections to anything on this site, and disagreements with the architecture — the last of which are genuinely welcome.
hello@bitshout.appFound something we claim that is not true? That is the most valuable message you can send. Law 10 says security claims must be testable; a claim on this site that fails a test is a bug in the product, not a wording problem, and it will be corrected here.