Multi-Agent Workflows

When an orchestrator agent delegates tasks to sub-agents, the delegation chain goes opaque. Who authorized whom? Who saw what? Who decided what? Without a provenance layer, these questions cannot be answered — not by the orchestrator, not by the auditor, not by the sub-agent itself.

Current approaches rely on logging and monitoring: post-hoc reconstruction from mutable, fragmented, system-scattered records. Logs can be altered. Context windows expire. Tool responses are ephemeral. When something goes wrong — a wrong decision, a data leak, an unauthorized access — there is no cryptographic proof of how it happened.

Delegated ≠ traceable. That is the structural gap Lemma closes.

Before Lemma — How the Incident Unfolds

Context

A healthcare company deploys an AI orchestrator to handle insurance claim processing. The orchestrator delegates tasks to specialized sub-agents: a data-retrieval agent, a compliance-check agent, and a document-generation agent. Sub-agents call MCP servers to access patient records, regulatory databases, and template engines.

Incident Timeline

Phase	What Happens	Why It's Undetectable
Delegation	Orchestrator assigns claim to compliance-check agent with "verify eligibility" scope	Scope is a prompt instruction, not a cryptographic bound
Escalation	Compliance agent calls data-retrieval agent for "full patient history"	No proof of what scope was (or wasn't) delegated to the sub-sub-agent
Over-access	Data-retrieval agent queries full medical records — including diagnoses unrelated to the claim	Access control is system-level, not delegation-level; the agent has valid credentials
Exfiltration	Compliance agent includes sensitive diagnosis in its report to orchestrator	No provenance layer tracks what data entered which decision
Discovery	Patient complains 3 months later; audit reveals the over-access	Logs are mutable and scattered; no cryptographic proof of the delegation chain
Accountability	"The orchestrator delegated." "The sub-agent decided." "The MCP server returned it."	No single node can reconstruct the full chain of authorization

Root Cause

• Delegation scope is soft — encoded as prompts, not as cryptographic proofs
• Sub-delegation is untracked — the orchestrator doesn't know the data-retrieval agent was called
• Data provenance is absent — no record of what data influenced which decision
• Accountability is diffused — no node owns the complete chain

After Lemma — How the Same Scenario Plays Out

What Changes at Deployment

• Each delegation step generates a ZK proof: delegator, delegate, scope, timestamp. The proof is anchored on-chain.
• Every agent operation carries its delegation proof. Downstream tools and MCP servers verify the caller's authority without trusting the agent's self-attestation.

Incident Timeline (With Lemma)

Phase	What Happens	How Lemma Changes It
Delegation	Orchestrator creates proof: "compliance-check agent, scope: verify eligibility only"	Scope is cryptographic, not interpretive
Attempted escalation	Compliance agent tries to call data-retrieval for "full patient history"	Delegation proof says eligibility only — data-retrieval agent's scope is bounded
Over-access prevented	Data-retrieval agent can only query eligibility-related fields	MCP server verifies the delegation proof before responding
No exfiltration possible	Sensitive diagnoses are outside the proven scope	The proof prevents the access, not just detects it
Full audit trail	Every step carries delegation proof, anchored on-chain	Auditor reconstructs the complete chain with cryptographic evidence

Design Principle

The delegation chain is the audit trail. The proof is the evidence. The on-chain anchor guarantees nothing was altered after the fact.

┌─────────────────────────────────────────────────────────────┐
│                  ORCHESTRATOR (Principal)                     │
│                                                              │
│  ┌────────────────────┐    ┌────────────────────────────┐   │
│  │  Task Assignment    │───▶│  Lemma Delegation Prover    │   │
│  │  "Verify claim      │    │  - ZK proof: principal →    │   │
│  │   eligibility"      │    │    delegate, scope, time    │   │
│  └────────────────────┘    │  - On-chain anchor          │   │
│                             └─────────────┬──────────────┘   │
└───────────────────────────────────────────┼──────────────────┘
                                            │ delegation proof
                                            ▼
┌─────────────────────────────────────────────────────────────┐
│                  COMPLIANCE AGENT (Delegate)                   │
│                                                              │
│  ┌────────────────────┐    ┌────────────────────────────┐   │
│  │  Sub-delegation     │───▶│  Lemma Delegation Prover    │   │
│  │  "Retrieve patient  │    │  - ZK proof: delegate →     │   │
│  │   eligibility data" │    │    sub-delegate, scope      │   │
│  └────────────────────┘    │  - Scope: eligibility only  │   │
│                             └─────────────┬──────────────┘   │
└───────────────────────────────────────────┼──────────────────┘
                                            │ delegation proof
                                            ▼
┌─────────────────────────────────────────────────────────────┐
│                  DATA-RETRIEVAL AGENT (Sub-Delegate)           │
│                                                              │
│  ┌────────────────────┐    ┌────────────────────────────┐   │
│  │  MCP Server Call    │───▶│  Proof Carrier              │   │
│  │  "Query eligibility │    │  - Full delegation chain    │   │
│  │   fields only"      │    │  - Scoped to eligibility    │   │
│  └────────────────────┘    │  - Verification at server   │   │
│                             └─────────────┬──────────────┘   │
└───────────────────────────────────────────┼──────────────────┘
                                            │ scoped query + proof
                                            ▼
┌─────────────────────────────────────────────────────────────┐
│                  MCP SERVER (Tool Provider)                    │
│                                                              │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  Lemma Verification                                   │   │
│  │  1. Is the delegation chain intact (principal →        │   │
│  │     delegate → sub-delegate)?                          │   │
│  │  2. Does the requested scope fall within the            │   │
│  │     delegated scope at each level?                     │   │
│  │  3. Are all proofs still valid (not revoked)?          │   │
│  │  ✓ All checks pass → return eligibility data only      │   │
│  │  ✗ Scope exceeds delegation → reject query              │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

Component Flow

1. Delegation: Each delegation step generates a ZK proof binding delegator → delegate → scope → timestamp. The proof is anchored on-chain as a commitment.
2. Sub-delegation: When a delegate further delegates, the new proof references the parent proof. The scope can only narrow — it cannot exceed what was originally delegated.
3. Execution: The sub-delegate carries the full proof chain when calling MCP servers or tools. The server verifies the chain independently.
4. Aggregation: The orchestrator assembles the final output with a complete proof chain from original principal to final result. Every node in the chain is cryptographically bound.

When a multi-agent workflow runs with Lemma, the following facts are cryptographically proven at each delegation node — not logged after the fact:

• Authorization chain (principal → delegate → sub-delegate) — Who authorized whom, and on what basis. Each link in the chain carries a ZK proof binding the delegator to the delegate.
• Scope inherited at each step — What authority was passed down. Scope can only narrow through delegation; any expansion is rejected at verification.
• Inputs and decisions per node — What data each agent accessed and what it decided. The proof chain records the inputs that influenced each decision point.
• End-to-end auditability — The complete chain from original principal to final output is reconstructable with cryptographic evidence. No gaps, no ambiguities.

X402 Commerce

Pillar: P3 Agent Trust Chain

When sub-agents in a workflow initiate purchases on the x402 rail, each agent's authority must be proven. Multi-agent workflow proofs provide the delegation chain that x402 sellers verify.

→ X402 Commerce

Delegated Treasury

Pillar: P3 Agent Trust Chain

When an orchestrator delegates purchasing authority to a sub-agent, the spend-control attestation must travel with the delegation. Delegated Treasury attestations and workflow proofs combine to prove both the authority and the scope.

→ Delegated Treasury