I wanted a local AI desktop that could do useful things with selected text, notes, logs, and scripts without treating a model’s suggestion as permission to act on my machine. The first architecture documents felt broad, so I kept pulling the design toward boundaries Linux could actually enforce: separate worker identities, limited groups, restricted paths, a broker, and staging for generated files.
The security reviews made the smallest proposed milestone especially important. The secure-v0.1 package allowed only a ping_broker operation. Even there, one review found that the response and audit schemas could accept a story that the policy forbade—such as a successful result for an unknown tool or file access the manifest did not allow. That was an evidence-integrity problem and a needs-rework verdict, followed by revisions. The point of this stretch is how an ambitious desktop concept narrowed to a tiny boundary whose behavior and records could be checked honestly.
A request is not permission
The proposed flow put a policy and permission layer between the model and tools. The model could request an operation; the surrounding software would decide whether to deny it, stage an artifact, allow a narrow tool, or require human review.
That distinction affected simple features. A script drafter should produce a file for inspection rather than execute it automatically. A knowledge indexer should receive selected documents rather than inherit access to an entire home directory. A diagnostic tool should be able to explain staged logs without gaining the authority to alter the services those logs describe.
I specifically asked whether agents could run as their own Linux users and use groups as capability boundaries. The proposed roles included a model service, an indexer, a log reader, a script drafter, and voice handling. The point was to avoid every feature inheriting the full permissions of the desktop account.
The architecture revision
The resulting architecture-and-build-plan revision tightened several early assumptions. Its update summary promoted the Trusted Broker / Policy Engine into the trusted computing base and added an explicit IPC/API section. It moved away from assuming that a localhost endpoint was automatically an adequate boundary and toward restricted Unix-socket access.
The same revision separated audit logs from diagnostic bundles, replaced a shared staging-write group with per-worker write groups, added canonical-path rules, and treated clipboard and voice as sensitive desktop-session capabilities. It also demoted the command classifier from a central safety mechanism to an advisory role.
That gave the design more concrete responsibilities:
| Part | Responsibility in the proposed model |
|---|---|
| Model | Produce a request or draft |
| Broker | Enforce the approved operation and caller contract |
| Worker identity | Limit reachable files and services |
| Staging area | Hold generated artifacts before use |
| Audit record | Describe what was requested and what actually happened |
These were design and review decisions. They should not be read as a claim that every boundary had already been implemented successfully.
Why begin with a ping?
The later secure-v0.1 review package deliberately limited the permitted tool to ping_broker. Its policy and manifest were supposed to allow a harmless broker response, with empty read and write roots and no model, shell, network, or general file-access capability.
This small scope made contradictions easier to see. If the only approved tool was a ping, a successful event claiming external network access or a created file should not pass as valid evidence of that system.
One review found exactly that mismatch. The policy and manifest had been tightened, but the response and audit schemas still accepted impossible success records: an unknown tool, external-network risk, destructive behavior, or nonempty file-access lists. A failed response could also carry an ok-looking tool payload.
The important distinction in the review was that this was an evidence-integrity defect, not by itself a demonstrated authorization bypass. The proposed repairs constrained successful records to the actual ping capability and required denied or failed responses to avoid a success-looking payload.
What the reviews established
The package went through revisions and received a needs-rework verdict at that point. The source material explicitly separated schema validation from runtime proof. A working broker, policy loader, socket permissions, audit permissions, denial paths, and actual runtime records were still needed to establish implementation behavior.
The needs-rework review gave me a concrete first gate: a broker allowed to answer a ping should not accept records claiming a different tool or file operation succeeded. That was still a narrow slice of the larger desktop, but one whose implementation and audit trail could actually be checked.