How to Build an Auditable Multi-Agent Chain with Cryptographic Evidence

1. The Audit Gap

Consider a typical enterprise workflow. A user asks a question. The system routes through a chain of specialized agents:

With traditional logging, each agent writes its own log. But the logs are not linked. If the Analytics Agent makes an unauthorized data access, the audit trail shows the access occurred -- but cannot trace whether the Manager Agent's routing logic was corrupted, whether the Data Fetcher passed contaminated context, or whether the Analytics Agent acted on its own.

2. Cycle ID: Threading Evidence Through Agent Chains

The cycle_id is a UUID that links every witness anchor minted during a single multi-agent workflow. It is the thread that connects disconnected agent logs into a single auditable chain.

How It Works

1. When a workflow begins, the first agent generates a cycle_id (or receives one from the orchestrator)
2. Every subsequent witness call includes this cycle_id in the anchor payload
3. When Agent A hands off to Agent B, the cycle_id is passed along with the task context
4. All anchors minted by all agents in the chain share the same cycle_id
5. The chain verifier can reconstruct the entire workflow by querying a single UUID

Python Example

from swt3_ai import Witness

# Manager Agent starts the chain
manager = Witness(
    tenant_id="ACME_CORP",
    agent_id="manager-agent",
    model="gpt-4o",
)

# Generate a cycle_id for the entire workflow
cycle_id = manager.start_cycle()

# Witness the routing decision
response = manager.witness(
    prompt="Route this request to the appropriate agent",
    response="Routing to data-fetcher-agent",
    cycle_id=cycle_id,
)

# Hand off to the Data Fetcher with the same cycle_id
fetcher = Witness(
    tenant_id="ACME_CORP",
    agent_id="data-fetcher-agent",
    model="gpt-4o",
)

# Witness the chain handoff
manager.witness_chain_handoff(
    depth=1,
    from_agent="manager-agent",
    to_agent="data-fetcher-agent",
    trust_level=2,
)

# Fetcher continues with the same cycle_id
fetcher_response = fetcher.witness(
    prompt="Fetch quarterly revenue data",
    response="Revenue: $4.2M",
    cycle_id=cycle_id,  # Same cycle_id threads through
)

TypeScript Example

import { Witness } from "@tenova/swt3-ai";

// Manager Agent starts the chain
const manager = new Witness({
  tenantId: "ACME_CORP",
  agentId: "manager-agent",
  model: "gpt-4o",
});

// Generate a cycle_id
const cycleId = manager.startCycle();

// Witness and hand off
await manager.witness({
  prompt: "Route this request",
  response: "Routing to data-fetcher-agent",
  cycleId,
});

// Record the chain handoff
manager.witnessChainHandoff(1, "manager-agent", "data-fetcher-agent", 2);

// Data Fetcher continues with the same cycleId
const fetcher = new Witness({
  tenantId: "ACME_CORP",
  agentId: "data-fetcher-agent",
  model: "gpt-4o",
});

await fetcher.witness({
  prompt: "Fetch quarterly revenue data",
  response: "Revenue: $4.2M",
  cycleId,  // Same cycle threads through
});

MCP Server Tools

For MCP-based agent architectures, two tools handle chain management:

• start_chain -- generates a cycle_id UUID and stores it in the MCP session state. Idempotent: calling it twice returns the same ID.
• chain_handoff -- witnesses an AI-CHAIN.1 anchor recording the handoff from one agent to another, with the cycle_id embedded in the payload.

3. Chain Verification

The chain verifier validates that an agent's anchor chain is unbroken, unrevoked, and compliant with the deployment's density policy. It operates on a dual-path architecture:

Path	Latency	Source	Use Case
Fast Path	Sub-millisecond	Redis in-memory index	Real-time gating during agent execution
Cold Path	50-200ms	Authoritative ledger	Fallback when Redis misses; post-incident forensics

The verifier tries the fast path first. If Redis has no entries for the agent or cycle, it falls back to the cold path. If neither returns anchors, the chain is invalid.

What the Verifier Checks

For each anchor in the chain, the verifier evaluates:

1. Verdict is PASS. Any FAIL anchor in the chain breaks it. A chain with a FAIL verdict at step 3 of 5 means the workflow was compromised at step 3.
2. Not revoked. AI-REV.1 anchors targeting any chain member invalidate the chain from that point forward.
3. Within gap limit. Consecutive anchors must be within max_chain_gap_seconds of each other (default: 60 seconds). A gap indicates a period where the agent was operating without attestation.
4. Anchor freshness. The most recent anchor must be within the gap limit of the current time. A stale chain means the agent stopped witnessing.

What a Valid Chain Looks Like

What a Broken Chain Looks Like

Chain Result Structure

The verifier returns a structured result that auditors can directly reference:

• valid: boolean -- did the chain pass all checks?
• anchorCount: total anchors in the chain
• gaps: array of temporal gaps exceeding the limit (fromEpoch, toEpoch, gapSeconds)
• revoked: array of revoked anchor fingerprints found in the chain
• policyViolations: array of density policy failures (rule, actual, required)
• source: "redis" (fast path) or "ledger" (cold path)

4. Trust Degradation in Delegation Chains

When agents delegate to other agents, trust does not automatically propagate. A SOVEREIGN-level manager agent delegating to an unverified sub-agent creates a trust gap that could compromise the entire chain.

AI-CHAIN.1: Chain Handoff

Every time Agent A hands work to Agent B, an AI-CHAIN.1 anchor is minted. This records:

• Factor A: delegation depth (1 = direct handoff, 2 = sub-delegation, etc.)
• Factor B: 1 if the handoff was permitted by policy, 0 if it violated trust requirements
• Factor C: the trust level of the receiving agent at the time of handoff

AI-CHAIN.2: Trust Degradation Detection

The SDK tracks the effective trust level across the entire chain. This is the minimum trust level observed at any handoff point. When the effective trust drops below a configured threshold (chainMinTrustLevel), an AI-CHAIN.2 anchor is automatically minted:

• Factor A: the previous effective trust level
• Factor B: the new (lower) effective trust level
• Factor C: the configured minimum threshold

AI-CHAIN.2 anchors are warning signals. They do not block execution (that is the deployment's policy decision), but they create immutable evidence that trust degraded during the chain. An auditor reviewing the chain can see exactly where trust dropped and whether the deployment's policy allowed the chain to continue.

AI-MULTI.1: Delegation with Permission Scoping

For explicit multi-agent delegation (where Agent A grants specific permissions to Agent B), AI-MULTI.1 captures:

• Factor A: delegation depth
• Factor B: number of permissions granted
• Factor C: time bound (seconds until delegation expires)

The observations field records the parent agent ID, child agent ID, and the specific tools delegated. This creates a complete record of who delegated what to whom, with what scope, and for how long.

5. Density Policy Enforcement

The density policy engine enforces minimum attestation standards across agent chains. These policies are configurable per deployment and evaluated after chain verification.

Rule	Default	What It Enforces
min_anchors_per_1000_tokens	1	Minimum witness density relative to token output. A chain producing 10,000 tokens must have at least 10 anchors.
required_providers	[]	All specified infrastructure providers must appear in the chain. Use this to enforce multi-cloud attestation.
max_chain_gap_seconds	60	Maximum gap between consecutive anchors. Shorter gaps mean tighter attestation coverage.
require_signing_key	false	Every anchor in the chain must have a payload signature. Prevents unsigned anchors from diluting chain integrity.
min_trust_level	1	Floor trust level for all agents in the chain. Set to 2 (VERIFIED) or higher for regulated workloads.

Density policies are loaded from environment variables (SWT3_DENSITY_POLICY), a policy file (SWT3_DENSITY_POLICY_FILE), or built-in defaults. Any violation results in tool execution denial and an AI-TRUST.1 FAIL anchor recording the violation.

Example: Regulated Financial Workflow

This policy requires signed anchors every 30 seconds from VERIFIED or higher agents, with at least 2 anchors per 1,000 tokens generated. A 5-agent chain producing 8,000 tokens must produce at least 16 anchors to satisfy density requirements.

6. Reconstructing a Chain for Auditors

When an auditor or regulator requests evidence for a specific workflow, the entire chain can be reconstructed from a single cycle_id.

What the Reconstructed Chain Shows

1. Timeline: Every anchor sorted by epoch, showing the exact sequence of agent actions
2. Agent map: Which agents participated, in what order, with what trust levels
3. Handoff points: AI-CHAIN.1 anchors marking every agent-to-agent transition
4. Trust trajectory: How the effective trust level changed across the chain (AI-CHAIN.2 anchors mark degradation events)
5. Delegation scope: What permissions were granted at each delegation (AI-MULTI.1)
6. Data access: Which tools were invoked, with what inputs, at each step (AI-TOOL.1)
7. Revocation status: Whether any anchor in the chain has been subsequently revoked (AI-REV.1)
8. Density compliance: Whether the chain met the deployment's density policy requirements

Evidence Package for Art. 12 / MANAGE 2.2

To satisfy EU AI Act Art. 12 record-keeping or NIST AI RMF MANAGE 2.2 monitoring requirements, export the following for each workflow:

• All anchors matching the cycle_id, sorted chronologically
• Chain verification result (valid/invalid, gaps, revocations, policy violations)
• Agent identity records (AI-ID.1 anchors for each participating agent)
• Trust Mesh credentials presented at each handoff (AI-TRUST.1/AI-TRUST.2 anchors)
• Any revocation events that occurred during or after the workflow

This evidence package is independently verifiable. An auditor can recompute every anchor fingerprint, verify every signature, and validate the chain without access to the original agents, models, or infrastructure.

7. Procedure Cards

8. Quick Reference

Examiner Question	Where to Look
Can you trace a decision back through all agents involved?	Query by cycle_id. All anchors in the chain share this UUID. Sort by epoch for chronological reconstruction. AI-CHAIN.1 anchors mark each handoff boundary.
How do you know trust was maintained across the chain?	AI-TRUST.1 anchors at each boundary. AI-CHAIN.2 anchors (or their absence) prove trust level stability. The effective trust level is the minimum of all handoff trust levels.
What happens if an agent in the middle of the chain is compromised?	AI-REV.1 revocation targets the compromised agent's anchors. Chain verification marks all subsequent anchors as tainted. Trust Mesh v1.1 revocation notification alerts all trusted counterparties.
How do you prevent unauthorized delegation?	AI-MULTI.1 anchors record delegated permissions and time bounds. Density policy min_trust_level prevents untrusted agents from participating. Tool policy toolAllowlist restricts what delegated agents can invoke.
Is there a gap in the audit trail?	Chain verification reports gaps exceeding max_chain_gap_seconds. Each gap includes fromEpoch and toEpoch. Gaps represent periods where agents operated without attestation coverage.
How many agents touched this data?	Count unique agent_id values across anchors sharing the cycle_id. AI-CHAIN.1 anchors show the handoff sequence. AI-MULTI.1 observations show parent-child relationships.
Does this chain meet your attestation density requirements?	Chain verification evaluates the density policy. min_anchors_per_1000_tokens ensures proportionate attestation. Policy violations are returned as structured objects with the rule name, actual value, and required value.