---
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.