Security¶
The Security section is for people evaluating LegionForge as user-owned AI infrastructure. The Framework and Guardian sections cover how LegionForge enforces checks. This section covers why the model is built around custody, auditability, and human authority.
Pages¶
-
STRIDE applied to agent systems. The kill-chain view: attacker goal → vector → which LegionForge layer catches it (or honestly, doesn't).
-
Side-by-side: what changes when the user is the root of trust instead of a vendor account or an unguarded agent loop.
-
What the Jan 2026 OpenClaw incident exposed about fast-moving agent ecosystems, and which architectural patterns LegionForge addresses.
-
Repository-by-repository coverage map: visible CI, local audit status, deployment surfaces, and the next security question each repo should answer.
Where to go from here¶
- For the technical security model — what runs where, what the deterministic checks look like — see Framework → Security Model.
- For Guardian's specific behavior — the 7 checks, the rule storage, the canary endpoint — see Guardian → Architecture.
- For an introduction to the thinking behind the model — the LLM-is-not-trustworthy thesis, why deterministic, why sidecar — see Concepts → Security fundamentals.
- For operational coverage across repos — what is checked, what is deployed, and what still needs wiring — see Project security inventory.
Reporting vulnerabilities¶
Do not open a public issue for security vulnerabilities. Email security@legionforge.org. We respond within 5 business days. After a fix is in place and users have had a chance to update, we publish a security advisory in the affected repo with the coordinated CVE if one was assigned.