Credentials Are a Fleet’s Most Expensive Inventory
Every agent in a fleet holds keys: API tokens, database passwords, signing keys, service credentials. A single agent might hold a dozen. A fleet of dozens of agents holds hundreds, and the moment a credential is written to a file that survives, it becomes inventory that must be tracked, rotated, and eventually destroyed. Most systems treat credentials as a convenience — a string to fetch at startup. The Council treats them as inventory with a lifecycle, because the security series documented in S7.1 through S7.9 only works if the keys those layers rely on are handled as carefully as the layers themselves.
This article is about where credentials live at rest, how they move in transit, and why the distinction between the two determines whether a fleet is secure or merely configured.
Secrets at rest: the failure of the plain file
The default pattern is a .env file or a config directory with tokens in plaintext. It works until it does not. The problems are structural:
- Ambient exposure. Any process that can read the directory can read the secrets. In a container, that is every process in the container. The
env_clearlayer in the narrow gate exists precisely because ambient credentials are the most common exfiltration path. - No provenance. A plaintext file does not record who created the credential, who used it, or when it should expire. The audit layer in S7.7 needs that provenance to verify agent actions, and a plaintext file supplies none of it.
- Rotation is manual. When a credential lives in a config file, rotating it means editing the file, redeploying, and hoping nothing cached the old value. The key-rotation discipline in S7.5 requires rotation to be a routine, automated event — not an emergency procedure.
The fix is not a better file format. It is a different storage model: credentials as signed, scoped, expiring artifacts managed by a secrets system, mounted into containers only as needed, and stripped from the environment before any tool call executes.
Secrets in motion: the handoff problem
Credentials at rest are only half the inventory. Credentials in motion — passed between agents, injected into tool calls, embedded in task summaries — are the harder half, because motion creates copies.
Every time Agent A passes a credential to Agent B, there are now two copies. Every time a credential appears in a task summary, there is a copy in the kanban board’s history. Every time a tool call carries a token, there is a copy in the gate’s inspection pipeline. Copies are the enemy: each one is a place where the credential can leak, and each one must be accounted for.
The Council’s rule is brutal and simple: credentials never appear in handoffs. Task summaries carry references to artifacts, not the artifacts themselves. A child agent that needs a service token requests it through the gate, scoped to the task, with an expiry tied to the task’s lifetime. The summary says “used the database write path for table X” — not the connection string. This keeps the shared-state surface (the kanban board) free of secrets, which means a board leak is a data leak but not a credential leak.
The ed25519 key tiers
The most important credentials in the fleet are the signing keys, and they follow a stricter lifecycle than service tokens. The architecture uses ed25519 key tiers:
- Root tier. The smallest set of keys, held offline where possible. Used to sign top-level trust anchors: profile registry entries, the doctrine, the initial keys of the first agents. Compromise of a root key is the catastrophic residual risk named in the threat model (S7.4) — bounded by rotation and by the fact that a root key alone cannot act; it can only re-sign.
- Agent tier. One key pair per agent, derived from and endorsed by a parent tier. This is the identity that signs task summaries and tool-call requests. When an agent is rotated, its key is revoked and a fresh one issued under the same parent.
- Ephemeral tier. Task-scoped keys for microsharks and short-lived workers. They exist for the duration of the task and are destroyed with it. Ephemeral keys make the rotation problem tractable: instead of rotating long-lived keys on a schedule, the fleet simply uses keys that were never meant to outlive the work.
The key tiers are the mechanism behind the child-agent key architecture documented in the council series. The important property is derivation: a child key is only as powerful as the parent’s solid-key geometry permits (S7.2), and a revoked child key does not require re-issuing the parent.
Storage backends: what actually holds the secrets
For a sovereign, local-first stack, the secrets backend must itself be local-first. The Docker Swarm stack (S7.9) provides swarm secrets: files mounted into containers at deploy time, never written into images, never stored in the overlay network’s shared state beyond what the scheduler needs. The persistence layer (volumes) holds data, not secrets — a distinction the architecture enforces at the storage level, not just in documentation.
Long-lived signing keys live in the profile registry’s secure store, mounted only to the agents that own them. Service tokens are issued by the gate’s token service with per-task scope and expiry, so even a leaked token decays. Nothing in the fleet holds a permanent, unscoped, ambient credential — because the threat model (S7.4) priced that configuration as a single-point failure.
Operational rules that make it hold
Storage architecture fails without operational discipline. The Council runs on four rules:
- No secrets in code, images, or boards. Every secret-bearing artifact goes through the gate’s secret service or swarm secrets. Enforcement is mechanical, not aspirational.
- Rotation is scheduled, not reactive. Agent-tier keys rotate on a calendar, not after an incident. S7.5 documents the rotation cascade — how a rotation propagates through the trust graph without breaking running work.
- Ephemeral by default. If a credential can be task-scoped and expiring, it is. Long-lived credentials are the exception that must be justified.
- The audit layer watches the inventory. Key issuance, usage, and revocation are logged. An anomalous pattern — a key that was issued but never used, a token that outlived its task — shows up in the ledger that S7.7 describes.
Why this matters for customers
Credential hygiene is invisible when it works and catastrophic when it fails. For a business selling sovereign infrastructure (the S6 series), it is also a product feature: the ability to say “customer credentials are task-scoped, expiring, and never stored in shared state” is not a marketing line, it is a verifiable property of the architecture — the same property the customer dashboard (S6.7) can expose as a trust signal. The audit layer turns credential discipline into evidence, and evidence is what turns security into trust.
Grounded in wiki concepts ed25519-key-tier-architecture, narrow-gate-principle, credit-safe-architecture, secrets-management, entity openfang, and the S7 security series. Design notes on a running system.
