110 lines
2.6 KiB
Markdown
110 lines
2.6 KiB
Markdown
# ThreeGate
|
|
|
|
**ThreeGate** is a compartmentalized architecture for building **secure, local AI assistants** that perform goal-directed tasks *without* relying on autonomous agents or trusting large language models to behave safely.
|
|
|
|
ThreeGate separates **thinking**, **retrieval**, and **execution** into distinct, least-privileged components with enforced trust boundaries.
|
|
|
|
> If prompt injection is inevitable, safety must come from structure.
|
|
|
|
---
|
|
|
|
## What ThreeGate Is
|
|
|
|
ThreeGate is:
|
|
|
|
- A **reference architecture** for secure local assistants
|
|
- A **defense-in-depth design** against prompt injection, tool abuse, and data exfiltration
|
|
- A **human-governed system**, not an autonomous agent
|
|
- Designed for **single-user, local operation**
|
|
- Explicitly extensible to multiple roles (research, policy analysis, data science, auditing)
|
|
|
|
---
|
|
|
|
## What ThreeGate Is Not
|
|
|
|
ThreeGate is **not**:
|
|
|
|
- An autonomous agent framework
|
|
- A self-modifying system
|
|
- A browsing-and-executing AI loop
|
|
- A cloud-first or multi-tenant platform
|
|
- A system that trusts LLM outputs without validation
|
|
|
|
---
|
|
|
|
## Core Insight
|
|
|
|
Most unsafe AI systems fail because they allow a single component to:
|
|
|
|
> **Read untrusted input, reason about it, and immediately act on the world.**
|
|
|
|
ThreeGate prevents this by enforcing **three independent gates**:
|
|
|
|
1. **FETCH** — retrieves untrusted external content
|
|
2. **CORE** — performs reasoning and synthesis
|
|
3. **TOOL-EXEC** — executes code, only when explicitly approved
|
|
|
|
No component crosses more than one gate.
|
|
|
|
---
|
|
|
|
## High-Level Architecture
|
|
|
|
Internet
|
|
↑
|
|
[ Managed Proxy ]
|
|
↑
|
|
FETCH (retrieval)
|
|
↓
|
|
Research Packets
|
|
↓
|
|
CORE (analysis)
|
|
↓
|
|
(optional, human-approved)
|
|
↓
|
|
TOOL-EXEC (sandboxed execution)
|
|
|
|
---
|
|
|
|
## Initial Target Role
|
|
|
|
The first concrete role implemented using ThreeGate is a:
|
|
|
|
**Secure Local Research Assistant**
|
|
|
|
Capabilities:
|
|
- Scholarly retrieval (controlled, allowlisted)
|
|
- Analysis and writing
|
|
- Optional sandboxed computation
|
|
- No autonomous browsing or execution
|
|
|
|
---
|
|
|
|
## Repository Structure (Initial)
|
|
|
|
ThreeGate/
|
|
├── README.md
|
|
├── docs/
|
|
│ ├── architecture.md
|
|
│ ├── threat-model.md
|
|
│ └── why-this-is-safer.md
|
|
|
|
---
|
|
|
|
## Status
|
|
|
|
This repository is in **early specification and reference implementation phase**.
|
|
|
|
The design is intentionally conservative. Convenience features are added *only* when they preserve trust boundaries.
|
|
|
|
---
|
|
|
|
## License & Philosophy
|
|
|
|
ThreeGate favors:
|
|
- Explicit over implicit authority
|
|
- Structural safety over behavioral promises
|
|
- Human-in-the-loop over automation
|
|
|
|
If a feature weakens a trust boundary, it does not belong here.
|