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?

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.

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 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

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. Revocation

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

10.1 Anchor Revocation

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

10.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.

10.3 Revocation Propagation

Cross-tenant revocation requires the revoking party to notify affected counterparts. The protocol does not define a broadcast mechanism; this is left to the deployment topology.

11. Security Properties

12. Implementations

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

Install:

pip install swt3-ai          # Python
npm install @tenova/swt3-ai  # TypeScript

13. 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).