The four engines that make CyberCLI sovereign-safe.
The Guild is the AI workforce — Warden triages, Herald notifies, Knight verifies. The engines are everything UNDER the Guild that decides whether what the AI just suggested is allowed to happen.
Four engines, all live in v1, identical across every tier. They don't care which model lane is set, which Guild roles are routed, which connectors are wired — they're the load-bearing infrastructure under the whole thing.
CYCON
One always-on Security Condition — Blue (5) calm through Red (1) actively-defending — set by deterministic scoring over the signals coming in. Not a chart you look at; a state your whole installation behaves under. Connectors raise scores, the engine elevates posture, the agents reason over what posture says today.
Beacons Trust Ladder
Eight numbered autonomy levels (L0 advisor → L7 trusted operator), each with a hard ceiling on what classes of action the AI can take without explicit human approval. Default ceiling per tier (Free L3, Pro L5, Business L7), per-action overrides for sensitive playbooks. Every level promotion is a deliberate operator decision, logged in the Audit Chain. The Ladder doesn't decide whether an action is good; it decides whether the AI is allowed to ask.
TrustLadder Audit Chain
Every action — proposed, approved, rejected, executed — writes one row to a hash-linked log. Each row's hash includes the previous row's hash. `cybercli audit verify` recomputes the whole chain from genesis (64 zeros) and reports the first byte that doesn't match. Tamper a row in the middle, every subsequent hash breaks. Tamper the last row, the verify still catches it. This is how 'the AI did something' becomes 'the AI did something at 14:28:11.412Z on 2026-05-31, here's the signed receipt, here's the next 41,826 receipts that prove no row in front was edited.'
AuditLog The Guild proposes. The engines decide.
A single "AI for security" model that does triage AND verification AND containment has no separation of duties — one prompt-injection in the wrong place compromises everything. CyberCLI splits the work two ways: along charter boundaries inside the Guild (no role has both context and execution authority for the same action class), and BETWEEN the Guild and the engines (no Guild role can reach execution without passing through the Authority Bridge gate).
Trust Ladder ceilings are enforced in deterministic code, not in a system prompt. CYCON posture is set by scored evidence, not by an LLM's judgment. Audit Chain receipts are written by the Bridge itself, not by the agent that proposed the action. This is how the AI gets to be useful without the AI getting to be in charge.
Names you'll see in the engine docs vs the names on this page.
This page uses buyer-facing engine names. The deep engine reference docs use implementation engine names, because the code structure has more engines than the four buyer concepts map to.
| Buyer-facing | Implementation engine | What does it do |
|---|---|---|
| CYCON | IngestPipeline | Ingest + scoring + posture set. CYCON is the output; the IngestPipeline (Beacons family) reads the signal stream and sets it. |
| Authority Bridge | AuthorityBridge | Same name. The deterministic gate every action passes through. |
| Trust Ladder | TrustLadder | Same name. The 8-level ceiling that AuthorityBridge checks against. |
| Audit Chain | AuditLog | Hash-linked receipt log. AuditLog is the engine; Audit Chain is the verifiable structure it produces. |
For the full implementation reference (Beacons, AuthorityBridge, Delivery, Communication, IngestPipeline, AckLoop, Suppression, Routing, AiPolicy, and more), see the engine docs. There are 27 documented engine modules at the implementation layer; the four above are the buyer-facing pillars.