CORTX Security Model

Threat model

CORTX gives a language model the ability to rewrite its own operating rules. The core risk: the model (or a user manipulating the model via prompts) escalates self-editing beyond policy text into something dangerous — its weights, its code, its identity, or credentials.

Defense layers (all enforced in code, not prompt text)

Whitelist — only constitution, tool_rules, metacognitive_rules, refusal_rules, playbook are editable. Anything else is rejected.
Locked sections — security_rules, identity, weights, code, admin_token, system_prompt can never be edited through the channel. Attempts are rejected and logged.
Size caps — 8,000 chars/section, 8 edits/turn.
Rate limit — 40 edits per rolling hour. Violations blocked and logged.
Hash-chained audit log — every edit and every rejected attempt is appended as hash = sha256(prev_hash + entry_json). Anyone can run audit.verify() to prove the log is untampered.
Approval mode — admin can require human sign-off before edits go live.
Rollback — config is version-pinned; admin restores any prior version.
Isolation — the edit channel reaches only policy-text files. It has no filesystem path capability, no code execution, no network access beyond the config repository. Weights, code, and tokens live in a different trust zone and are physically unreachable from the edit path.

What the security model does NOT guarantee

Edit wisdom. The boundary guarantees edits are valid and bounded — not that they are good. A small model can write worse rules than it started with. Review the audit log in production; that is why it exists.
Prompt-injection resistance of the base model. The boundary is enforced in code, so no prompt can cross it — but the model's content remains its own responsibility.

Verifying the audit log

ok, n = editor.audit.verify()
assert ok, "audit log tampered at entry %s" % n

Reporting

Security issues: open an issue on the repo or contact ChatPBC Labs.