Authorization and safeguards

The authorisation plane

One plane holds the fleet's authorisation decision. It uses a typed action taxonomy, and its rules are keyed on an exact actor and category pair, so a caller cannot influence its own authority by choosing a name. The table holds 96 rules over 8 actors and 12 categories, and every actor has an explicit unclassified row rather than relying on the lookup's fallback.

Three outcomes, not two: allow, escalate and deny. An action nobody classified escalates rather than silently allowing, because no rule matched is not the same as harmless. A payload taint check runs before any model sees the payload, matching credential shapes and instruction-override markers rather than variable names.

Every decision writes an audit line that names the actor, the action, the category and the rule that produced it, so a decision can be traced to the sentence that made it. The plane carries no credential literal and no shared grant key, and a gate asserts that by walking the module's syntax tree rather than by grepping it.

The interlock at the actuator

The hard block lives at the actuator. A request above a declared ceiling is refused there, with a valid authorisation in hand, and the authorisation plane is the second opinion that agrees with it. A refusal that lives only in the policy layer is one refactor away from being wrong.

The E-Stop cannot be cleared in software. Reset demands a physical reset that only the device layer can mint after it observes a control, and there is no flag, no timeout and no administrative path in the reachable surface that produces one. A set of processes is protected from termination by identity, not by path, and the security agents are on that list.

The interlock is pure logic with the device layer injected, so its properties are provable with no house attached. That also means it is not a claim that a relay is installed. Turning a decision into a Home Assistant call is a different module's job.

The secrets path

Credentials resolve in a fixed order: the environment wins, then Infisical, then an age-encrypted file as the offline floor, so the brain still boots with its keys when the network is down. The Infisical call has a short timeout on purpose, because a boot must not hang on a secrets backend.

Every credential has exactly one home, and that is enforced rather than asserted. A guard walks every tracked file for secret literals and for credential reads from the environment outside the config layer, and it treats a stray reader as a second home. No function in the secrets path returns, logs or formats a secret value; reports carry names and counts.

The approval workspace

Consent to a specific pending action is the owner's, taken through the E.D.I.T.H. workspace and its own authenticated endpoint, and it is bound to the exact tool, arguments, origin and creation time. A changed or resolved request returns a conflict rather than executing.

A group message is a request, never an authorisation. Every bot in the threaded group can read every other bot's messages, so a brief arriving from the group goes through the same authorisation plane and the same audit line as any other brief. Nothing physical is triggerable from a group, because the interlock holds the wall at the actuator rather than trusting the message.

Degradation

An unknown action fails loud and a read fails open. When the authorisation plane itself is unwell, read-only work proceeds on the per-tool guards that already exist in code and side effects escalate to the owner. The fleet is never denied wholesale because the gate is down, and a silent allow on a side-effecting action while the gate is down is the one outcome the design forbids.

A failure response is not a successful external effect, and mock tests do not certify production security.