SWT3 Trust Mesh Protocol

1. Purpose

The SWT3 Trust Mesh Protocol defines how autonomous AI agents establish, verify, and enforce mutual trust before exchanging data, invoking tools, or delegating tasks. It is the authentication and authorization layer for agent-to-agent communication in regulated and unregulated environments.

The protocol operates independently of the SWT3 compliance witnessing pipeline. Compliance witnessing generates the evidence. The Trust Mesh consumes that evidence to make real-time trust decisions.

The Trust Mesh answers three questions:

1. Who is this agent?
2. Has this agent been attested?
3. Should I allow this agent to act?

How this differs from existing identity protocols: mTLS verifies that a server holds a valid certificate. OAuth verifies that a token was issued by a trusted authority. SPIFFE verifies workload identity across infrastructure. None of these verify compliance posture. An agent can have a valid TLS certificate, a fresh OAuth token, and a SPIFFE identity while running with zero guardrails, stale model weights, and no audit trail. Trust Mesh verifies what the agent has done (active attestations), not just who it is (identity). The two layers are complementary: use mTLS or SPIFFE for transport security, and Trust Mesh for compliance verification on top.

2. Trust Levels

The Trust Mesh defines five trust levels. Each level is a strict superset of the level below it.

Trust levels are evaluated locally by the verifying agent. The protocol does not require a central authority for level assignment. However, the evidence backing each level (anchors, signatures, hardware attestation) is verified against a trusted ledger.

3. Credential Format

A Trust Credential is the unit of identity exchange between agents. It contains evidence sufficient for the receiving agent to evaluate trust level.

All fields except credentialSignature are included in the signature computation. Boolean fields default to false if absent.

For working code examples that construct and verify credentials, see the Implementation Guide Quick Start.

4. Credential Signing

Credentials are signed using HMAC-SHA256 to prevent forgery, field tampering, and trust level escalation. The signing formula is locked for cross-language parity.

4.1 Signature Message Construction

Procedures are sorted alphabetically and joined by comma. The message is a colon-delimited string:

{agentId}:{tenantId}:{anchorFingerprint}:{anchorTimestampMs}:{isSigned?1:0}:{hasHardwareAttestation?1:0}:{hasGuardrails?1:0}:{clearingLevel}:{sortedProcedures}

4.2 Signature Computation

HMAC-SHA256(message, signingKey) -> hex string

4.3 Verification

The receiving agent reconstructs the message from the credential fields and computes the HMAC using the counterpart's registered signing key. Comparison is constant-time to prevent timing attacks.

4.4 Post-Quantum Signing

ML-DSA-65 (FIPS 204) post-quantum signing is available as an alternative to HMAC-SHA256 via the signing_algorithm: ml-dsa-65 configuration option in .swt3.yaml. This provides quantum-resistant credential signatures for deployments requiring long-term cryptographic assurance. The digest_algorithm field is a separate option that controls hash function selection (SHA-256 only in this version).

4.5 Trust Level Capping

This prevents self-elevation. An agent cannot claim ATTESTED status without a verifiable signature.

5. Verification Flow

When Agent A wants to interact with Agent B:

6. Denial Codes

The first 10 codes are emitted by the local verifyCredential function. The last 2 (anchor_not_found, anchor_revoked) are reserved for network-level ledger verification and are not emitted by the local SDK.

For assessor-oriented analysis of denial patterns, see Common Findings in the Assessment Guide.

7. Cross-Tenant Trust

Same-tenant agents trust each other by default. Cross-tenant trust requires explicit registration.

7.1 Tenant Trust

Agent B's registry adds Agent A's tenant as trusted:

registry.trustTenant("TENANT_A")

7.2 Agent Trust

For finer control, trust a specific agent within a tenant:

registry.trustAgent("TENANT_A", "agent-007")

7.3 Key Exchange

For signed credentials, Agent B registers Agent A's signing key:

registry.registerSigningKey("agent-007", sharedKey)

7.4 Deny Override

Deny lists take precedence over trust lists. A denied agent cannot be trusted regardless of tenant status.

8. Anchor Chain Verification

For long-running agent sessions, a single anchor may not be sufficient. The chain verifier validates a sequence of anchors over time.

8.1 Chain Query

The verifier queries anchors by agent_id or cycle_id, sorted by epoch. The query path prioritizes speed:

8.2 Chain Checks

For each anchor in the chain:

• Verdict must be PASS (FAIL anchors break the chain)
• Not revoked (AI-REV.1 check)
• Within maximum gap of the next anchor

8.3 Gap Detection

Consecutive anchors must be within max_chain_gap_seconds of each other. Gaps indicate periods where the agent was unwitnessed. Default maximum gap: 60 seconds.

8.4 Chain Result

The chain verification returns a structured result including: validity status, anchor count, detected temporal gaps, revoked anchor fingerprints, and density policy violations.

9. Density Policy

The density policy engine enforces minimum attestation standards for agents interacting through the Trust Mesh.

Any policy violation results in tool execution denial. The chain verifier mints an AI-TRUST.1 FAIL anchor recording the denial.

10. Key Attestation

Key attestation binds a public key to an anchor fingerprint with an HMAC proof, allowing agents to prove possession of a signing key tied to a specific compliance state.

10.1 Attestation Structure

10.2 Verification

The verifier reconstructs the attestation message and validates the HMAC against the agent's registered signing key. Freshness is enforced: attestations older than the freshness window are rejected.

10.3 Key Purposes

signing keys are used for credential and anchor signing. encryption keys protect data in transit between agents. delegation keys authorize sub-agent spawning (AI-DEL.1).

11. Challenge-Response Liveness

Challenge-response liveness proves an agent possesses its signing key at the moment of interaction, preventing credential relay attacks where a valid credential is forwarded by a compromised intermediary.

11.1 Flow

11.2 When to Use

Liveness verification is optional and adds one round-trip of latency. It is recommended for: cross-tenant interactions at ATTESTED or SOVEREIGN trust levels, delegation chain establishment (AI-DEL.1), and any interaction where credential relay is a credible threat.

12. Revocation

Agents and anchors can be revoked at any time through three mechanisms.

12.1 Anchor Revocation

An AI-REV.1 anchor is minted targeting the revoked anchor's fingerprint. Seven reason codes are defined:

12.2 Agent and Tenant Denial

Agents and entire tenants can be added to the deny list at runtime. Denial is immediate within the local registry.

12.3 Revocation Propagation

Cross-tenant revocation propagation uses a defense-in-depth approach with three mechanisms at decreasing latency:

Any one mechanism is sufficient to prevent a revoked agent from maintaining access indefinitely. All three operate independently.

12.4 Revocation Notification (RECOMMENDED)

When an AI-REV.1 anchor is minted, the revoking agent SHOULD notify all tenants in its local trust registry that have an active trust relationship with the revoked agent or its tenant. The notification mechanism is transport-agnostic: HTTP webhooks, message queues, event streams, or any reliable delivery channel.

The notification payload contains: revocation type (anchor, agent, or tenant), the revoked identifier, reason code, the AI-REV.1 anchor fingerprint as proof, and the revoking tenant. If a signing key is registered with the receiving party, the payload SHOULD be signed using the same HMAC pattern as credential signing.

Notifications are fire-and-forget. Delivery failure does not block local revocation. The freshness window remains the ultimate backstop.

12.5 Notification Witnessing (RECOMMENDED)

When implemented, revocation notifications SHOULD produce a three-anchor evidence chain:

This evidence chain is independently verifiable by any auditor, Notified Body, or C3PAO without access to the notification transport or either party's internal systems. Under EU AI Act Art. 9, notification of affected parties is a risk mitigation measure; the anchor chain is the evidence.

13. Security Properties

14. Registry Configuration

The TrustRegistry exposes configuration methods beyond the core trust/deny operations documented in Section 7. These control verification behavior at the registry level.

Python equivalents use snake_case: set_freshness_window, set_require_signature, etc. All methods are available in both TypeScript and Python implementations.

15. Implementations

All implementations maintain cross-language parity on the credential signing formula and trust level evaluation logic.

The SWT3 SDK is available in 10 languages (Python, TypeScript, Go, Rust, C#, Ruby, Swift, Kotlin, MCP Server, K8s Agent), but the Trust Mesh (TrustRegistry, credential exchange, liveness) is currently implemented in Python and TypeScript only. The remaining languages provide core witnessing primitives (fingerprint, signing, types) without Trust Mesh capabilities. The MCP Server exposes Trust Mesh as two tools that LLMs can call autonomously (see Section 18).

Install:

pip install swt3-ai          # Python
npm install @tenova/swt3-ai  # TypeScript
npm install @tenova/swt3-mcp # MCP Server + Middleware

16. Relationship to Other Standards

SWT3 Spec v1.0

The Trust Mesh consumes anchors minted by the SWT3 witnessing pipeline. It does not require the full witnessing pipeline to operate; only the anchor fingerprint and metadata are needed.

Model Context Protocol (MCP)

The Trust Mesh integrates with MCP via the @tenova/swt3-mcp server. Tool execution is gated by chain verification and density policy. Any MCP server can adopt the Trust Mesh by verifying credentials before processing tool calls.

EU AI Act (Regulation 2024/1689)

The Trust Mesh provides evidence for Article 9 (risk management), Article 13 (transparency), and Article 15 (accuracy and robustness). Trust levels map to the risk-based approach: BASIC for minimal-risk agents, ATTESTED for high-risk, SOVEREIGN for critical infrastructure.

NIST AI RMF

Trust levels align with the Govern and Measure functions. Credential exchange supports the Map function (understanding AI system context). Chain verification supports Manage (monitoring and response).

17. Composition with Transport Witnessing

Trust Mesh and the SWT3 Witness Middleware serve different purposes and produce independent evidence streams. They are designed to work together.

The sequence is:

Agent A                          Agent B
  |                                |
  |-- present_credential() ------->|
  |                                |-- verify_trust(credential)
  |                                |   Mints AI-TRUST.1 + AI-TRUST.2
  |                                |
  |<-- TrustResult (granted) ------|
  |                                |
  |-- tool call ------------------>|
  |                                |-- tool handler executes
  |                                |   withSWT3() mints AI-TOOL.1
  |<-- tool response --------------|

The two evidence streams are independently verifiable. An assessor can confirm that (a) the counterpart was verified before the call, and (b) the call itself was witnessed. Neither depends on the other. If the trust verification fails, the tool call should not proceed, and no AI-TOOL.1 anchor is minted.

For implementation details, see the Implementation Guide and the Witness Middleware Guide.

18. MCP Tools

The SWT3 MCP Server (@tenova/swt3-mcp) exposes Trust Mesh as two tools that LLMs can call autonomously during a conversation. This enables AI agents to verify counterpart compliance without human intervention.

18.1 verify_agent_trust

Verifies a counterpart agent's trust credential. Mints AI-TRUST.1 (verification result) and AI-TRUST.2 (handshake evidence) anchors.

Returns: verification result (GRANTED or DENIED), trust level (0-4), denial reason if applicable, checks performed and passed, and the minted AI-TRUST.1 and AI-TRUST.2 anchor tokens.

18.2 present_trust_credential

Generates a trust credential for the current agent to send to a counterpart for verification. Read-only (no anchors minted).

Returns: a formatted credential containing agent_id, tenant_id, anchor_fingerprint, anchor_timestamp_ms, is_signed, and clearing_level. The counterpart passes these fields to their own verify_agent_trust tool.

For a complete MCP conversation flow with JSON-RPC examples, see the MCP Trust Mesh Guide.