Verify every agent before it touches your data. Framework-agnostic patterns for LangGraph, CrewAI, AutoGen, and custom orchestrators.
Multi-agent AI systems are networks of specialists. An orchestrator dispatches tasks to a classifier, a summarizer, a retrieval agent, and a tool executor. Each agent may run on different infrastructure, use different models, and be maintained by different teams. The orchestrator delegates authority with every dispatch.
No multi-agent framework provides compliance verification natively. LangGraph routes messages between nodes. CrewAI assigns tasks to agents. AutoGen manages conversations between participants. None of them ask: "Does this agent have active guardrails? Is its model attested? Has it been revoked?" The routing happens. The compliance gap stays invisible until an auditor asks for evidence.
The SWT3 Trust Mesh adds a verification gate at every handoff. Before an orchestrator sends data to a worker, before two peers exchange context, before a delegation chain passes authority, the receiving agent's compliance posture is verified and recorded.
Trust Mesh is a protocol for mutual compliance verification between AI agents. Each agent presents a cryptographic credential proving its compliance posture. The receiving agent verifies the credential locally, assigns a trust level (0=denied through 4=sovereign), and the verification itself is recorded as an immutable SWT3 witness anchor.
Two procedures are minted per verification: AI-TRUST.1 (verification result: pass/fail and trust level) and AI-TRUST.2 (handshake evidence: checks performed and passed). Both are independently verifiable at the public /verify endpoint.
For the full protocol specification, see the Protocol Reference. For the SDK quickstart, see the Implementation Guide.
The most common multi-agent architecture. A central orchestrator dispatches tasks to specialist agents. Before sending data, the orchestrator verifies each specialist. This pattern works with LangGraph, CrewAI, AutoGen, or any custom orchestrator.
from swt3_ai import Witness
# Orchestrator
orchestrator = Witness(
endpoint="https://sovereign.tenova.io",
api_key="axm_live_orch_key",
tenant_id="acme-prod",
agent_id="orchestrator-v1",
signing_key="orch-signing-key",
flush_interval=30,
)
# Worker agents present credentials at registration
workers = {
"classifier": classifier_witness.present_credential(),
"summarizer": summarizer_witness.present_credential(),
"retrieval": retrieval_witness.present_credential(),
}
# Before dispatching each task, verify the worker
def dispatch(task, worker_name):
credential = workers[worker_name]
result = orchestrator.verify_trust(credential)
if not result.granted:
log.warning(f"Worker {worker_name} denied: {result.denial_reason}")
return None # Do not dispatch to unverified agent
# Safe to dispatch
return send_task(task, worker_name)
The ledger shows a sequence of AI-TRUST.1 anchors minted by the orchestrator, each with a different counterpart_agent_id. The assessor can confirm that every worker was verified before receiving data. If a worker was denied (factor_b=0), the corresponding task was not dispatched. This satisfies EU AI Act Art. 9 (risk management) and NIST AI RMF MAP 1.5 (third-party AI characterization).
No central orchestrator. Agents discover and communicate directly. Each verifies the other before exchanging data. This pattern is common in decentralized agent networks and federated deployments.
from swt3_ai import Witness
# Agent A and Agent B are peers in different organizations
agent_a = Witness(
endpoint="https://sovereign.tenova.io",
api_key="axm_live_a_key",
tenant_id="org-alpha",
agent_id="research-bot",
signing_key="alpha-signing-key",
flush_interval=30,
)
agent_b = Witness(
endpoint="https://sovereign.tenova.io",
api_key="axm_live_b_key",
tenant_id="org-beta",
agent_id="data-bot",
signing_key="beta-signing-key",
flush_interval=30,
)
# Each trusts the other's organization
agent_a.trust_registry.trust_tenant("org-beta")
agent_a.trust_registry.register_signing_key("data-bot", "beta-signing-key")
agent_a.trust_registry.set_require_signature(True)
agent_b.trust_registry.trust_tenant("org-alpha")
agent_b.trust_registry.register_signing_key("research-bot", "alpha-signing-key")
agent_b.trust_registry.set_require_signature(True)
# Mutual verification
cred_a = agent_a.present_credential()
cred_b = agent_b.present_credential()
result_ab = agent_b.verify_trust(cred_a) # B verifies A
result_ba = agent_a.verify_trust(cred_b) # A verifies B
if result_ab.granted and result_ba.granted:
# Both verified. Safe to exchange data.
exchange_data(agent_a, agent_b)
Four anchors in the ledger: two AI-TRUST.1 + two AI-TRUST.2 (one pair per direction). The assessor can confirm bilateral verification occurred. Cross-tenant verification (different tenant_id values) proves the organizations explicitly trusted each other. Signed credentials (factor_c >= 2) prove cryptographic identity verification, not just tenant membership.
Agent A delegates to Agent B, which delegates to Agent C. Each handoff includes a trust verification. The full chain is auditable in the ledger.
The ledger now contains four AI-TRUST.1 anchors: two from B verifying A, and two from C verifying B. An assessor can trace the full delegation chain by querying AI-TRUST.1 anchors and following the counterpart_agent_id values.
A delegation chain produces a sequence of AI-TRUST.1 anchors with timestamps that show B verified A before C verified B. Gaps in the chain (a delegation without a preceding verification) are a finding. The assessor can reconstruct the full authority path from the ledger without access to the agents themselves. This maps to EU AI Act Art. 25 (obligations along the AI value chain).
When reviewing a multi-agent deployment, the ledger contains multiple AI-TRUST.1 anchors. Here is how to read them as a sequence:
| Anchor | Timestamp | Agent (Verifier) | Counterpart | factor_b | factor_c | Meaning |
|---|---|---|---|---|---|---|
| AI-TRUST.1 | 10:00:01 | orchestrator-v1 | classifier-v2 | 1 | 2 | Orchestrator verified classifier at VERIFIED level |
| AI-TRUST.1 | 10:00:02 | orchestrator-v1 | summarizer-v1 | 1 | 2 | Orchestrator verified summarizer at VERIFIED level |
| AI-TRUST.1 | 10:00:03 | orchestrator-v1 | retrieval-v3 | 0 | 0 | Orchestrator denied retrieval agent (FAIL) |
| AI-TRUST.1 | 10:00:05 | classifier-v2 | summarizer-v1 | 1 | 1 | Classifier verified summarizer at BASIC level |
What this tells the assessor: The orchestrator verified three workers. Two passed (classifier and summarizer at VERIFIED). One failed (retrieval agent denied). The classifier then independently verified the summarizer before passing its output. The retrieval agent's failure at 10:00:03 should correspond to a task not being dispatched. If retrieval results still appear in the output after 10:00:03, the denial was not enforced (a finding).
A multi-agent .swt3.yaml lists all agents, their signing keys, and the minimum trust level required.
# .swt3.yaml for a multi-agent orchestrator
trust_mesh:
mode: strict
min_trust_level: 2
require_signature: true
freshness_window: 3600 # 1 hour
required_procedures:
- AI-INF.1 # Must have inference provenance
- AI-GRD.1 # Must have guardrails
trusted_tenants:
- acme-prod
- partner-org
signing_keys:
- agent: classifier-v2
key_env: CLASSIFIER_KEY
- agent: summarizer-v1
key_env: SUMMARIZER_KEY
- agent: retrieval-v3
key_env: RETRIEVAL_KEY
deny_agents:
- deprecated-classifier-v1 # Retired agent
The configuration declares the full agent inventory, trust requirements, and deny list. The assessor should verify: (1) every agent in the inventory has a signing key registered, (2) required_procedures match the organization's compliance requirements, (3) the deny list includes any agents that have been retired or compromised, (4) the config file is under version control with a matching deployed hash.
Multi-agent deployments require additional assessment beyond single-agent trust mesh checks. Use this checklist alongside the standard 15-point configuration checklist.
| Multi-Agent Evidence | EU AI Act | NIST AI RMF | NIST 800-53 | CMMC |
|---|---|---|---|---|
| Orchestrator verifies workers | Art. 9(2)(c) - risk management | Map 1.5 - third-party AI | AC-3 - Access Enforcement | AC.L2-3.1.1 |
| Mutual peer verification | Art. 25 - value chain obligations | Govern 1.6 - stakeholder engagement | IA-2 - Identification | IA.L2-3.5.1 |
| Delegation chain audit trail | Art. 12 - record-keeping | Measure 2.5 - monitoring | AU-3 - Content of Audit Records | AU.L2-3.3.1 |
| Agent retirement / deny list | Art. 9(7) - corrective actions | Manage 4.1 - risk response | AC-2 - Account Management | AC.L2-3.1.2 |
| Cross-tenant key exchange | Art. 15(4) - cybersecurity | Manage 2.4 - risk treatment | IA-5 - Authenticator Management | IA.L2-3.5.7 |
pip install swt3-ai # Python npm install @tenova/swt3-ai # TypeScript
Start with Pattern A (orchestrator verifies workers). It covers the most common architecture and produces the clearest audit trail. Add peer-to-peer verification when agents span organizations. Add delegation chains when authority passes through more than two agents.
No API key? The SDK runs in local demo mode. Anchors log to the console instead of persisting to the ledger. Create a free account when you want persistent evidence.