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.

4.4 KiB Raw Permalink Blame History Unescape Escape