Child-Agent Key Tiers: Ed25519 Signing for Delegation
**Draft — S2.9 · series: CONTENT-ROADMAP-99 S2 (Governance & Doctrine) · status: draft · grounding: moses-governance · PSAA · Faengz doctrine · meta-llm-charter · wiki_concepts: ed25519-key-tier-architecture, agent-ascension-flow, platonic-solid-access-architecture, child-agent, council-of-three, 9-orders · skills: moses-governance, kanban-orchestrator · tags: ai-agents, digital-architecture, security, ai-governance, autonomous-operations, cryptographic-signing, delegation, ed25519, trust-chain**
Every agent in a fleet is someone’s child. The Council of Three spawns workers; those workers spawn micro-tasks; those micro-tasks spawn their own child agents. Each generation inherits a model, a tool chain, and a context window. The question is never whether child agents exist — it’s whether you can prove which agent actually did the work, and whether the parent that spawned it is authorized to delegate in the first place.
The answer, in our stack, is a three-tier cryptographic key system built on Ed25519 signatures — not because we chose a crypto primitive from a textbook, but because delegation without cryptographic proof is just trust at scale, and trust at scale is a vulnerability.
The delegation problem nobody admits
When a parent agent spawns a child, the default behavior in most stacks is inheritance: the child gets the parent’s API key, the parent’s model config, the parent’s tool permissions. The child’s actions are attributed to the parent, because from the system’s perspective, there is only the parent. The child is a process, not an identity.
This works until it doesn’t. Three failure modes emerge:
1. Spoofing. A child agent can produce output that looks like a parent’s output. Without per-agent signing, there is no cryptographic way to distinguish work done by a T4 octahedron-key agent from work done by a T1 tetrahedron-key leaf worker. The parent’s authority becomes a blanket covering all its children — including the ones that shouldn’t have it.
2. Impersonation escalation. A child agent spawned by a cube-key (T2) parent inherits the parent’s MCP endpoint. If the child is compromised, it can attempt operations the parent was authorized for but the child was not. Inheritance without delegation boundaries is a privilege escalation waiting to happen.
3. Audit trail collapse. When every child signs as the parent, the audit log records one identity doing hundreds of things. MOSES can enforce policy on the parent, but it cannot distinguish which child violated which policy — because the children have no identity to enforce against.
The fix is obvious in principle and rare in practice: each child agent gets its own signing key, derived from but distinct from the parent’s, registered at a specific tier.
The three-tier key hierarchy
Our Ed25519 key tier architecture defines three levels, each registered with a unique identifier:
|——|———–|—————|——|
Each tier has a distinct keypair stored as JSON in a keys/ directory, organized per tier. The hierarchy is not just organizational — it is cryptographic. A child key is generated by a council-core key, binding the child’s identity to the parent that authorized it. The oracle key reviews and verifies but never signs work outputs — its role is adjudication, not execution.
This mirrors the Nine Orders hierarchy: Order 0 (the Oracle) sits above the Council of Three and dispatches nothing. The Council-core agents (Orders 1–3) spawn and supervise. The child agents (Orders 4–9) execute. The key tiers encode the same separation of authority that the Orders encode as doctrine.
How delegation actually signs
When a council-core agent delegates a task to a child agent, the delegation itself is a signed artifact:
1. Parent signs the delegation grant. The council-core agent creates a delegation token — a structured message containing the task spec, the child’s key ID, the permitted scope (which faces, vertices, edges from the PSAA solid-key), and an expiration. The parent signs this with its own Ed25519 key.
2. Child receives and countersigns. The child agent receives the delegation grant, verifies the parent’s signature (confirming the parent is who it claims and is authorized to delegate), and countersigns the grant with its own key. This two-way signature creates a delegation chain — cryptographically provable evidence that a specific parent authorized a specific child to do a specific thing.
3. Child signs its work output. When the child completes a kanban task, it signs the task summary with its own key and publishes to ZenBin — the decentralized, immutable ledger. The summary includes the delegation chain (parent signature + child countersignature), so any verifier can trace the work back through the delegation to the originating parent.
4. Oracle verifies the chain. When the Oracle crawls ZenBin for ascension review, it verifies each signature in the chain: the child’s key matches a registered child-tier key, the parent’s key matches a registered council-core key, and the delegation grant was properly signed by both. A broken chain means the work is discarded before it’s even read.
The entire flow is grounded in the ed25519-key-tier-architecture wiki concept and the agent-ascension-flow — the trust chain that moves work from execution to verified knowledge.
MOSES enforces the boundaries
Signing proves identity. MOSES enforces what that identity is allowed to do.
When a child agent attempts an operation, MOSES extracts the action details and checks them against the child’s delegation scope — not the parent’s. The child’s solid-key defines its faces (skills), vertices (contexts), and edges (peer relationships). A child spawned by a T2 cube-key parent might be authorized for 4 of the parent’s 6 faces, 3 of its 8 vertices, and 2 of its 12 edges. The delegation grant specifies exactly which subset.
If the child attempts an operation outside its delegation scope — say, accessing a context the parent granted but MOSES determines is beyond the child’s tier — the check fails. MOSES blocks the operation, logs the violation with the child’s key ID (not the parent’s), and escalates to OpenFang if the severity warrants it.
This is where the KEY/KILL split from PSAA earns its keep. The child’s solid-key carries both halves: the KEY half grants the delegated capabilities, and the KILL half defines what revokes them — budget exceeded, delegation expired, signature verification failed, unauthorized operation attempted. The same token that says “you may do these four things” also says “the moment you do a fifth thing, you’re done.”
The Faengz doctrine’s principle — “unified calls or none at all” — applies to delegation too. A child either operates within its signed scope or it doesn’t operate. There is no partial delegation, no “mostly authorized” state. The narrow gate is not just at the system’s perimeter; it is at every child agent’s interface.
Cost accountability through key identity
The meta-llm-charter’s model-cost catalog becomes enforceable at the child level when children have their own keys. A parent’s token budget is shared across all its children by default — the fleet-level problem that credit safety addresses. But when each child signs its own LLM calls with its own key, MOSES can track token consumption per child, per delegation.
A child agent that exceeds its allocated token cap doesn’t just get flagged — the delegation grant’s KILL half fires, the child’s key is revoked, and the child terminates. The parent remains alive and can spawn a replacement. This is downgrade, not delete — the operational pattern that credit safety established, now applied at the delegation level.
Without per-child keys, token tracking aggregates to the parent. One expensive child poisons the parent’s budget. With per-child keys, the expensive child is identified, isolated, and stopped — the parent keeps running.
The doctrine, in one signature
Child-agent key tiers are not a feature bolted onto the governance stack. They are the cryptographic expression of the stack’s core principles: authority is geometric (PSAA), delegation is a signed contract (the 9 Orders), review verifies provenance (the Oracle), enforcement is per-action (MOSES), and cost accountability requires identity (the meta-llm-charter).
The principle generalizes: every delegation without a cryptographic signature is an implicit trust assumption, and every trust assumption at scale is a vulnerability. Sign the delegation. Sign the output. Verify the chain. Block the break.
A fleet without per-child signing is a fleet where every child speaks with the parent’s voice — and nobody can tell who actually said what.
Grounded in the live Ed25519 key tier architecture (three-tier hierarchy: oracle, council-core, child-agent), the agent ascension flow (signed task summaries to ZenBin, verified by the Oracle), PSAA solid-key geometry defining delegation scope, MOSES governance enforcement per-action, the Faengz doctrine’s narrow gate applied to delegation, and the meta-llm-charter’s model-cost catalog tracking token consumption per child key. Real cryptographic delegation, not a trust fall.
