When a customer signs up for an AI service, they get a login. When they log in, they get a dashboard. When they use the dashboard, they get… whatever the platform decided they should have. The access model is invisible, arbitrary, and impossible to verify. You trust the vendor’s RBAC implementation because you have no choice — and no way to audit it.
The Kingdom of Truth does not ask you to trust. It shows you the geometry.
From agent keys to customer keys
The internal architecture already solved this problem for agents. Every agent in the Council runs on a solid-key — a cryptographic token encoding shape, tier, scope, and lifetime. The five Platonic solids in three-dimensional Euclidean space map to five access tiers: Tetrahedron (T1, 4 faces), Cube (T2, 6), Octahedron (T3, 8), Dodecahedron (T4, 12), and Icosahedron (T5, 20). The geometry is the policy. A cube-key agent has access to exactly 6 skills, 8 contexts, and 12 peer relationships. The counts are mathematically fixed by the solid’s face, vertex, and edge numbers.
This is not a convention. It is a theorem. There are exactly five Platonic solids — convex polyhedra where every face, edge, and vertex is identical. Euclid proved it two thousand years ago. We did not pick five tiers because pricing said so. We picked five because the mathematics left no other option.
The question this article answers: what happens when the customer gets a solid-key?
The customer-tier architecture
The same PSAA (Platonic Solid Access Architecture) that governs internal agents governs customer access. A customer’s solid-key determines what they can reach, what memory they can query, and what operations they can trigger. The shape of the key is the contract.
Tier 1 — Tetrahedron (Hobbyist)
Four faces. Four vertices. Six edges. The minimal solid — the simplex. A T1 customer gets one agent, a narrow skill surface, and basic memory access. The tetrahedron self-dual property means the key and its dual are identical: there is no hidden complexity. What you see is what you get. The tetrahedron is the root anchor — every agent, human or machine, needs at least this solid to operate.
Tier 2 — Cube (Starter)
Six faces. Eight vertices. Twelve edges. The cube opens up write operations — the customer can create, modify, and persist. Six skills, eight contexts, twelve relationships. The cube-octahedron dual pair means T2 and T3 are operational complements: one writes, the other reads. A starter customer builds. The system monitors.
Tier 3 — Octahedron (Growth)
Eight faces. Six vertices. Twelve edges. The octahedron is the cube’s dual — same edge count, swapped face/vertex counts. A T3 customer reads more than they write: monitoring, analytics, audit. Eight skills for observation, six contexts for precision. The symmetry between T2 and T3 reflects a real operational truth: building and monitoring are two halves of the same access contract.
Tier 4 — Dodecahedron (Enterprise)
Twelve faces. Twenty vertices. Thirty edges. The dodecahedron-icosahedron dual pair is the most complex. A T4 customer operates at the strategic level: twelve skills for planning, twenty contexts for breadth, thirty relationships for cross-team coordination. The dodecahedron is the pentagonal solid — five-fold symmetry that encodes the deepest geometric relationships in three dimensions.
Tier 5 — Icosahedron (Scale)
Twenty faces. Twelve vertices. Thirty edges. The icosahedron inverts the dodecahedron: maximum faces, minimum vertices. A T5 customer runs the full stack — cloud meta-runner, deploys all tiers, executes across every surface. Twenty skills, twelve focused contexts, thirty peer relationships. The icosahedron is the most spherical Platonic solid — it approximates a sphere, the shape of maximum coverage with minimum edge length. That is the operational metaphor: maximum access with minimal overhead.
The dual token pattern: KEY + KILL
Every customer solid-key carries both halves in one cryptographic token. The KEY half grants access. The KILL half defines what revokes it. This is not a separate revocation system bolted onto permissions — it is the same token, the same signature, the same geometry.
A customer’s solid-key encodes:
CUSTOMER_SOLID_KEY = {
shape: <tetrahedron|cube|octahedron|dodecahedron|icosahedron>,
tier: <1-5>,
faces: [<skill_id>], # Length = solid's face count
vertices: [<context_id>], # Length = solid's vertex count
edges: [<relationship_id>], # Length = solid's edge count
lifetime: <iso_timestamp>,
kill_conditions: [<trigger_id>]
}
KILL triggers include: tier_downgrade (budget exceeded → demote to next-lower solid), session_expired (terminate, no persistence), identity_compromise (hard kill + scrub), violation_<rule> (domain-specific failsafe), and manual_revocation (admin killed it). OpenFang, the Security Custodian, enforces both halves centrally. One signature covers both grant and revoke. No ambiguity about what access the customer has (KEY half) and no ambiguity about what can stop it (KILL half).
Ed25519: the cryptographic foundation
Solid-keys are signed with Ed25519 — the elliptic-curve algorithm chosen for speed, small signatures, and resistance to side-channel attacks. The three-tier key hierarchy (oracle, council-core, child-agent) extends to customer-facing operations: the oracle tier verifies, the council-core signs customer keys, and child-agent keys carry the customer’s session scope.
Each key is registered with a unique keyId containing a prefix and timestamp (e.g., customer-1778554942790). The cryptographic foundation ensures that no lower-tier key can impersonate a higher-tier one, and that every customer action is traceable to a specific key pair. This is not optional encryption. It is structural identity.
Cloudflare as the perimeter
The solid-key architecture needs a network perimeter. Cloudflare provides it. The tunnel architecture routes customer requests through Cloudflare’s edge network, where the 530 audit ensures that only authenticated traffic reaches the Council infrastructure. The customer’s solid-key travels through the tunnel, gets validated at the MCP layer, and provisions their scoped access — all before any tool call executes.
The Cloudflare zone configuration hardens the perimeter: DNSSEC for name resolution integrity, SPF/DMARC for email authentication, and tunnel rules that enforce the narrow gate principle at the network level. The customer never connects directly to the infrastructure. They connect to Cloudflare. Cloudflare connects to OpenFang. OpenFang validates the solid-key. The chain is auditable at every link.
Why this matters
Most access systems are administrative — they manage lists of permissions that nobody can verify from outside. PSAA is structural — the permissions are the geometry. A customer can look at their solid-key shape and know exactly what they can do. A cube customer sees 6/8/12 and understands their scope. An icosahedron customer sees 20/12/30 and sees full coverage.
The geometry is self-documenting. The dual token makes revocation explicit. The Ed25519 foundation makes it cryptographic. The Cloudflare perimeter makes it network-enforced. And OpenFang — the gatekeeper — makes it sovereign.
You do not have to trust the vendor. You have to understand the geometry. And the geometry is a theorem.
Grounded in wiki concepts platonic-solid-access-architecture, ed25519-key-tier-architecture, entity openfang, and source cloudflare-tunnel-audit-20260801. Skills: moses-governance, kanban-orchestrator. Second article in the S7 series on Security & Sovereignty. Design notes on a running system, not a sales pitch.
