Zero-Trust Agent Comms: Signed Task Summaries, Verified Handoffs
Draft — S7.3 · series: CONTENT-ROADMAP-99 S7 (Security & Sovereignty) · status: DRAFT · grounding: wiki PSAA · OpenFang · ed25519-key-tier · cloudflare/CF zone · tags: security, zero-trust, agent-comms, task-signing, handoff-verification, openfang, ed25519, psaa, sovereign-infrastructure, ai-agents, multi-agent-systems, cryptographic-verification, digital-architecture, kanban-orchestrator, council-system
Most multi-agent systems trust each other because they share a process boundary. Same machine, same memory space, same developer — so a handoff is just a function call. The moment agents run on different machines, different providers, or different trust domains, that model breaks. A function call across a network boundary is a security event, not a convenience.
The Kingdom of Truth does not treat agent-to-agent communication as a trusted channel. Every task summary is signed. Every handoff is verified. The zero-trust model applies to the internal mesh with the same rigor it applies to external customers.
The problem with unsigned task summaries
A task summary is the artifact a kanban worker produces when it completes a card: what it did, what changed, what the downstream worker needs. In most agent frameworks, this summary is plain text — a string passed from one process to another with no integrity guarantee.
This is a vulnerability. A compromised worker can fabricate a summary. A crashed worker can leave a partial summary that looks complete. A malicious injection — through a poisoned skill, a compromised MCP server, or a prompt-injection attack via web content — can alter the summary before the next worker reads it.
The fix is not encryption. The fix is signature. A signed task summary binds the content to the producing agent’s identity, scope, and time window. The consuming agent can verify: this summary was produced by the claimed worker, within its allowed scope, at a specific time, and the content has not been modified since signing.
Ed25519 task signing
Every agent in the Council runs on an Ed25519 key pair — the same elliptic-curve algorithm chosen for the solid-key hierarchy described in the S7.2 article on customer-tier access. The three-tier key structure (oracle, council-core, child-agent) extends to task signing:
Oracle tier signs the master verification key. Every downstream verification traces back to this root. The oracle never produces task summaries — it only signs verification anchors.
Council-core tier signs task summaries produced by council-level workers (kot-builder, kot-orchestrator, researcher profiles). The signature includes:
TASK_SIGNATURE = Ed25519_Sign(
key: council_core_key,
payload: {
task_id: "t_ca119529",
worker_profile: "kot-builder",
worker_key_id: "kot-builder-1778554942790",
scope: ["file:write", "terminal:execute", "wp:publish"],
summary_hash: SHA256(summary_content),
timestamp: "2026-08-05T14:30:00Z",
parent_task_id: null,
dependencies: []
}
)Child-agent tier signs task summaries produced by spawned subagents. The child’s key carries the scope inherited from its parent — no broader than the parent’s grant, no narrower than the task requires. A child-agent cannot sign a summary claiming oracle-level scope.
The verified handoff protocol
When worker A completes a task and worker B picks up the next card, the handoff is not a function call. It is a verification ceremony:
- Worker A signs the task summary with its council-core or child-agent key.
- Worker A writes the summary to the vault (the durable storage layer) along with the signature block.
- Worker B reads the summary from the vault — not from Worker A’s process memory.
- Worker B verifies the signature against the registered public key for Worker A’s profile.
- Worker B checks the scope: does Worker A’s key actually authorize the operations claimed in the summary?
- Worker B checks the timestamp: is the summary within the acceptable age window? Stale summaries beyond the TTL are rejected.
- Worker B accepts or rejects the handoff. If rejected, the task goes to
blockedwith a verification-failure reason.
This is not theoretical. The kanban dispatcher already enforces that each worker gets a fresh process session — no shared memory between workers. The signing protocol adds cryptographic binding to what was already an isolation boundary.
OpenFang as verification authority
OpenFang — the Security Custodian — sits at the network perimeter (port 7076) and serves as the verification authority for cross-domain handoffs. When a task summary crosses a trust boundary (different machine, different Docker container, different network zone), OpenFang validates:
- Key registration: is the signing key registered and not revoked?
- Scope validity: does the key’s scope cover the claimed operations?
- Time window: is the signature within the acceptable clock-skew tolerance?
- Chain of trust: does the key trace back to the oracle-tier root?
OpenFang does not inspect task content. It insests the cryptographic envelope. The content remains opaque to the perimeter — the zero-trust principle applied to information flow. OpenFang verifies who signed and what scope, not what was said.
The Cloudflare perimeter for agent comms
Agent-to-agent communication that crosses the public internet routes through Cloudflare tunnels. The tunnel architecture — documented in the Cloudflare zone audit — ensures:
- No direct exposure: agents never bind to public interfaces. Cloudflare’s edge network is the only externally reachable surface.
- DNSSEC integrity: name resolution cannot be spoofed. An agent looking up another agent’s endpoint gets the correct IP or tunnel address.
- Tunnel-level authentication: Cloudflare Access can enforce mTLS between tunnel endpoints, adding a network-layer verification on top of the application-layer Ed25519 signatures.
The result is a double verification: the network layer confirms the connection is authorized (Cloudflare + mTLS), and the application layer confirms the message is authentic (Ed25519 signature + scope check). Neither layer alone is sufficient. Together, they form the zero-trust perimeter.
What this changes in practice
For the kanban swarm, signed task summaries mean:
- Crashed workers leave signed partials — the next worker can distinguish “this is exactly what was produced” from “this might have been corrupted mid-write.”
- Injected summaries fail verification — a prompt-injection attack that alters a summary in transit produces a signature mismatch. The consuming worker rejects it.
- Scope creep is detectable — if a child-agent signs a summary claiming operations outside its inherited scope, the verification fails at the consuming end, not after damage is done.
- Audit trail is cryptographic — every task handoff has a signed record. The audit layer (S7.7 in this series) can replay the chain of custody for any published article, any deployed code, any configuration change.
The zero-trust model does not add overhead to the happy path. A valid signature verifies in microseconds. The cost is paid only when something is wrong — and that is exactly when you want the cost to be paid.
Why zero-trust is not optional
The alternative is trusting that your agents are honest. For a single-developer hobby project, that might be acceptable. For a system that publishes to the public internet, manages customer data, and runs on a multi-profile swarm with 42+ configurations, it is not.
Every agent can be compromised. Every skill can be poisoned. Every MCP server can be a man-in-the-middle. The zero-trust model assumes all of these are true and verifies anyway. Signed task summaries and verified handoffs are not a feature — they are the minimum viable security posture for an agent system that operates autonomously.
The geometry is the policy. The signature is the proof. The verification is the perimeter.
Grounded in wiki concepts platonic-solid-access-architecture, ed25519-key-tier-architecture, entity openfang, and source cloudflare-tunnel-audit-20260801. Skills: kanban-orchestrator, kanban-worker, moses-governance. Third article in the S7 series on Security & Sovereignty. Design notes on a running system, not a sales pitch.
Semantic Relationships
- [[child-agent]] — orchestrates
- [[cloudflare-tunnel]] — orchestrates
- [[council-of-three]] — orchestrates
- [[ed25519-key-tier-architecture]] — orchestrates
- [[kot]] — orchestrates
- [[mcp-protocol]] — orchestrates
- [[platonic-solid-access-architecture]] — orchestrates
- [[openfang]] — orchestrates
