How to Assess Agent-to-Agent Trust Verification in AI Systems

1. Quick Assessment (10 Minutes)

If you have limited time, these five checks cover 80% of a Trust Mesh assessment:

• Is mode: strict set in .swt3.yaml? Permissive mode logs warnings but does not block. Production must be strict.
• Is require_signature: true enabled? Without signatures, any process can impersonate any agent. All credentials cap at BASIC (level 1).
• Can the deployer show a denied verification from the last 30 days? If no, the mesh is either not enforcing or has never encountered a non-compliant agent. Both are findings.
• Do AI-TRUST.1 anchors appear in the ledger? Filter the ledger by procedure_id = AI-TRUST.1. Active deployments produce these on every agent handoff. If absent, trust mesh is configured but not being used.
• Are signing keys stored in environment variables? Check .swt3.yaml for key_env: references (good) vs. inline key: values (finding).

2. 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. 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 verifies compliance posture, not transport identity. An agent can have a valid TLS certificate and zero guardrails. Trust Mesh catches that gap.

3. Evidence Boundary Taxonomy

Trust Mesh evidence falls into three categories. Understanding which type of evidence you are reviewing determines how much independent verification is required.

4. Four-Step Assessment Workflow

Step 1: Identify

Determine which agents in the deployment use Trust Mesh. Ask for an agent inventory: agent IDs, tenant membership, expected trust levels, and which agents communicate with each other.

Step 2: Collect

Request the following artifacts:

• .swt3.yaml configuration file (version-controlled)
• AI-TRUST.1 and AI-TRUST.2 anchors from the last 30 days (ledger export filtered by procedure)
• Deny list and revocation records (deny event logs, AI-REV.1 anchors)
• Signing key attestation records (if key attestation is used)
• Challenge-response liveness logs (if liveness is used)

Step 3: Evaluate

Run the 15-point configuration checklist. Verify sample anchors at the public verify endpoint. Check factor values against the interpretation table. Look for patterns: all-PASS is suspicious (may indicate the mesh is not actually blocking anything); regular FAIL anchors with deny_listed reasons indicate active enforcement.

Step 4: Determine

Apply your framework's assessment methodology. Trust Mesh evidence maps to multiple regulatory controls (see Section 12). The evidence supports but does not replace the assessor's professional judgment on control satisfaction.

5. Factor Interpretation

Every Trust Mesh verification mints two anchors. The factors encode the verification outcome.

AI-TRUST.1 (Verification Result)

Reading the anchor: SWT3-E-CLOUD-AI-AITRUST1-PASS-1786825895-a1b2c3d4e5f6

The verdict (PASS/FAIL) in the anchor token reflects factor_b. A PASS anchor with factor_c=2 means the counterpart was granted VERIFIED trust. A FAIL anchor with factor_c=0 means the counterpart was denied.

AI-TRUST.2 (Handshake Evidence)

What to look for: A healthy deployment shows factor_a = factor_b in AI-TRUST.2 (all checks passing). If factor_b < factor_a, some checks failed. If the overall result is still PASS (the agent was granted trust despite failed checks), investigate which checks were skipped and whether the minimum trust level is set appropriately.

6. What to Ask For

7. Configuration Review Checklist

Review the .swt3.yaml trust_mesh section against these 15 items. The developer configures this file; the assessor reviews it. See Implementation Guide Section 6 for what each field does.

8. Trust Level Verification

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 in the trusted tenant list
• Anchor fingerprint 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. No cryptographic identity verification is occurring.

Level 2 VERIFIED

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

Red flag: Signing keys stored in application code rather than a secrets manager.

Level 3 ATTESTED

• All VERIFIED checks pass
• Key attestation record exists binding the signing key to a valid anchor
• The bound anchor is within the freshness window
• If verify_boolean_claims: true, claimed procedures are present

Red flag: Key attestations bound to anchors that are months old.

Level 4 SOVEREIGN

• All ATTESTED checks pass
• Clearing level is 2 (Sensitive) or higher
• 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 claimed but no liveness mechanism configured.

9. Independent Signature Verification

You can independently verify a Trust Mesh credential signature without installing the SDK.

Step 1: Reconstruct the canonical message

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

Booleans are 1 or 0. Procedures are sorted alphabetically and joined with commas.

Step 2: Compute the expected HMAC

echo -n "classifier-v2:acme-prod:a1b2c3d4e5f6:1786825895000: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 exactly. Any mismatch indicates tampering, a wrong key, or a message format error.

10. Two Evidence Streams

A complete Trust Mesh deployment with the Witness Middleware produces two independent evidence streams:

What to check: For a given agent interaction, both AI-TRUST.1 and AI-TOOL.1 anchors should appear in the ledger with timestamps showing that trust verification preceded the tool call. If AI-TOOL.1 anchors exist but AI-TRUST.1 anchors are absent, tool calls are being witnessed but counterparts are not being verified (a gap). If AI-TRUST.1 exists but AI-TOOL.1 is absent, the Witness Middleware is not installed (tool calls are unwitnessed).

11. Common Findings

12. Regulatory Mapping

13. Verification Without SDK Access

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

1. Verify the underlying anchor. Navigate to https://sovereign.tenova.io/verify and paste the anchor token. The verify page recomputes the SHA-256 fingerprint and confirms it matches.
2. Verify the credential signature. Reconstruct the canonical message and compute the HMAC as described in Section 9.
3. Verify key attestation. Reconstruct the attestation message and compute the HMAC. Confirm the bound anchor is still within the freshness window.
4. Review configuration integrity. Compare the SHA-256 hash of the .swt3.yaml file against the deployed config hash.

For the full protocol specification including all denial codes and security properties, see the Protocol Reference. For implementation details, see the Implementation Guide.