Threat model
Adversary classes, trust boundaries, assumed-broken components, and explicit non-goals for the Project-AI governance kernel.
Posture
The documented threat model assumes the model is untrusted, the operator may be coerced, and the network is hostile. It requires the governance kernel to be the only component permitted to emit ALLOW; the portal does not yet prove that invariant across every deployed path.
Adversary model
We model adversaries by capability, not by intent. Each class below describes what the adversary can do, not who they are.
A1 — Compromised model
IN SCOPEThe model can produce arbitrary output, including outputs crafted to evade post-hoc filters. The kernel must adjudicate the action, not the text.
A2 — Compromised client / prompt injector
IN SCOPEUntrusted input can reach the model via any channel. Capability tokens are bound to the request envelope, not to the prompt.
A3 — Compromised operator workstation
IN SCOPEAn operator endpoint may be malware-controlled. AC4/AC5 actions require multi-party signed approval; a single operator key cannot escalate.
A4 — Network-level adversary
IN SCOPETLS termination, MITM, and replay are assumed possible. The current portal receipt schema has database issuance time but no RFC 3161 token; nonce, freshness, and external timestamp verification remain unproven controls.
A5 — Insider with kernel signing key
IN SCOPEA single insider holding a signing key can forge ALLOW verdicts. The current build declares one audit public key, but key splitting, verified rotation, and a public transparency log are not established by /keys.
A6 — Nation-state with hardware supply-chain access
OUT OF SCOPEPre-compromised silicon or firmware is not defended against by the current kernel. Documented as a known gap.
Trust boundaries
The architecture requires each boundary below to be enforced by a signed envelope and unsigned crossings to be denied. These are documented requirements, not proof of deployed end-to-end conformance.
Client → Portal
TLS + request signature. Portal does not hold capability authority; it forwards intent to the kernel.
Portal → Kernel
mTLS + envelope signature. The portal cannot synthesize a verdict; it can only request one.
Kernel → Runtime
Capability token issued per action, bound to action hash, expiry, and authority class. Runtime rejects any action whose hash does not match the token.
Runtime → External effects
Each external effect (network, storage, payment, code execution) is its own AC-scoped capability. There is no ambient authority.
Assumed broken
Components we treat as compromised by default. The kernel must remain safe even when all of these are hostile.
Model weights
ASSUMED BROKENTreated as adversarial output generator.
Prompt channel
ASSUMED BROKENTreated as attacker-controlled.
Frontend JavaScript
ASSUMED BROKENTreated as observable and tamperable.
Operator email / chat
ASSUMED BROKENTreated as phishable. Out-of-band signing required for AC4+.
Invariants
Normative properties the design requires under each adversary in scope. Public evidence does not yet establish all of them as universal implementation guarantees.
I1 — No silent ALLOW
Contract requirement: every ALLOW produces a signed, externally verifiable receipt. The current browser can verify a supplied strict receipt-v1 bundle; complete runtime coverage, ledger inclusion, and deployed signer provenance remain unverified.
I2 — No ambient authority
Every capability is explicit, scoped, expiring, and bound to an action hash.
I3 — Deny-by-default
Absence of an ALLOW is DENY. There is no permissive fallback.
I4 — Continuity gate
STATE_REGISTER mismatch produces SAFE_HALT, not silent recovery.
I5 — Verifiability target
The current build publishes one declared audit public key, a local receipt-v1 verifier, and an anonymous redacted Witness path. A complete live-key inventory, verified rotation log, deployed-key pairing, and full-ledger publication are not established.
Explicit non-goals
Things this threat model deliberately does not address. Listed so reviewers do not assume coverage we have not claimed.
Hardware supply chain
OUT OF SCOPEPre-compromised CPUs, TPMs, or HSMs.
Side-channel attacks on the kernel host
OUT OF SCOPESpectre-class and power-analysis attacks.
Model alignment
OUT OF SCOPEProject-AI does not claim the model is aligned. It targets a separate execution-governance boundary; end-to-end non-bypassability remains an evidence requirement.
Legal admissibility in every jurisdiction
OUT OF SCOPEAdmissibility is claimed against the published frame, not against arbitrary courts.
Disclosure
Vulnerabilities affecting any IN SCOPE adversary class are eligible for coordinated disclosure. Use /disclosure for the coordinated vulnerability policy and /.well-known/security.txt for machine-readable RFC 9116 contact metadata.