# Access Control — Red Tape, Green Tape, and Work Mode

**The feature that makes LatticeSearch safe to run on a work machine.** You decide exactly what the
lattice is allowed to see. Nothing is scanned, indexed, served, or shown to an AI agent unless you
permit it — so confidential company data stays invisible to the engine.

This is a headline USP: most desktop search tools index *everything* by default. LatticeSearch can
be told, precisely, where it may and may not look — and it enforces that at every layer.

## The two modes

### Personal mode (default)
Full access to everything on the machine — **except** any folder you've **red-taped**. This is the
normal single-user experience: instant search over your whole drive, with the option to carve out a
few private folders.

### Work mode
**Deny by default.** The lattice scans **only** the folders you've **green-taped** (explicitly
allowed). Everything else on the machine is off-limits — never scanned, never indexed, never served.
The index grows *only* where you grant access. Perfect for a work laptop that also holds client
data, HR files, or anything under confidentiality: the lattice indexes your design folder and
nothing else.

## Red tape vs green tape

| | What it does | Applies in |
|---|---|---|
| **🟥 Red tape** (deny) | This folder is **never** scanned, in any mode. | Personal **and** Work |
| **🟩 Green tape** (allow) | This folder **may** be scanned. | Work mode (the allowlist) |

Red tape always wins. Even in personal mode, a red-taped folder is invisible to the engine. And in
work mode, a red-taped subfolder *inside* a green-taped area is still excluded — so you can allow
`Projects\` but block `Projects\ClientConfidential\` within it.

## How the gate works (and why it can't be bypassed)

Every path the engine might touch — a scan root, a live-watch event, a file it's about to serve, a
search result, a CLI read/write — passes through one function, `is_scannable(path)`:

1. The path is resolved to its **real** location first (`realpath`), so `..\..\` traversal tricks
   can't sneak outside an allowed area.
2. If it's under any **red-tape** root → **denied** (both modes).
3. Personal mode → allowed (unless red-taped).
4. Work mode → allowed **only** if under a **green-tape** root.

Because *every* layer funnels through this one gate, there's no side door: the scanner won't walk
it, the watcher won't index it, the file server won't stream it, search won't return it, and the AI
agent's `lattice read` can't open it. Comparison is case-insensitive on Windows and boundary-safe
(so allowing `C:\Work` does not accidentally allow `C:\WorkOther`).

## Agent-safe by design

When you point Claude or Codex at the lattice in **work mode**, the agent physically cannot see or
read anything outside your allowed folders — the engine returns nothing for off-limits paths. You
get all the speed of the lattice for your actual work, with a hard wall around everything else. That
is the B2B story: **an AI file-brain your compliance team can approve**, because the data boundary
is enforced by the tool, not by trusting the agent to behave.

## Configuration

Stored in `lattice_access.json` in the engine's data directory:

```json
{
  "mode": "work",
  "allow": ["C:\\Users\\me\\Design", "C:\\Users\\me\\Projects"],
  "deny":  ["C:\\Users\\me\\Design\\ClientConfidential"]
}
```

Managed from the GUI (Settings → Access): a Personal/Work toggle, a green-tape folder picker for the
allowlist, and a red-tape picker for always-off-limits folders. Changing it takes effect
immediately — the gate re-reads the config on the next operation, and the next scan reshapes the
index to match.

## How this fits the engine

The lattice engine builds tiers of understanding over your files — a name index (instant
filename/path search from RAM), and optional semantic tiers (meaning search over images, documents,
audio, captions). Access control sits **in front of all of it**: `roots_to_scan()` narrows what the
indexers ever walk, and `is_scannable()` guards every read after that. So work mode doesn't just
hide results — it means the confidential bytes are **never loaded into the index in the first
place**. Turn work mode on before the first scan and the engine simply never learns those folders
exist.
