AuthorityBridge

The AuthorityBridge is the single deterministic chokepoint between an AI's recommendation and your fleet. Without it, an LLM that hallucinates a `wazuh.isolate_agent.v1` could quarantine half your hosts at 3am. With it, the same LLM proposes the same action and the bridge gates it against your operator-configured trust level, your tier ceiling, the action's risk lock, and your license entitlement — taking the strictest answer.

Other AI-security tools either ship fixed autonomy (the AI is at the same level on day 1 and day 365) or ship binary on/off. CyberCLI is the only product in the category where you set the dial per action template, watch the calibration log, and lift the ceiling as a role proves itself. The bridge is the engine that makes that earned-trust story real — not a marketing claim.

Forensically, the bridge is also the engine that gives you the receipt. Every decision the bridge makes — whether it blocks, queues, vetoes, or executes — is written to the hash-chained audit log with the actor, the model, the trust levels applied, the resolved ceiling, the action template, and the outcome. Replay the row two years later and you can answer who decided what, against which evidence, at which level.

On each action proposal the bridge resolves four ceilings — the operator's configured trust level for this template (from `[trust_ladder]` in config.toml), the tier ceiling (Free=4 / Starter=5 / Pro+=7), the action's manifest-locked risk ceiling, and the license payload's per-category ceiling — and picks the strictest as the `effective_level`.

The effective level routes the action to one of eight outcomes. L0 → `BLOCKED_RISK_LOCK` (the action is hard-locked off; the manifest doesn't allow it at this tier). L1 → `OBSERVED` (audit only, no operator notification). L2 → `SHADOWED` (would-have-done logging, no operator notification). L3 → `QUEUED_FOR_APPROVAL` (notification with approve/reject links). L4 → `VETO_WINDOW` (notification with a 24h veto window before the executor fires). L5 → `APPROVED_WITH_ALERT` (autonomous fire + page operator). L6 → `APPROVED_AUTONOMOUS` (autonomous fire + dispatcher notification). L7 → `APPROVED_AUTONOMOUS` (autonomous fire, log-only — explicitly for actions where the operator does not want to be paged, like silent firewall enforcement).

When the bridge routes to L5 / L6 / L7 it calls the registered Executor for the action's `action_template_id`. The executor is per-connector (Wazuh, Unifi, M365) plus built-in no-ops for templates like `notify_only.v1` whose externality is the dispatcher's notification, not the gate's execution. Executor failures are caught and re-routed to `EXECUTED_FAILED` so the audit row is honest about what actually happened.

Every outcome lands on the audit log as a single row with the prev_hash + entry_hash linkage that makes the chain tamper-evident. The row carries the resolved levels, the action_template_id, the actor (AI or human), the model_route, the confidence score, and the rollback_state where the executor captured it. The audit log is the only place an after-the-fact replay reads.

Stable — the bridge has been on the v1 acceptance install since 2026-06-03 and has gated every action since (51+ signals as of 2026-06-07). The Trust Ladder + risk-lock + license-ceiling math is locked in `_resolve_ceilings` and covered by 60+ unit tests.

Known limit: L6 currently dispatches identically to L5 (autonomous + dispatcher notification). The intended L6 semantic of 'autonomous + batched digest' lands in v1.x when the batched-delivery scheduler ships.

Known limit: the bridge defaults to `Tier.PRO` in unit tests where the runtime wiring is not present. In `build_runtime()` the actual license tier is now threaded in (r31 fix, commit c89aed4) — any harness that constructs the bridge by hand should pass `tier=` explicitly to match the operator's license.