epic-12: after epic audit and init commit
This commit is contained in:
@@ -0,0 +1,110 @@
|
||||
---
|
||||
name: "Security Boundaries"
|
||||
description: "Trust boundaries and component isolation rules"
|
||||
depth: 2
|
||||
links:
|
||||
- "../index.md"
|
||||
- "./overview.md"
|
||||
---
|
||||
|
||||
# security boundaries
|
||||
|
||||
**version:** 0.1-draft
|
||||
**status:** architectural reference
|
||||
|
||||
---
|
||||
|
||||
## 1. trust model
|
||||
|
||||
Correx operates under the assumption that **models are untrusted**, **tools are dangerous**, and **plugins may be malicious**. The system enforces explicit security boundaries between components to contain risk.
|
||||
|
||||
---
|
||||
|
||||
## 2. principal boundaries
|
||||
|
||||
```
|
||||
┌───────────────┐
|
||||
│ user │ human, interactive steering, ultimate authority
|
||||
└───────┬───────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────┐
|
||||
│ router │ facial facade; can only summarise, interpret, forward
|
||||
└───────┬───────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ harness (core) │
|
||||
│ orchestrator, validation, approvals, │
|
||||
│ transitions, policies, event store │
|
||||
│ │
|
||||
│ all sensitive decisions happen here │
|
||||
└───┬───────┬───────┬──────────┬──────┬───────┘
|
||||
│ │ │ │ │
|
||||
▼ ▼ ▼ ▼ ▼
|
||||
┌─────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
|
||||
│model│ │tool │ │prov- │ │plugin│ │pers- │
|
||||
│ │ │ │ │ider │ │ │ │ist │
|
||||
└─────┘ └──────┘ └──────┘ └──────┘ └──────┘
|
||||
|
||||
Boundaries are strictly enforced:
|
||||
- Model ⇄ Harness: only text in, artifact out
|
||||
- Tool ⇄ Harness: only receipts, no direct state mutation
|
||||
- Provider ⇄ Harness: only inference interface
|
||||
- Plugin ⇄ Harness: only via published contracts
|
||||
- Persistence ⇄ Harness: only through storage interfaces
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. specific boundary rules
|
||||
|
||||
### 3.1 model boundary
|
||||
|
||||
* Models receive only ContextPacks; they never access raw events, files, or network.
|
||||
* Output is untrusted; validation pipeline scrutinises every artifact.
|
||||
* No state carried between model calls.
|
||||
|
||||
### 3.2 tool boundary
|
||||
|
||||
* All tools are assigned an approval tier (T0–T4).
|
||||
* Execution requires explicit approval matching the tier and session mode.
|
||||
* Tools run sandboxed (containerised or restricted shell).
|
||||
* Tools may only affect the filesystem paths allowed by policies.
|
||||
* Network access is blocked by default; curl, etc., require tier T3 and explicit approval.
|
||||
|
||||
### 3.3 provider boundary
|
||||
|
||||
* Local and remote providers are abstracted behind the same `InferenceProvider` interface.
|
||||
* Credentials are never exposed to core logic; they reside in environment variables or secret vaults.
|
||||
* Provider health failures trigger orchestration fallback, not panic.
|
||||
|
||||
### 3.4 plugin boundary
|
||||
|
||||
* Plugins (custom validators, compressors, tools) interact via stable DTOs.
|
||||
* They cannot mutate core projections or approval decisions.
|
||||
* Plugin code is loaded into an isolated classloader/process in later versions.
|
||||
|
||||
### 3.5 user boundary
|
||||
|
||||
* User interaction happens only through the Router and approval prompts.
|
||||
* Steering input is recorded verbatim and later injected as guidance into context packs.
|
||||
* Session cancellation is immediate and enforced by the orchestrator.
|
||||
|
||||
---
|
||||
|
||||
## 4. extra safeguards
|
||||
|
||||
* **Audit trail:** every approval, validation rejection, and tool execution is permanently recorded.
|
||||
* **Least privilege:** each component starts with zero access and gains only what is explicitly granted.
|
||||
* **Execution timeouts:** all inference and tool calls have strict durations; watchdog kills overruns.
|
||||
* **Secrets isolation:** no secret appears in logs, events, or context unless explicitly allowed.
|
||||
* **Replay safety:** replay does not re‑execute risky side effects; it only reconstructs state.
|
||||
|
||||
---
|
||||
|
||||
## 5. what we do not protect against (by design)
|
||||
|
||||
* Deliberate user bypasses (e.g., yolo mode) – they are logged but allowed.
|
||||
* Model‑generated harmful content – semantic validation can flag it, but ultimate responsibility lies with the user’s policies.
|
||||
* Physical machine compromise – we assume the OS and sandbox provide the last line of defence.
|
||||
Reference in New Issue
Block a user