Key Rotation: When Agents Outlive Their Credentials
Draft — S7.5 · series: CONTENT-ROADMAP-99 S7 (Security & Sovereignty) · status: DRAFT · grounding: wiki PSAA · OpenFang · ed25519-key-tier · cloudflare/CF zone · wiki_concepts: ed25519-key-tier-architecture, platonic-solid-access-architecture, narrow-gate-principle · wiki_entities: openfang, cloudflare-tunnel · skills: kanban-orchestrator, kanban-worker, lucidhive-wp-publish · tags: security, key-rotation, credential-lifecycle, ed25519, openfang, psaa, cloudflare, sovereign-infrastructure, ai-agents, digital-architecture, autonomous-operations, cryptographic-keys, trust-chain, key-revocation, zero-trust, rotation-cascade, multi-agent-systems, council-system
An agent that signs its first task summary at 9:00 AM and signs its hundredth at 4:00 PM has been running for seven hours. The Ed25519 key pair it used at 9:00 AM is still the same key pair at 4:00 PM. If the key was generated with a 24-hour validity window, it will expire at 9:00 AM tomorrow. If the agent is still running — and in the Kingdom of Truth, agents are designed to keep running — the question is not whether the key will expire, but what happens to the trust chain when it does.
Most security systems treat key rotation as an administrative task. An engineer generates a new key pair, updates the configuration, restarts the service, and hopes nothing broke. In a single-service architecture, this works. In a multi-agent fleet where 42 profiles share trust boundaries, task summaries carry cryptographic signatures, and customer access tiers are encoded in the key hierarchy itself, key rotation is not a maintenance window. It is a security event that must be designed, enforced, and verified.
The static-key failure mode
A static key — one that never rotates — is a liability that grows with every task it signs. The longer a key exists, the more signed artifacts accumulate under its identity. If the key is compromised, every signed artifact becomes suspect. The attacker does not need to forge new signatures; they can retroactively alter unsigned summaries and re-sign them with the stolen key. The trust chain breaks not at the point of compromise, but at every point the compromised key touched.
The three-tier Ed25519 key hierarchy — oracle, council-core, child-agent — compounds this risk. An oracle key that never rotates becomes the single point of failure for the entire verification chain. A council-core key that never rotates means every task summary signed by that council worker carries the same long-lived identity. A child-agent key that never rotates means a spawned subagent’s output is verifiable only as long as the parent’s key is valid. Static keys do not just fail silently — they fail catastrophically, because the trust model assumes keys are fresh.
The rotation cascade
Key rotation in a three-tier hierarchy is not a linear process. It cascades downward. The oracle tier signs the council-core verification key. The council-core tier signs child-agent keys. When the oracle rotates its key, every council-core verification anchor becomes invalid — not because the council-core keys changed, but because the oracle’s signature on them no longer matches. The cascade forces a coordinated update across every tier simultaneously.
The Kingdom of Truth handles this cascade through a protocol called staggered rotation:
-
Oracle generates a new key pair and publishes the new public key to the verification surface (ZenBin, the public audit layer). The old key remains valid for a grace window — typically one hour.
-
Council-core workers detect the oracle’s new key (via the verification surface’s changelog) and generate their own new key pairs. They sign the new council-core public keys with the oracle’s new key, creating fresh verification anchors.
-
Child-agent workers pick up the new council-core verification anchors on their next task. If a child-agent is mid-task when the rotation occurs, it continues signing with its old key until the task completes — then rotates on the next spawn.
-
The oracle’s grace window closes. After the grace period, the old oracle key is revoked. Any signature made with the old key after the grace window is invalid. Any signature made during the grace window is valid but flagged as “pre-rotation” in the audit trail.
The staggered approach means no single tier rotates in isolation. Each tier’s rotation triggers the next tier’s rotation, and the grace window ensures that mid-task agents do not lose their signing capability during the transition.
OpenFang’s role in rotation enforcement
OpenFang — the Security Custodian running on port 7076 — is the enforcement point for key rotation. It does not merely detect expired keys; it blocks operations that rely on them.
When an agent attempts to sign a task summary, OpenFang checks four things before accepting the signature:
- Key registration: Is the signing key registered and not revoked? A revoked key fails immediately — the agent cannot sign, and the task summary is rejected.
- Scope validity: Does the key’s scope cover the claimed operations? A rotated key carries the same scope as its predecessor — the rotation does not change what the agent can do, only which key it uses.
- Time window: Is the signature within acceptable clock-skew tolerance? OpenFang allows a configurable clock-skew window (default: 30 seconds) to account for legitimate time drift between agents.
- Chain of trust: Does the key trace back to the oracle-tier root? After rotation, the chain must trace to the new oracle key. Signatures under the old oracle key are valid only within the grace window.
OpenFang’s env_clear also strips ambient credentials from the rotation process. The agent never sees the raw key material — it receives a signing handle that delegates to OpenFang’s key store. Rotation happens at the key store level, not at the agent level. The agent’s only indication that rotation occurred is that its next signature uses a different key ID.
The temporal overlap vulnerability
The most dangerous moment in key rotation is the overlap window — the period when both old and new keys are valid simultaneously. During this window, an attacker who compromised the old key can still produce valid signatures. The new key does not help, because the old key has not yet been revoked.
The Kingdom of Truth mitigates this through signature provenance tagging. Every signed artifact carries metadata indicating which key version produced it:
{
"key_id": "council-core-kot-builder-1778554942790",
"key_version": 3,
"rotation_epoch": "2026-08-05T14:00:00Z",
"pre_rotation": false
}When an artifact is signed with a key from a previous rotation epoch, the pre_rotation flag is set to true. The consuming agent can then decide: accept the pre-rotation signature (valid but potentially compromised) or reject it and require a re-signing with the current key. The flag does not replace verification — it supplements it, giving consumers an additional signal during the overlap window.
Cloudflare and the DNS perimeter
Key rotation does not exist in isolation. The Kingdom of Truth runs behind Cloudflare’s tunnel infrastructure — the same tunnel audited in the 530 audit referenced in the S7.4 article on Cloudflare as perimeter. When an Ed25519 key rotates, the DNS and certificate layer must stay in sync.
Cloudflare’s role is threefold:
-
Certificate rotation: The TLS certificate that encrypts traffic between Cloudflare’s edge and the origin server has its own lifecycle. If the certificate expires while agent keys are rotating, the trust chain breaks at the network layer — agents cannot reach OpenFang to verify their new keys.
-
Tunnel persistence: The
cloudflaredtunnel maintains a persistent connection between the origin server and Cloudflare’s edge. Tunnel credentials rotate independently of agent keys, but both rotations must be coordinated to avoid a window where the tunnel is down while keys are being updated. -
DNS propagation: When the origin server’s IP changes (common during infrastructure updates), DNS records must propagate before agent keys rotate — otherwise agents may try to verify keys against a stale endpoint.
The Cloudflare integration ensures that the network perimeter and the cryptographic perimeter rotate in concert. A key rotation that succeeds at the agent level but fails at the network level is not a successful rotation — it is a partial failure that leaves the system exposed.
Rotation as a first-class operation
Key rotation is not a bolt-on security feature. It is a first-class operation in the Kingdom of Truth’s architecture — designed, enforced, and audited with the same rigor as task signing and handoff verification. The staggered rotation cascade ensures that no tier rotates in isolation. OpenFang’s enforcement ensures that expired keys cannot produce valid signatures. The temporal overlap mitigation ensures that compromised keys lose their power the moment the grace window closes. And the Cloudflare integration ensures that the network perimeter stays synchronized with the cryptographic perimeter.
The article that follows this one — S7.6 on port maps and service health — covers the observability layer that monitors rotation events in real time. Key rotation is not a fire-and-forget operation. It is a watched, measured, and verified process that leaves a permanent audit trail in the public proof-of-work layer.
Grounded in the wiki concepts ed25519-key-tier-architecture, platonic-solid-access-architecture, and narrow-gate-principle, the openfang entity, the cloudflare-tunnel entity, and the cloudflare-tunnel-audit-20260801 source. Fifth article in the S7 series on Security & Sovereignty. Follows S7.4’s coverage of Cloudflare as perimeter; this one specifies the credential lifecycle that the perimeter enforces.
