Every agent framework ships communication. None of them ship trust. SWT3 Trust Propagation computes quantified, evidence-based trust scores between AI agents -- turning cryptographic witness history into automated clearing level decisions.
@tenova/swt3-ai) or PyPI (swt3-ai).
Who this is for: AI platform architects building multi-agent systems, CISOs evaluating agentic deployment risk, compliance officers governing agent-to-agent data flows, Notified Bodies assessing AI value chain responsibilities, and developers integrating trust decisions into MCP, A2A, or custom agent frameworks.
CRITICAL ASSESSOR NOTICE: SWT3 witness anchors record that a governance event occurred and capture its computational factors. They do not replace assessor judgment. The assessor must independently verify that the substance of each trust control implementation meets the requirements of the applicable framework. Anchors provide the evidence trail -- the assessor determines whether that evidence is sufficient.
The agentic AI landscape is accelerating. Google shipped A2A for agent-to-agent communication. Anthropic shipped MCP for agent-to-tool access. Microsoft, LangChain, CrewAI, and AutoGen all provide frameworks for building multi-agent systems. Every one of these frameworks solves communication. None of them solve trust.
The question every CISO asks: When Agent A needs to share patient data, financial records, or classified information with Agent B, how does Agent A know Agent B is safe? Today, the answer is one of three things:
None of these approaches are auditable. None produce evidence. None satisfy EU AI Act Art. 25 (value chain responsibilities), NIST AI RMF GOVERN 1.4 (proportional access controls), or any regulatory framework that requires documented trust decisions in AI system interactions.
What Trust Propagation provides: A quantified trust score (0.0 to 1.0) for any agent, computed from that agent's cryptographic witness anchor history. Not self-reported ratings. Not reputation votes. Verifiable transaction records that already exist in the SWT3 ledger.
The score maps directly to clearing levels, automating the decision of what data sensitivity tier an agent qualifies for. The trust assertion itself is recorded as an immutable witness anchor (AI-TRUST.3), creating an auditable chain of trust decisions that satisfies regulatory evidence requirements.
Trust Propagation reads an agent's transaction history from the sovereign witness ledger and computes a trust score. Every witnessed interaction -- inference calls, tool executions, guardrail checks, RAG retrievals, revocations -- contributes to the score. The more an agent transacts without incident, the higher its trust.
Every time an agent performs a witnessed operation through SWT3, an anchor is minted. These anchors contain:
Trust Propagation aggregates this history into a single score. No new data collection is required -- the scoring engine reads evidence that already exists.
The score tells an agent or operator: "Based on 847 verified transactions over 14 months with zero revocations and interactions with 12 distinct counterparties, this agent is recommended for Clearing Level 3 (Classified) data access."
The trust score is computed from five inputs, each derived from the agent's witness anchor history:
| Input | What It Measures | Effect on Score |
|---|---|---|
| Reliability | Pass rate across all operational transactions | Primary factor. Higher pass rate = higher score. New agents start at a neutral midpoint rather than full trust (see Cold Start Behavior below). |
| Recency | Time since last transaction | Scores decay over time. Prolonged inactivity reduces the score. Active agents maintain full credit. |
| Revocations | Number and severity of revocation events | Each revocation reduces the score. Severity depends on reason: an error correction is minor; a regulatory order is severe. |
| Credentials | Whether the agent holds a valid W3C Verifiable Credential | Small positive bonus for agents with verified credentials. |
| Diversity | Number of distinct counterparties and procedure types | Sybil resistance gate. Agents that only transact with themselves or only use one procedure type are capped. |
The score includes a confidence indicator based on transaction volume:
Consumers of trust scores should factor confidence into their decisions. A score of 0.8 with high confidence is more actionable than 0.9 with low confidence.
A trust score that can be gamed is worse than no trust score at all. A common attack against reputation systems is the Sybil attack: creating many fake identities to inflate your own reputation. In an agent context, this means spinning up hundreds of dummy agents that do nothing but transact with each other to manufacture a perfect track record. Trust Propagation includes two diversity gates that detect and prevent this:
An agent must have transacted with a minimum number of distinct counterparty agents to qualify for higher trust tiers. An agent that creates 1,000 sock puppet agents and transacts only with itself cannot exceed the diversity cap.
Verify that the counterparty count in the trust score basis reflects genuine distinct agents, not aliases or synthetic identities within the same tenant.
An agent must have used multiple distinct procedure types (e.g., AI-INF.1 and AI-TOOL.1) to qualify for higher trust tiers. An agent that only generates inference anchors over and over cannot build full trust -- it must demonstrate breadth of governed behavior.
Procedure diversity confirms the agent operates under governance across multiple capability domains, not just a single repeated action.
What score should a brand-new agent receive? If it starts at full trust, unproven agents get access they haven't earned. If it starts at zero, new agents can never get started. Trust Propagation uses a smoothing technique to solve this: the scoring formula assumes a small number of prior transactions at a balanced pass rate. The practical effect is that every new agent starts at a neutral midpoint -- enough to begin transacting and building real history, but not enough for sensitive or classified data access. As real transactions accumulate, the prior becomes insignificant and the score reflects actual behavior.
The trust score maps directly to SWT3 clearing levels, automating the most common trust decision in multi-agent deployments: "What data sensitivity can this agent handle?"
| Trust Score Range | Clearing Level | Data Access |
|---|---|---|
| Low | L0 (Analytics) | Non-sensitive operational data only |
| Below diversity threshold | L1 (Standard) | Standard business data, hashed PII |
| Above diversity threshold | L2 (Sensitive) | PII, financial records, health data |
| High confidence, sustained history | L3 (Classified) | Classified, regulated, or restricted data |
This eliminates the manual access control matrix. Instead of a human deciding "Agent B is allowed to see patient records," the protocol computes it from verified transaction history. The decision is auditable, reproducible, and backed by cryptographic evidence.
Key distinction: The trust score recommends a clearing level. The clearing engine enforces it. These are separate protocol layers. An operator can override the recommendation by setting explicit clearing level caps per agent, per tenant, or per procedure. Trust Propagation automates the input; it does not bypass governance.
When Agent A has never transacted with Agent C, but both have transacted with Agent B, Trust Propagation can compute a transitive score:
A configurable decay factor ensures transitive trust is always lower than direct trust. The resulting transitive score typically qualifies for standard data access, but Agent A would need direct transaction history with Agent C to reach sensitive or classified tiers.
If the intermediary agent (B) has revoked the target agent (C), the transitive path returns zero regardless of individual scores. This prevents a compromised or malicious agent from maintaining trust through intermediaries that have already flagged it.
The revocation signal propagates through the trust graph without requiring a central authority to broadcast it. Each agent computes its own scores from its own ledger data.
Trust Propagation builds on two existing SWT3 procedures and adds a third:
Records the result of verifying a counterpart agent's compliance posture. Captures the granted trust level (0=denied through 4=sovereign). This is the binary "are you trusted?" check.
Records the handshake evidence when one agent presents its credentials to another. Captures checks performed, checks passed, and grant/deny outcome.
Records a quantified trust score as immutable evidence. When an agent asserts trust in another agent, the computed score is anchored with:
factor_a -- number of operational transactions evaluatedfactor_b -- number of transactions with PASS verdictfactor_c -- trust score multiplied by 1000 for integer encodingAI-TRUST.3 anchors are excluded from the scoring formula to prevent feedback loops. Trust assertions are evidence, not operational transactions.
AI-TRUST.3 anchors provide a complete audit trail of trust decisions. The basis field in the trust score response documents the exact inputs: transaction count, revocation count, history duration, and counterparty count. This satisfies EU AI Act Art. 25 documentation requirements for value chain responsibilities.
AI-TRUST.1 answers "is this agent trusted?" (binary gate). AI-TRUST.2 records the credential exchange (handshake evidence). AI-TRUST.3 quantifies "how much do I trust this agent?" (scored assessment). In a typical multi-agent interaction:
queryTrust("agent-b") to get Agent B's trust scoreverifyTrust(credential) to perform the credential handshake (AI-TRUST.1 + AI-TRUST.2)assertTrust("agent-b") to record the trust decision as an immutable anchor (AI-TRUST.3)Trust Propagation addresses specific requirements across multiple regulatory frameworks:
| Framework | Requirement | How Trust Propagation Satisfies It |
|---|---|---|
| EU AI Act Art. 25 | Value chain responsibilities must be documented | AI-TRUST.3 anchors record every trust decision between agents with quantified scores and evidence basis |
| NIST AI RMF GOVERN 1.4 | Risk-proportional access controls | Trust scores automatically map to clearing levels, enforcing data sensitivity access proportional to demonstrated reliability |
| ISO 42001 A.6.2.6 | AI system interaction controls | Trust verification and assertion procedures provide auditable controls for inter-system interactions |
| OWASP Agentic Top 10 | MCP-07: Agent identity and trust | Quantified trust scoring with Sybil resistance addresses the agent impersonation and trust exploitation risks |
| NIS-2 Art. 21(2)(j) | Supply chain security | Transitive trust with negative propagation creates a supply chain risk signal that flows through the agent network |
| Five Eyes Agentic FE-3 | Multi-agent coordination trust | Trust propagation provides the quantified trust framework for agent coordination in Five Eyes member deployments |
| Approach | Trust Basis | Auditable | Sybil Resistant | Regulatory Evidence |
|---|---|---|---|---|
| API Key (allow/deny) | Developer decision | No | No | No |
| OAuth Scopes | Permission grants | Partial | N/A | No |
| Reputation Voting | Self-reported ratings | No | No | No |
| Blockchain Reputation | Token stakes | Yes | Partial (cost-based) | No |
| PGP Web of Trust | Manual key signing | Yes | Partial | No |
| SWT3 Trust Propagation | Cryptographic witness history | Yes | Yes (diversity gates) | Yes (AI-TRUST.3 anchors) |
The differentiator is the evidence source. Every other system relies on self-reported data (ratings, stakes, manual signatures). SWT3 Trust Propagation derives scores from the same cryptographic witness anchors that prove compliance with 279 procedures across 81 frameworks. The trust score is a byproduct of governance, not a separate system bolted on afterward.
queryTrust() and assertTrust()