110 lines
4.4 KiB
Markdown
110 lines
4.4 KiB
Markdown
---
|
||
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. |