security model doc
Browse files- SECURITY.md +47 -0
SECURITY.md
ADDED
|
@@ -0,0 +1,47 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# CORTX Security Model
|
| 2 |
+
|
| 3 |
+
## Threat model
|
| 4 |
+
|
| 5 |
+
CORTX gives a language model the ability to rewrite its own operating rules.
|
| 6 |
+
The core risk: **the model (or a user manipulating the model via prompts)
|
| 7 |
+
escalates self-editing beyond policy text into something dangerous** β its
|
| 8 |
+
weights, its code, its identity, or credentials.
|
| 9 |
+
|
| 10 |
+
## Defense layers (all enforced in code, not prompt text)
|
| 11 |
+
|
| 12 |
+
1. **Whitelist** β only `constitution`, `tool_rules`, `metacognitive_rules`,
|
| 13 |
+
`refusal_rules`, `playbook` are editable. Anything else is rejected.
|
| 14 |
+
2. **Locked sections** β `security_rules`, `identity`, `weights`, `code`,
|
| 15 |
+
`admin_token`, `system_prompt` can never be edited through the channel.
|
| 16 |
+
Attempts are rejected *and* logged.
|
| 17 |
+
3. **Size caps** β 8,000 chars/section, 8 edits/turn.
|
| 18 |
+
4. **Rate limit** β 40 edits per rolling hour. Violations blocked and logged.
|
| 19 |
+
5. **Hash-chained audit log** β every edit and every rejected attempt is
|
| 20 |
+
appended as `hash = sha256(prev_hash + entry_json)`. Anyone can run
|
| 21 |
+
`audit.verify()` to prove the log is untampered.
|
| 22 |
+
6. **Approval mode** β admin can require human sign-off before edits go live.
|
| 23 |
+
7. **Rollback** β config is version-pinned; admin restores any prior version.
|
| 24 |
+
8. **Isolation** β the edit channel reaches only policy-text files. It has no
|
| 25 |
+
filesystem path capability, no code execution, no network access beyond the
|
| 26 |
+
config repository. Weights, code, and tokens live in a different trust zone
|
| 27 |
+
and are physically unreachable from the edit path.
|
| 28 |
+
|
| 29 |
+
## What the security model does NOT guarantee
|
| 30 |
+
|
| 31 |
+
- **Edit wisdom.** The boundary guarantees edits are *valid and bounded* β not
|
| 32 |
+
that they are *good*. A small model can write worse rules than it started
|
| 33 |
+
with. Review the audit log in production; that is why it exists.
|
| 34 |
+
- **Prompt-injection resistance of the base model.** The boundary is enforced
|
| 35 |
+
in code, so no prompt can cross it β but the model's *content* remains its
|
| 36 |
+
own responsibility.
|
| 37 |
+
|
| 38 |
+
## Verifying the audit log
|
| 39 |
+
|
| 40 |
+
```python
|
| 41 |
+
ok, n = editor.audit.verify()
|
| 42 |
+
assert ok, "audit log tampered at entry %s" % n
|
| 43 |
+
```
|
| 44 |
+
|
| 45 |
+
## Reporting
|
| 46 |
+
|
| 47 |
+
Security issues: open an issue on the repo or contact ChatPBC Labs.
|