Why Fleet-Scale Least Privilege Fails on Per-Machine ACLs
Least privilege is the rule that every component gets exactly the access it needs and nothing more. The principle is ancient. The implementation is where fleets break. Per-machine ACLs — file permissions, container grants, role assignments attached to a host — work for a small number of known processes. They fail for a fleet, because a fleet’s access decisions are made at a different granularity: not per machine, but per agent, per task, per moment.
This article explains why solid-keys (S7.2) are the fleet-scale answer to least privilege, what per-machine ACLs get wrong, and how the geometry of the Platonic solids turns an access-control problem into an identity problem.
What per-machine ACLs actually control
A per-machine ACL answers one question: what can a process running on this machine access? The answer is static. The ACL is written when the machine is configured and changes when someone remembers to update it. In a fleet, the question is wrong in four ways:
- Wrong subject. The unit of access is the agent, not the machine. Many agents share a machine. An ACL attached to the machine grants access to every agent on it, which is the opposite of least privilege.
- Wrong granularity. An agent’s needs change per task. A worker that publishes content for one task and reads research for the next needs different scopes at different times. A static ACL cannot express that.
- Wrong lifetime. Ephemeral agents (S8.7 microsharks) exist for minutes. Configuring an ACL for them is overhead that outlives the agent. Least privilege needs access to die with the task, not persist in a config file.
- Wrong enforcement point. An ACL is enforced at the resource. If the agent is on the machine, the ACL is satisfied. It does not ask whether the agent’s identity authorizes the action — only whether the process has the file permission.
The common failure mode is scope creep: because per-machine ACLs are static and coarse, operators grant more than any agent needs, so that future tasks do not require reconfiguration. The result is a system where every agent has the union of all accesses, and least privilege is a slogan.
The solid-key answer: geometry as policy
The Platonic Solid Access Architecture (PSAA) replaces machine-attached ACLs with identity-attached keys. Each agent holds a key whose scope is derived from the geometry of a Platonic solid: a T1 tetrahedron agent has 4 skills, 4 contexts, and 6 relationships; a T5 icosahedron agent has 20, 12, and 30. The shape is not a metaphor — it is the policy. The key encodes exactly what the agent can touch, and the gate (S7.1) enforces the key, not the machine.
This shifts least privilege from configuration to identity. Access is a property of who the agent is, not where it runs. Move the agent to another machine and the key still says what it can do. Spawn a child and the child’s scope is derived from the parent’s geometry — the delegation is bounded by construction, not by a hand-edited ACL.
Task-scoped access beats static grants
The fleet needs access decisions that change with work, and solid-keys make that possible because the gate issues scoped tokens per task. A worker that needs to publish one article does not hold a permanent “publish” grant; it holds a token valid for that task, with that post’s ID in its scope, expiring when the task completes. The token is checked by the gate on every tool call, and the taint-tracking layer (S7.1) watches what the token’s data flows into.
Compare this to the per-machine model: the machine has “publish” access permanently, for every process on it, forever. The task-scoped token has publish access for one agent, one post, one window. The difference is the difference between a key to the building and a key to one room, for one afternoon, that self-destructs.
Why this is the honest version of least privilege
Least privilege is usually implemented as a best-effort approximation because the alternative — precisely scoping every access — is too expensive to administer manually. The solid-key model makes precision the default because the scope is derived, not administered. The geometry produces the scope; the scope produces the token; the token is enforced by the gate; the gate’s decisions are recorded in the audit layer (S7.7). There is no step where a human has to remember to restrict an agent, because the restriction is structural.
The audit trail is the proof that least privilege is actually being enforced. The ledger shows every tool call, its scope check, and its outcome. When a customer or an auditor asks “does the fleet actually enforce least privilege?” the answer is not a policy document — it is a query against the ledger.
The cost is real, and it is worth it
Nothing in security is free. The solid-key model costs per-call verification: every tool call is checked against the key’s scope before it executes, and that check adds latency. The fleet pays this tax on every action. The alternative — static ACLs with no per-call check — is faster and leakier. The Council chose the tax, because the threat model (S7.4) priced lateral movement as the dominant risk, and per-machine ACLs are precisely what lateral movement walks through.
From access control to access architecture
The upgrade from per-machine ACLs to solid-keys is not a tooling swap. It is a change in what access means. In the old model, access is a property of infrastructure — what the machine is configured to allow. In the new model, access is a property of identity — what the agent’s key authorizes, regardless of machine, enforced at every call, recorded in every ledger entry. For a sovereign-infrastructure business (S6 series), this is also the product story: customers do not buy “a server with permissions”; they buy an access architecture where every identity’s reach is geometric, bounded, and auditable. That is least privilege with receipts.
Grounded in wiki concepts platonic-solid-access-architecture, narrow-gate-principle, ed25519-key-tier-architecture, zero-trust, entity openfang, and the S7 security series. Design notes on a running system.
