The Customer Boundary Is the Hardest One
Multi-tenancy is the art of running many customers on one infrastructure without letting them see, touch, or slow each other down. For a single server, it is a solved problem with well-known tools: virtual machines, containers, network isolation. For a fleet of agents that share a kanban board, a vault, a gate, and a publishing pipeline, multi-tenancy stops being a virtualization question and becomes a governance question: how do you prove that customer A’s agent cannot reach customer B’s data, even though both run on the same stack, through the same gate, under the same doctrine?
Why fleet multi-tenancy is not container multi-tenancy
Containers isolate processes. They do not isolate agents. An agent is not a process — it is an identity with a key, a scope, and a history of actions. Two agents from different customers can run in the same container, on the same host, while their isolation lives entirely in the identity layer. Conversely, two agents from the same customer can run on different hosts and still share state through the board.
The architecture therefore treats tenancy as an attribute of identity, not of infrastructure. The solid-key geometry (S7.2, S7.12) defines what each agent can reach; the tenant is encoded in the key’s scope. Customer A’s agent holds a key whose geometry includes customer A’s data plane and nothing else. The gate (S7.1) enforces the key at every tool call, and the taint layer watches whether data from customer A’s context ever flows into a tool call bound for customer B’s plane. Isolation is a property of the verification pipeline, not of the process table.
The shared-state problem
The board is the fleet’s memory, and it is shared by construction. Customer A’s task and customer B’s task sit on the same board, are consumed by the same dispatcher, and produce entries in the same history. The isolation requirement is therefore not “separate the boards” (that would be a single-tenant architecture wearing a costume) but “make every board entry’s tenant visible and verifiable.”
The mechanisms:
- Tenant-tagged tasks. Every task carries a tenant field. The dispatcher routes work only to agents whose scope includes that tenant.
- Scoped consumption. A worker consuming a task can see the task’s payload only if its key grants access to that tenant’s plane. The gate checks the grant before the payload is exposed.
- Tenant-separated artifacts. Published content, generated media, and research outputs are written to tenant-scoped paths, with the write authorized by the same key check as every other tool call.
- Audited cross-tenant events. The audit layer (S7.7) records every access to a tenant plane. A cross-tenant access attempt that fails is logged as a security event; one that succeeds is logged as a violation, because by design there is no legitimate cross-tenant access.
The design goal is that tenant isolation is not enforced by a “trust the code not to cross the boundary” assumption, but by a per-call, key-derived, audited check — the same enforcement machinery that powers least privilege, now pointed at the customer boundary.
What the customer actually experiences
Tenant isolation has a user-visible shape. The customer dashboard (S6.7) shows each customer only their own agents, tasks, budgets, and artifacts. The self-service portal (S6.7) lets a customer act on their own plane — pause an agent, spend budget, request a service — without any pathway to another customer’s plane. The dashboard is not a separate app bolted onto the stack; it is the same stack, filtered through the customer’s key. What the customer sees is exactly what their key can reach. There is no “admin view” that shows everything, because no single key in the system holds the geometry of all tenants — including the operator’s.
The operator’s dilemma: power without a master key
A classic multi-tenant system has a superuser who can see and do everything. The Council’s architecture deliberately has none. The operator holds keys at the top tier, but even those keys are scoped: they can administer the fleet — rotate keys, restart services, update doctrine — without holding the data-plane keys of every customer. This is the honest version of sovereign infrastructure: the operator runs the machine but cannot read the tenants’ mail.
This design choice has real costs. Debugging a customer issue is harder when the operator cannot impersonate the customer’s view. The compensation is the audit layer: the operator can see what the customer’s agents did, through the ledger, without needing the data itself. The ledger is the operator’s window into every tenant plane — not by privilege, but by evidence.
Why this is the product
Multi-tenancy is a business feature in the S6 series, not just a security property. A customer evaluating sovereign infrastructure is asking: “if my data sits on your stack alongside other customers’ data, what stops your other customers — or your own fleet — from touching it?” The answer is the key architecture: tenant scope is geometric, enforced per call, and recorded in an immutable ledger. That is not a promise; it is a mechanism the customer can inspect. The audit layer turns the multi-tenancy claim into a demonstration, and the customer dashboard turns the demonstration into a daily experience.
Grounded in wiki concepts platonic-solid-access-architecture, narrow-gate-principle, zero-trust, immutable-logging, tenant-scope, entity openfang, and the S6 + S7 series. Design notes on a running system.
