ThreeGate/docs/architecture.md

151 lines
3.4 KiB
Markdown

# ThreeGate Architecture
This document specifies the **ThreeGate architecture**, including components, trust boundaries, data flow, and enforcement mechanisms.
---
## Design Objective
Enable powerful, local, goal-directed AI assistance while preventing:
- Prompt injection (direct and indirect)
- Tool abuse
- Data exfiltration
- Accidental or malicious system modification
This is achieved by **compartmentalization**, not by trusting model behavior.
---
## Core Components
ThreeGate consists of **three isolated components**, each with a distinct role and privilege level.
### 1. CORE — Analysis & Synthesis
**Responsibilities**
- Reasoning
- Synthesis
- Writing
- Policy interpretation
- Drafting requests for retrieval or execution
**Explicit Restrictions**
- No internet access
- No shell
- No execution
- No package installation
- No modification of policy files
CORE is the **most prompt-exposed component** and therefore the **least powerful**.
---
### 2. FETCH — Controlled Retrieval
**Responsibilities**
- Retrieve external information
- Normalize content into *Research Packets*
**Capabilities**
- HTTPS access only
- Internet access only via managed proxy
- Domain allowlists (e.g., academic sources)
**Explicit Restrictions**
- No execution
- No shell
- No persistence beyond packet output
- No access to CORE state
FETCH treats all retrieved content as hostile by default.
---
### 3. TOOL-EXEC — Optional Execution Sandbox
**Responsibilities**
- Execute explicitly approved code or commands
- Perform computations that cannot be done textually
**Implementation**
- Backed by sandboxed execution (e.g., microVMs such as ERA)
- Ephemeral by default
- No network unless explicitly approved
**Explicit Restrictions**
- No direct access to CORE or FETCH
- No ambient credentials
- No persistent state by default
Execution is the **highest-risk capability** and is therefore isolated and human-gated.
---
## Data Flow & Trust Boundaries
All data movement is **one-way** and **validated**.
| From | To | Direction | Validation |
|----|----|-----------|------------|
| FETCH | CORE | One-way | Required |
| CORE | TOOL-EXEC | Draft only | Human approval |
| TOOL-EXEC | CORE | One-way | Required |
There is **no shared mutable state** between components.
---
## Network Topology
- CORE: no internet route
- FETCH: internet access only via managed proxy
- TOOL-EXEC: no network by default
Network restrictions are enforced at:
- Container network level
- Host firewall level
- Explicit proxy allowlists
---
## Policy Enforcement
- Policies are mounted read-only
- Instruction hierarchy is explicit
- Tool usage requires justification and approval
- Outputs are validated before reuse
---
## Failure Containment
If any component is compromised:
- FETCH cannot execute or persist
- CORE cannot browse or execute
- TOOL-EXEC cannot exfiltrate or persist by default
Failures are **observable, contained, and reversible**.
---
## Architectural Invariants
The following must never be violated:
1. No component both reasons and acts
2. No component both browses and executes
3. External content is hostile by default
4. Execution is optional and sandboxed
5. Network access is a scarce privilege
Any extension must preserve these invariants.
---
## Summary
ThreeGate enforces safety by **structure**, not by instruction.
It assumes model fallibility and limits consequences accordingly.