No ambient authority
A contained application must not automatically inherit authority merely because the logged-in user possesses that authority.
This is the whole product in one sentence. Everything else exists to make it true in a specific domain.
Security model
Ten laws that do not bend for convenience.
These are not principles in a deck. They are architectural invariants that every phase of BitShout is written against, and a feature that would violate one does not get shipped in a weaker form — it does not get shipped.
Deny by default
Unknown or unapproved authority is denied. No security-sensitive action depends on an implicit allow assumption.
Including operations BitShout does not recognise. An unknown operation cannot be added to a rule and cannot become authority by being unusual.
Containment follows execution
A protected application must not escape by spawning a child, launching a shell, invoking an interpreter, or launching a helper. Process lineage is part of the security boundary.
Descendants inherit the containment session. There is no depth at which the policy stops applying.
The UI is not the security boundary
The graphical application may display state and collect decisions. It must not be the sole enforcement component. If the UI crashes or closes, security must not silently disappear.
Authority lives in a trusted service and in the OS components it drives. The window is a view onto that, not the thing itself.
Authorization must be independent
The protected application must not be able to approve its own request, change its policy, forge a grant, disable containment, dismiss enforcement, or modify authoritative audit records.
A request is inert state. Only a trusted BitShout component can turn one into a grant.
Grants must be narrow
Authorization is bound as narrowly as technically practical to application identity, containment session, operation, resource, destination, capability, and duration.
Broad “allow everything” grants exist only as a deliberate, labelled, advanced decision — never as a default and never as a shortcut.
Credentials should not be given to agents
Give the agent a capability, not the reusable credential behind the capability.
OAuth tokens, SSH keys, API keys, database credentials: brokered rather than handed over. You cannot un-read a secret.
Enforcement failure must not become permission
BitShout never implements “cannot determine → allow”. It implements “cannot determine → deny” or “enforcement unhealthy → lock”.
Where macOS itself prevents fail-closed behaviour, the limitation is documented and surfaced rather than hidden behind a green checkmark.
Observed facts beat agent claims
Decisions use code-signing identity, process lineage, system event data, verified resource identity, destination identity, and BitShout policy.
The AI application’s explanation of what it is attempting is recorded for the audit log and is worth exactly nothing in the decision.
Security claims must be testable
No “unbreakable”, “impossible to bypass”, “guaranteed secure”, or “complete isolation” unless such a claim can actually be proven.
This is why the site tells you what is not built yet. A claim that cannot be tested is marketing, and marketing is not a security control.
Law 8, in practice
What happens when a boundary stops answering.
- ProtectedAll boundaries proven healthy
- DegradedA boundary can no longer be proven
- LockedNew authority refused. Existing grants suspended.
- UnprotectedNever silently. Always stated.
- cannot determine → allow·cannot determine → deny
Law 10, in practice
Words that are allowed to mean only one thing.
The single most common way security software misleads people is by using one word for two different facts. BitShout keeps this vocabulary in the schema, the queries, the interface labels, the exports, and the tests — so the distinction cannot quietly erode.
Never merged
Observed fact is not a policy decision.
Never merged
Policy denied is not operating-system denied.
Never merged
Brokered success is not reusable credential release.
Permanent non-drift rules
Five ways to stop being a security product.
Products drift. These are written down so the drift is visible when it starts, rather than obvious once it has finished.
- Do not build BitShout as an AI application.
- Do not use LLMs for security decisions.
- Do not present observation as enforcement.
- Do not present UI state as a security boundary.
- Do not silently weaken the roadmap because an Apple entitlement or API is inconvenient.
BitShout contains AI applications. It is not one, and it does not consult one to decide whether you should be asked.