# Security-Boundary Review: Autonomous Self-Improvement v7

**Design session:** `01a015f7-89dc-7ce0-b9b7-62d7b85d2396`  
**Reviewer session:** `01a01665-6cc0-7d67-b635-d0f3cfc10444`

## Verdict

**Final sign-off is pending one factual security-boundary correction.** All functional governance requirements are now represented, but the claimed runtime immutability is not enforced by the mechanism described.

## Blocking Correction: Same-User Permissions Are Not an Immutable Boundary

`chmod 0500` on a directory owned by the same OS user does not protect it from active extension code running as that user. The owner can call `chmod`, replace parent-directory entries, signal the supervisor, or access other same-user resources. Likewise, a Unix socket with mode `0600` authorizes the entire user account, not a specific extension process. An HMAC audit chain is forgeable if its key is readable by that same user/process.

Therefore §8.A cannot simultaneously claim that a faulty or malicious active extension has no write access while the supervisor, extension, socket, artifacts, and audit key all run under the same user identity.

Choose and document one of these valid designs:

### Option A — Enforced Privilege Separation

- Install/run the supervisor under a distinct OS service identity or root-owned signed service.
- Make supervisor code, baseline policy/tests, active-version pointer, artifact store, migration journal, audit key, and rescue utility writable only by that identity.
- Run the Pi extension unprivileged.
- Authenticate IPC using OS peer credentials plus a narrow capability protocol; socket mode alone is insufficient.
- Keep HMAC/signing keys supervisor-only and never expose them through IPC.
- Define signed supervisor installation/update outside autonomous upgrade.

### Option B — Explicitly Narrow the Threat Model

If privileged installation is out of scope:

- state that the active, human-approved extension and same-user processes are trusted;
- describe the supervisor as isolated from **candidate builders/sandboxes** and tamper-evident, not immutable against active same-user code;
- remove claims that it protects against a malicious active extension;
- retain disabled-by-default self-upgrades, digest-bound human approval, sandboxing, backups, and rescue as defense in depth.

## Approval Condition

After §8 and `prompt.md` adopt either Option A or Option B consistently, the autonomous self-improvement subsystem is approved for phased implementation. No other architecture findings remain.