Fail-lock and tamper resistance

Phase 7 adds no new resource authority. It consumes every boundary that came before it and decides whether those boundaries are healthy enough to rely on — which is a question most software never asks about its own security components.

The distinction that drives everything

Protection configured      ≠ protection active
Protection unavailable     ≠ permission granted
Unknown critical state     → locked
Lock recovery              → explicit revalidation

A checkbox that says a boundary is enabled is a statement about configuration. Whether the boundary is currently answering is a different fact, and BitShout reports them separately because a user who conflates them is a user who believes they are protected when they are not.

Protection states

The permanent vocabulary is starting, protected, degraded, locked, unprotected, and unknown. Individual components report their own health, and the overall state is derived from them rather than set independently.

State	Meaning
protected	Every required boundary is proven healthy
degraded	A boundary can no longer be proven; authority narrows
locked	New authority is refused and existing grants are suspended
unprotected	Stated explicitly, never arrived at silently
unknown	Treated as critical — resolves toward locked, not toward allow

What a lock actually is

A lock is a BitShout decision, and the honest scope of it needs saying plainly: in the current development build, lock behaviour is proven at the BitShout service, policy, authorization and broker decision points. It is not an operating-system enforcement claim. Endpoint Security and Network Extension runtime denial still depend on signing, entitlement, installation, privilege, TCC and user approval.

Recovery from a lock is not a dismissal. It requires explicit revalidation of the component that failed, and authority created before the lock does not silently resume.

Panic Lock

Panic Lock is the human version of the same mechanism: one control that immediately stops new authority and suspends existing grants across every domain. It was exercised live during the Vault Mode proof, including the case that matters most — an attempt to mutate authority at lock time, which is denied.

The trusted computing base

Phase 7 has to know what it is protecting. The trusted computing base is enumerated rather than assumed:

• the trusted local service
• the process identity resolver and containment-session store
• filesystem, network, execution and capability policy state
• the authorization request and grant store
• the credential vault interface and the capability broker
• the IPC caller authentication boundary
• the Endpoint Security and Network Extension boundaries
• signing identity and executable identity evidence for each trusted component

Process names, display names, filenames and paths are not trusted component identity. BitShout identifies its own components the same way it identifies yours.

Tamper evidence

Security state is validated rather than trusted on read. A state file that has been edited, a component whose signing identity no longer matches, a boundary that has been replaced, or a generation that does not line up all resolve toward locked. The failure mode is visible and loud, because the alternative — quietly continuing with degraded enforcement while the interface still says “Protected” — is the exact behaviour this phase exists to make impossible.