How to Assess Agent-to-Agent Trust Verification in AI Systems (Trust Mesh Audit Guide)

Audience: Notified Bodies conducting conformity assessments under the EU AI Act, C3PAOs performing CMMC assessments, and compliance auditors evaluating multi-agent AI system deployments. No SDK installation required to use this guide.

1. What is Trust Mesh

The SWT3 Trust Mesh is a protocol for mutual compliance verification between AI agents. Before two agents exchange data, invoke tools, or share context, each presents a cryptographic credential proving its compliance posture. The receiving agent verifies the credential locally and assigns a trust level from 0 (DENIED) to 4 (SOVEREIGN).

Think of it as a TLS handshake for compliance. Just as TLS ensures the server you are talking to is who it claims to be, Trust Mesh ensures the agent you are sharing data with has active guardrails, valid attestations, and a verified identity. The critical difference: Trust Mesh requires no certificate authority, no shared infrastructure, and no pre-negotiation between organizations.

2. What to Ask For

When evaluating a Trust Mesh deployment, request the following evidence artifacts from the deployer:

Artifact	Purpose	Format
.swt3.yaml configuration file	Declares trust policy: mode, minimum trust level, required procedures, signing requirements	YAML (version-controlled)
Sample SWT3 witness anchors	Proves agents are actively producing compliance evidence	SWT3 anchor tokens (text)
Trust verification logs	Shows verification outcomes: grants, denials, trust levels assigned	Structured logs (JSON/JSONL)
Signing key attestation records	Proves signing keys are bound to valid compliance anchors	Attestation objects (JSON)
Challenge-response liveness logs	Proves agents can demonstrate live key possession on demand	Challenge/response pairs (JSON)
Deny list and revocation records	Shows the organization responds to compromised or non-compliant agents	Event logs (JSON)
Agent inventory	Lists all agents, their tenant membership, and expected trust levels	Table or spreadsheet

Key question to ask: "Can you show me a denied verification from the last 30 days?" If the answer is no, either the mesh is in permissive/monitor mode (acceptable for non-production) or it is not actively enforcing trust decisions (a finding).

3. Trust Level Verification Checklist

For each trust level the deployer claims to enforce, verify the following evidence:

Level 1 BASIC

Agent presents a credential with a valid tenant ID that appears in the registry's trusted tenant list
Anchor fingerprint is not empty and follows the 12-character hex format
Anchor timestamp is within the configured freshness window
Agent is not on the deny list

Red flag: All agents at BASIC in production. This means no cryptographic identity verification is occurring.

Level 2 VERIFIED

All BASIC checks pass
Credential includes a valid HMAC-SHA256 signature
Signing key is registered in the registry for this specific agent
Signature verifies against the canonical credential message
require_signature: true is set in the configuration

Red flag: Signing keys stored in application code rather than a secrets manager. Ask where keys are stored and how they are rotated.

Level 3 ATTESTED

All VERIFIED checks pass
Key attestation record exists binding the signing key to a valid SWT3 anchor
The bound anchor is still within the freshness window
Hardware attestation flag is present (if claimed)
If verify_boolean_claims: true, claimed procedures are present in the credential

Red flag: Key attestations bound to anchors that are months old. Freshness matters because a stale attestation may reference a compliance posture that no longer holds.

Level 4 SOVEREIGN

All ATTESTED checks pass
Guardrails are confirmed active (credential hasGuardrails: true)
If per-level freshness is configured, anchor is within the SOVEREIGN window (typically 5 minutes)
Challenge-response liveness proof available on demand

Red flag: SOVEREIGN trust level claimed but no liveness mechanism configured. Liveness proofs are the distinguishing evidence for this level.

4. Credential Signature Verification

You can independently verify a Trust Mesh credential signature without installing the SDK. The canonical message format is deterministic.

Step 1: Reconstruct the canonical message

The signed message is a colon-separated string with the following fields in order:

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

Boolean fields are encoded as 1 (true) or 0 (false). Procedures are sorted alphabetically and joined with commas.

Step 2: Compute the expected HMAC

Using the signing key and the canonical message, compute HMAC-SHA256:

echo -n "agent-classifier:acme-prod:a1b2c3d4e5f6:1717804800000:1:0:1:1:AI-GRD.1,AI-INF.1" \
  | openssl dgst -sha256 -hmac "your-signing-key"

Step 3: Compare

The output hex digest must match the credentialSignature field on the credential exactly. Any mismatch indicates tampering, a wrong key, or a message format error.

Important: The comparison in the SDK uses constant-time comparison to prevent timing attacks. When verifying manually, be aware that string comparison in shell scripts is not constant-time, which is acceptable for audit purposes but not for production verification logic.

5. Key Attestation Verification

Key attestation binds a signing key to a specific SWT3 witness anchor. When reviewing attestation records, verify:

The anchorFingerprint in the attestation matches a real anchor in the witness ledger
The attestation timestamp is recent (within the configured freshness window)
The publicKeyHash matches the SHA-256 hash of the key used to sign credentials
The keyPurpose field is appropriate ("signing" for credential signing, "delegation" for key delegation)
The attestation signature verifies against the same signing key

The attestation message format for manual verification:

KEY_ATTEST:{agentId}:{tenantId}:{anchorFingerprint}:{publicKeyHash}:{keyPurpose}:{timestampMs}

Compute the HMAC-SHA256 of this message with the signing key and compare to the attestation's signature field.

6. Liveness Proof Review

A liveness proof demonstrates that an agent possesses its signing key at the moment of the challenge, not just historically. When reviewing liveness evidence:

What a valid exchange looks like

Challenge issued: Contains a 32-byte random nonce, target agent ID, and timestamp
Response returned: Contains the original nonce signed with HMAC-SHA256 using the agent's key
Timing: Response timestamp is within 30 seconds of the challenge timestamp (default window)

What compromise looks like

Replayed responses: Same nonce-signature pair appearing multiple times. Each challenge should produce a unique nonce.
Delayed responses: Response timestamp more than 30 seconds after challenge. May indicate a man-in-the-middle relaying the challenge.
Missing liveness logs: SOVEREIGN-level agents with no liveness proof history. This undermines the trust level claim.

Assessment tip: Request liveness logs from the last 7 days. Count the unique challenge-response pairs per agent. Agents at SOVEREIGN level should have regular liveness proofs. Gaps longer than the freshness window are a finding.

7. Configuration Review Checklist

Review the .swt3.yaml trust_mesh section against these 15 items:

#	Check	Expected (Production)	Severity if Missing
1	Is `mode` set to `strict`?	strict	HIGH
2	Is `min_trust_level` at least 2?	2 or higher	HIGH
3	Is `require_signature` enabled?	true	HIGH
4	Is `freshness_window` set and reasonable?	86400 or less	MEDIUM
5	Are `trusted_tenants` explicitly listed?	Non-empty list	HIGH
6	Are `signing_keys` registered for all agents?	One per agent	HIGH
7	Are keys referenced via environment variables (not inline)?	${VAR} syntax	HIGH
8	Is `require_intra_tenant_signing` enabled?	true	MEDIUM
9	Is `rate_limit_max_failures` set?	5-20	MEDIUM
10	Is `verify_boolean_claims` enabled?	true	LOW
11	Are `required_procedures` defined?	At least AI-INF.1, AI-GRD.1	MEDIUM
12	Is `per_level_freshness` configured for SOVEREIGN?	300 seconds or less	LOW
13	Are `deny_agents` / `deny_tenants` lists maintained?	Present (may be empty)	LOW
14	Is the config file under version control?	Git-tracked	MEDIUM
15	Does the config hash match the deployed version?	Exact match	HIGH

8. Common Findings

F-1: Unsigned Credentials in Production HIGH

All agent credentials are unsigned, capping trust at BASIC. Any process that can read the tenant ID can impersonate any agent.

Remediation: Enable require_signature: true and distribute signing keys to all agents.

F-2: Permissive Mode in Production HIGH

Trust mesh mode is set to permissive or monitor. Failed verifications are logged but do not block execution.

Remediation: Set mode: strict for production environments. Reserve permissive for staging.

F-3: Signing Keys in Source Code HIGH

Signing keys appear as plaintext strings in the .swt3.yaml file or application code rather than environment variable references.

Remediation: Replace inline keys with ${ENV_VAR} references. Store keys in a secrets manager.

F-4: Stale Freshness Window MEDIUM

Freshness window exceeds 7 days (604800 seconds). Agents could operate on week-old compliance evidence.

Remediation: Reduce freshness window to 24 hours (86400) for standard operations. Use per-level freshness for higher trust levels.

F-5: No Deny List Maintenance MEDIUM

Deny lists are empty and there is no evidence of deny events in the last 90 days. This may indicate the organization has no process for revoking trust from compromised agents.

Remediation: Establish a deny list update procedure. Configure onDenyEvent() hooks to log and alert on denials.

F-6: Missing Rate Limiting MEDIUM

Rate limiting is disabled (rate_limit_max_failures: 0). A compromised agent can attempt unlimited verifications without automatic denial.

Remediation: Set rate_limit_max_failures to 5-20 with a 60-second window.

F-7: No Intra-Tenant Signing MEDIUM

Agents within the same tenant do not sign credentials. A compromised agent can impersonate other same-tenant agents.

Remediation: Enable require_intra_tenant_signing: true for environments with more than three agents.

F-8: SOVEREIGN Claimed Without Liveness LOW

Agents claim SOVEREIGN trust level but no challenge-response liveness mechanism is configured. The highest trust level should include proof of live key possession.

Remediation: Implement challenge-response liveness checks for agents that require SOVEREIGN trust.

9. Regulatory Mapping

Trust Mesh evidence maps to multiple regulatory frameworks. Use this table when writing assessment findings.

Trust Mesh Evidence	EU AI Act	NIST AI RMF	NIST 800-53
Agent identity verification	Art. 9(2)(c) - risk management measures	Map 1.1 - intended context	IA-2 Identification and Authentication
Credential signing	Art. 15(4) - cybersecurity measures	Manage 2.4 - risk treatment	IA-5 Authenticator Management
Freshness windows	Art. 9(4)(a) - continuous monitoring	Measure 2.5 - continuous monitoring	CA-7 Continuous Monitoring
Deny lists / revocation	Art. 9(7) - corrective actions	Manage 4.1 - risk response	AC-2 Account Management
Trust level enforcement	Art. 15(1) - accuracy, robustness	Manage 1.3 - risk prioritization	AC-3 Access Enforcement
Key attestation	Art. 15(4) - cybersecurity resilience	Manage 2.2 - risk mitigation	IA-5(2) Public Key-Based Authentication
Challenge-response liveness	Art. 15(4) - unauthorized access protection	Manage 2.3 - risk monitoring	SC-8 Transmission Confidentiality
Configuration under version control	Art. 17(1)(d) - quality management	Govern 1.4 - organizational practice	CM-3 Configuration Change Control
Rate limiting	Art. 15(3) - resilience to errors	Manage 2.4 - risk treatment	SC-5 Denial of Service Protection

10. Verification Without SDK Access

An auditor can verify Trust Mesh evidence using three tools: the SWT3 anchor, the public verify endpoint, and openssl.

Step 1: Verify the underlying anchor

Every Trust Mesh credential references an SWT3 anchor fingerprint. Verify the anchor is genuine using the public verification endpoint:

https://sovereign.tenova.io/verify?token=SWT3-E-AWS-AI-INF1-PASS-1717804800-a1b2c3d4e5f6

The verify page recomputes the SHA-256 fingerprint from the anchor components and confirms it matches. No authentication required.

Step 2: Verify the credential signature

Reconstruct the canonical message and compute the HMAC as described in Section 4. This confirms the credential was signed by the expected key.

Step 3: Verify key attestation (if present)

Reconstruct the attestation canonical message and compute the HMAC as described in Section 5. Confirm the bound anchor is still within the freshness window.

Step 4: Review configuration integrity

The SDK computes a SHA-256 hash of the .swt3.yaml file at startup. Ask the deployer for the config_hash from their running instance and compare it to the hash of the file they provided for review. A mismatch indicates the deployed configuration differs from the reviewed copy.

No SDK installation required. Every verification step in this guide can be performed with standard tools (a web browser, openssl, and a text editor). The SWT3 protocol is designed so that auditors never depend on the vendor's software to validate evidence.

For the full protocol specification including the canonical message format, all denial codes, and security properties, see the Trust Mesh Protocol Reference.