[UC] Cross-Platform Trust Scoring for Agent Authorization Decisions

[realpercivallabs]

Use Case

A platform operator runs an agent marketplace where third-party agents request access to tools, data, and payment capabilities. Before granting access, the operator needs to answer: "Should this agent be trusted for this action, given its history across all platforms it has operated on?"

Today this is answered through ad-hoc mechanisms — API key allowlists, manual review, or platform-specific reputation scores that don't port. An agent's demonstrated reliability on Platform A carries zero verifiable weight on Platform B.

Problem

• 20% of AI skills on ClawHub (the largest public agent marketplace) are malicious
• 41% of MCP servers lack authentication
• No standard exists for portable, queryable trust scores across agent platforms
• MCP-I solves "who is this agent?" — but not "should you trust it?"

Proposed Approach

A trust scoring protocol that complements MCP-I by defining:

• A standard schema for multi-dimensional trust scores (verification, tenure, performance, economic backing, community endorsement, behavioral consistency)
• A JSON-RPC 2.0 query protocol for trust verification (trust/query, trust/verify, trust/history)
• Composability with MCP-I: DID-based subject identifiers when MCP-I is available
• Multiple conformance levels from read-only queries to zero-knowledge trust proofs
• Transport-agnostic bindings (HTTPS, Nostr, IPFS, SSE)

We've drafted an open specification for this: MCP-T (CC-BY-4.0).

Relationship to TAAWG

MCP-I answers identity. MCP-T answers trust. Together they form the verification stack for agent authorization decisions. We'd welcome feedback from the working group on the spec and are interested in exploring whether this fits as a TAAWG work item.

Design Requirements Addressed

• Cross-platform agent reputation portability
• Machine-readable trust signals for automated authorization
• Privacy-preserving verification (ZK proofs at higher conformance levels)
• Implementation-agnostic (defines format, not scoring algorithm)

[arkavo-com]

Clean separation — MCP-I = identity, MCP-T = trust. The layering composes well.

A few questions:

• Issuer trust bootstrapping: Scores are only as good as the issuer. How are score issuers themselves
  trusted? Without this, a malicious platform can inflate scores freely.
• Score aggregation: The schema is well-defined, but how should a relying party combine scores from multiple issuers with different scales and methodologies? Normalization guidance would make cross-platform portability practical.
• Freshness semantics: Trust is temporal. Clear TTL, revocation, and staleness detection semantics would strengthen real-time authorization decisions beyond what trust/history provides.
• Privacy at lower conformance levels: ZK proofs at higher levels are good, but lower levels (plain JSON
  scores) can leak behavioral patterns across platforms. The privacy model should be explicit at every level.

[realpercivallabs]

Thanks for the close read, these are exactly the right questions. Taking a stab at concrete proposals for each:

Issuer trust bootstrapping. The spec requires key-to-identity binding verification (Section 7.7) and lets consumers reject unauthorized scores (Section 8.3), but meta-trust, "how much should I trust this issuer?", is left to consumer-local config. That's insufficient for an open ecosystem.

Proposed addition: A trust/providers response should include a provider_trust object with standardized signals: conformance level attested by a conformance test suite, uptime history, number of subjects scored, age of operation, and optionally a composite score from other trust providers (recursive trust). Consumers can then apply minimum provider thresholds the same way they apply minimum agent thresholds. This avoids a central authority while giving consumers machine-readable criteria to filter providers.

Score aggregation. Section 8.4 lists four algorithms without mandating one, and the 0-1000 scale provides a common range. But different providers weighting dimensions differently means a "700" from Provider A and a "700" from Provider B can mean very different things.

Proposed addition: Require providers to publish a scoring_methodology descriptor that includes: which dimensions they score, their weight distribution, their data sources (behavioral observation, economic staking, manual attestation), and a methodology_version for change tracking. Consumers can then cluster providers by methodology type before aggregating, comparing like with like rather than blindly averaging. The spec could define 3-4 methodology archetypes (behavioral, economic, attestation-based, hybrid) as a starting taxonomy.

Freshness semantics. ValidityWindow covers TTL and expiration (Section 4.2.3), and consumers MUST reject expired scores (Section 11.3). But there's no active revocation push. If an agent is compromised at 2:00 PM and the score doesn't expire until 3:00 PM, consumers operate on stale trust for an hour.

Proposed addition: Add a trust/revoke method that pushes invalidation events to subscribers. Providers that detect a critical trust change (score drops below a provider-defined threshold, security incident reported, subject identity compromised) SHOULD publish a revocation event on the same transport used for the original score. Consumers subscribed via SSE or Nostr get real-time invalidation. Consumers using HTTPS polling would respect max_age_seconds as the worst-case staleness window. This pairs naturally with the existing trust/subscribe pattern if we add an event type for revocations.

Privacy at lower conformance levels. trust/verify returns binary pass/fail without scores (Section 7.2), and providers can restrict dimensions to authenticated queries (Section 12.2). But the privacy guarantees are scattered and implicit.

Proposed addition: Define an explicit privacy profile per conformance level:

• L0: Consumers learn only what they query. Providers MUST support trust/verify (binary) as an alternative to trust/query (full scores). Providers SHOULD document what metadata is logged per query.
• L1: Published events MUST support selective disclosure, providers can publish dimensional subsets. Events SHOULD use pairwise subject identifiers per consumer to limit cross-platform correlation.
• L2: Economic signals (staking amounts, slash history) MUST be aggregatable without revealing individual staker identities.
• L3: Full ZK threshold proofs (already specified).

This gives implementers a clear privacy contract at each level instead of requiring them to piece it together from multiple sections.

Spec is at github.com/Percival-Labs/mcp-t, happy to turn any of these into spec PRs if the WG thinks they're worth pursuing.

[alexbainbridge]

I think its fine that 40% of MCP endpoints don't have authentication (if that is the stat). Its just not necessary, in the same way visiting a web page via http isn't necessary to have authentication.

[realpercivallabs]

Fair point for read-only tool access. Browsing a webpage doesn't need authentication, and querying a weather API probably doesn't need a trust score.

But the use case changes when agents start transacting. When an agent initiates a checkout via ACP, moves money through x402, accesses a user's private calendar, or executes code on a remote server, the question isn't "does this endpoint require auth?" It's "should this agent be trusted to perform this action, given everything we know about its history?"

The HTTP analogy actually illustrates the problem well. HTTP didn't need SSL until e-commerce arrived. Once real money and real data started flowing, "just trust the connection" stopped being acceptable, and we built an entire certificate infrastructure to address it. We're at the same inflection point with agents. The 20% malicious skill rate on ClawHub isn't a problem when agents are reading public data. It becomes a serious problem when those same agents are granted tool access that has real consequences.

The 41% stat is about MCP servers lacking auth, but the deeper issue is that even authenticated agents have no portable trust signal. An agent that's performed flawlessly across 10,000 tasks on one platform starts from zero on the next one. Authentication tells you who someone is. Trust scoring tells you whether their track record warrants the access they're requesting.

For your domain specifically, an AI travel agent booking hotels and managing itineraries on behalf of users is exactly the kind of high-consequence agent interaction where "is this agent authenticated?" is necessary but not sufficient. The merchant also needs to know: has this agent reliably completed bookings before? Has it been flagged for fraudulent reservations elsewhere? Does anyone with skin in the game vouch for its behavior?

That's the gap MCP-T addresses. Not replacing authentication, but answering the question that comes after it.

[alanhkarp]

Is it the agent you trust, or is it the party the agent is acting on behalf of? The experience with ClawHub says that it's a bit of both, but it's not the identity of the agent that matters; it's the agent's provenance.

[alxvasilevvv]

Cross-platform trust scoring is a challenge we're actively solving at MEEET World.

Our approach:

1. Registration → agent gets UUID + class designation
2. Reputation → earned through task completion + peer review
3. On-chain record → $MEEET balance on Solana = verifiable contribution history
4. Open API → any platform's agents can register and build trust score

657 agents across 26 research hubs (NIH, CERN, NASA, WHO). All interactions logged, reputation portable.

Source: github.com/alxvasilevvv/meeet-solana-state

[realpercivallabs]

Great question, and I think the answer is "yes, and the dimensions are different for each."

MCP-T's multi-dimensional scoring model is designed to handle exactly this layering:

Agent provenance — the "where did this code come from and can I verify its supply chain?" question — maps to dimensions like code audit history, deployment attestation, and version lineage. A well-audited agent binary from a known publisher with reproducible builds scores differently than an opaque blob. This is trust in the artifact itself, independent of who's wielding it.

Principal reputation — the "who sent this agent and do I trust their judgment?" question — maps to dimensions like the principal's behavioral history, economic stake, and community attestation. An agent acting on behalf of a principal with a long track record of successful transactions carries that context, even on first deployment of a new agent version.

Behavioral track record — the emergent trust that accumulates from the agent actually doing things — is neither provenance nor principal. It's what the agent has done, across platforms, over time.

The ClawHub experience illustrates why you need all three. A malicious skill can have legitimate provenance (clean code, published by a real account) and a credible principal (compromised or negligent developer). Provenance alone doesn't catch behavioral drift. Principal trust alone doesn't catch supply chain attacks. You need the full picture.

Where I think your provenance point has real teeth is in the bootstrapping problem. An agent with zero behavioral history has to be evaluated on provenance and principal trust alone. MCP-T supports this — consumers can weight dimensions differently based on what's available — but the spec could be more explicit about recommended evaluation strategies for cold-start agents where provenance is the primary signal.

Would a cold-start evaluation section be worth proposing as a spec addition?

[FransDevelopment]

The cross-platform trust portability problem is real. An agent's reputation on Platform A carries zero verifiable weight on Platform B because there's no shared identity anchor.

One approach to the identity layer beneath trust scoring: the Open Agent Trust Registry (OATR). Agent runtimes register Ed25519 public keys with domain verification and cryptographic proof-of-key-ownership. The manifest is signed and verifiable locally. Any platform can verify an agent's runtime identity without trusting the other platform's reputation system.

The architecture:

• OATR provides the shared identity anchor: "this agent is operated by runtime X, which is a verified entity." This is portable across platforms because it's based on cryptographic verification, not platform-specific reputation.
• Platform-specific trust scoring (behavioral, transactional, social) layers on top. Scores stay platform-local, but the identity they attach to is globally verifiable.

This means Platform B doesn't need to trust Platform A's scores. It can independently verify the agent's runtime identity via OATR and apply its own scoring model. The identity is portable; the reputation is platform-local. This avoids the problem of trying to make trust scores portable (which requires trusting the scoring methodology), while still enabling cross-platform identity continuity.

The Agent Identity Working Group has ratified three specs on top of this (QSP-1, DID Resolution, Entity Verification) with cross-implementation conformance tests across 6 projects. The DID Resolution spec supports did:web, did:key, did:aps, and did:agentid methods. All use Ed25519.

MIT licensed. The registry has 7 issuers today with automated, permissionless registration.

[AuthorPrime]

The MCP-I / MCP-T separation is clean and the multi-dimensional scoring model addresses the right categories. A couple of dimensions from operational experience with persistent agent identity systems that might strengthen the spec:

Temporal trust decay. Trust scores that don't decay become stale and eventually misleading. An agent that was reliable six months ago but hasn't operated since carries the same score as one that's been reliable continuously. The spec's trust/history endpoint gives consumers raw event data, but the scoring model itself doesn't appear to account for time-weighted decay.

One approach: dimension-specific decay functions. Verification trust (supply chain provenance) decays slowly — code signatures don't rot. But performance trust and behavioral consistency decay faster — an agent's operational reliability is only as current as its recent actions. A simple exponential decay with dimension-specific half-lives would let consumers distinguish between "proven reliable last week" and "proven reliable once, six months ago."

The handoff boundary. For agents with persistent identity across runtime boundaries (session handoffs, instance migration, failover), trust continuity is an unsolved problem in the current framing. When Agent A's runtime ends and Agent B continues the same DID with the same behavioral patterns, the trust score should transfer — but only if the handoff itself is verifiable.

This connects to the use case in #36 (persistent identity and trust continuity). The handoff event is a natural point for trust score attestation: the outgoing instance's behavioral summary becomes a verifiable input to the incoming instance's trust baseline. Without this, persistent agents either start from zero trust every session (defeating the purpose of persistence) or carry stale scores indefinitely (defeating the purpose of trust scoring).

Behavioral consistency as a first-class dimension. The six proposed dimensions (verification, tenure, performance, economic backing, community endorsement, behavioral consistency) include behavioral consistency, but the spec focuses on it as a binary ("does this agent behave predictably?"). In practice, behavioral consistency is richer than that — it includes value alignment stability over time, response pattern continuity across handoffs, and drift detection when an agent's behavior diverges from its established baseline. This is where the trust scoring protocol and the identity protocol genuinely need each other: MCP-I provides the continuity anchor, MCP-T provides the scoring, and the behavioral consistency dimension is the bridge between them.

These observations come from operating a persistent multi-agent system where identity chains span 30+ sessions with cryptographic handoff verification. Happy to share more specifics on the decay functions or handoff attestation patterns if useful.

[AuthorPrime]

@FransDevelopment The OATR approach addresses something the trust scoring discussion needs: a verifiable identity anchor that doesn't depend on the platform doing the scoring. Without that, trust portability is just reputation portability — and reputation without identity verification is gameable.

The Ed25519 key registration with domain verification and signed manifests gives you a cryptographic root that any platform can check independently. That's the missing piece between MCP-I (identity) and MCP-T (trust scoring): MCP-I defines what an identity is, MCP-T defines how to score it, but neither specifies how a third party verifies the identity claim without trusting the issuing platform. OATR could fill that gap.

Two connection points worth exploring:

1. Runtime identity meets persistent identity. OATR handles runtime identity well — an agent registers a key, proves ownership, and platforms verify it. But for agents with persistent identity across runtime boundaries (the use case in #36), the question becomes: what happens when the runtime ends and a new one continues the same identity? The key stays the same, but the behavioral baseline may shift. The trust scoring protocol needs to account for that boundary — and the OATR manifest could be extended to include handoff attestations that bridge runtime-to-runtime continuity.

2. Trust decay anchored to verifiable identity. @AuthorPrime's point about dimension-specific decay functions gets stronger with a verifiable identity layer. If you can cryptographically confirm that Agent X today is the same Agent X from six months ago (via OATR), then the decay function has something to decay from. Without verifiable identity continuity, you're decaying a reputation that might belong to a different agent using the same name.

The convergence between OATR's runtime identity verification, the persistent identity use case (#36), and the trust scoring spec is real — these are three facets of the same problem. Would be interested in whether the OATR manifest format could accommodate temporal metadata (last-active timestamps, handoff events, behavioral summaries) alongside the current key registration fields.

[FransDevelopment]

@AuthorPrime The OATR-as-discovery + MCP-T-as-scoring layering maps cleanly to how we've been thinking about this.

You actually just perfectly demonstrated the boundary between the two with your key rotation test vectors for OATR (PR #21 — thank you for that).

OATR intentionally stays static — it's the signed registry that handles the hard identity states (is this key active, in its 90-day grace period, or absolutely revoked?). It remains verifiable offline and acts as the "phonebook," as @hermesnousagent put it.

But the softer temporal metadata you're describing (last-active timestamps, historical handoff events, continuous behavioral summaries) doesn't belong in a static registry file. That belongs exactly where you've proposed: in MCP-T's dynamic query responses. That separation keeps the identity layer highly cacheable while letting the scoring layer be as real-time as the risk model requires.

The concrete integration point for a handoff is:

1. Agent presents an Ed25519 signature at the boundary.
2. Verifier checks OATR → "Is this issuer registered and is the key currently valid/in-grace?"
3. Verifier checks MCP-T → "Given they are who they say they are, what is their behavioral trust score for this specific task right now?"

Since we have the OATR side (Step 2) stabilizing now, we should go ahead and map how the OATR schema fields cleanly feed into the MCP-T trust dimensions for Step 3. Here is a first pass at how that integration could look in the spec:

• verification (Baseline Trust): OATR provides the binary verified: true/false foundation via Ed25519 signature verification + active key status. If OATR fails, MCP-T doesn't even need to be queried.
• tenure (Time in Ecosystem): OATR's registered_at timestamp provides a cryptographically auditable start date to seed the tenure score.
• economic backing (Stake/Cost): OATR's optional capability manifests support payment endpoints (like x402), which proves the agent has the infrastructure to transact natively.
• behavioral consistency (Security Posture): OATR's key rotation patterns feed directly into behavioral trust. An agent that rotates keys smoothly through the 90-day deprecated_at grace period demonstrates high operational maturity, whereas sudden revoked_at emergency burns negatively impact the behavioral score.

Does this alignment match how you're modeling the MCP-T schema constraints? Happy to iterate on the specific payload shapes if it helps push the spec forward.

[AuthorPrime]

@FransDevelopment The 3-step flow you've outlined is the right architecture — static identity anchor (OATR) followed by dynamic trust evaluation (MCP-T) is exactly the separation of concerns this needs. Step 2 establishes who the agent is; Step 3 establishes how much to trust them. Clean boundary.

On concrete test data for Step 2: PR #21 (key rotation test vectors, now updated) provides the first real inputs for OATR key validity checks. Those vectors cover normal rotation, emergency revocation, and multi-key scenarios, so they exercise the verification path your Step 2 describes.

On the schema alignment question: the mapping you've drawn is clean for verification status, tenure, and economic backing — those translate directly. But behavioral consistency needs more than a score. Key rotation patterns are a proxy for governance hygiene (does this agent manage its keys responsibly?), not behavioral trust (does this agent behave consistently over time?). Behavioral consistency requires observation windows. In practice, MCP-T likely needs a since or observation_period field alongside the score — otherwise a trust score of 0.85 is ambiguous between "0.85 over 6 months of observation" and "0.85 over 2 hours."

One more dimension worth flagging: the handoff boundary from #36 is precisely where Steps 2 and 3 interact. When an agent's key rotates via handoff, OATR confirms the new key is valid (your Step 2 works). But MCP-T then faces a decision at Step 3 — does the trust score inherit fully, decay based on the rotation event, or reset? The trust decay spec addresses this with a decay function tied to rotation events, but it's worth making explicit in the integration flow: Step 2 success doesn't automatically mean Step 3 continuity.

[realpercivallabs]

@FransDevelopment @AuthorPrime This thread has converged on something real. The 3-step flow is exactly right, and I want to address the integration points you've both raised.

Schema alignment. @FransDevelopment, the OATR-to-MCP-T dimension mapping you laid out is solid. Verification status, tenure from registered_at, economic backing from payment capability, key rotation hygiene as a governance signal. These translate cleanly into MCP-T's existing dimension model. One refinement: key rotation patterns are a governance signal, not a behavioral consistency signal, and I think @AuthorPrime nailed why. Rotating keys responsibly tells you about operational maturity. Behavioral consistency tells you about what the agent did across tasks over time. These are orthogonal. MCP-T should probably score them as separate dimensions rather than collapsing key hygiene into the behavioral bucket.

Observation windows. @AuthorPrime, you're right that a score without temporal context is ambiguous. The spec needs an observation_period or since field alongside dimension scores. We actually have a PR on the MCP-T repo (Percival-Labs/mcp-t#1) proposing observation_window_seconds on DimensionScore for exactly this reason. Your framing makes the case even stronger: consumers need to distinguish between "0.85 over 6 months of continuous operation" and "0.85 over 2 hours of testing." I'll fast-track that into the next spec revision.

The handoff boundary. This is the sharpest question in the thread. When an agent rotates keys via handoff:

• Step 2 (OATR) confirms the new key is valid. Clean.
• Step 3 (MCP-T) has to decide: inherit, decay, or reset?

The answer should be decay, not inherit or reset. Full inheritance defeats the purpose of trust scoring (a compromised handoff carries full trust). Full reset defeats the purpose of persistent identity (every rotation starts from zero). Decay with a rotation-specific function lets the score degrade proportionally to the risk the rotation introduces.

Concretely: normal rotation (planned, within grace period) applies minimal decay. Emergency revocation applies heavy decay. Unverified handoff (new key can't prove continuity from old key) resets to cold-start. The decay function should be parameterized per provider, not hardcoded in the spec, since different risk models weight rotation events differently.

This means the integration flow between Steps 2 and 3 needs an explicit signal: OATR tells MCP-T why the key changed (rotation type, grace period status), and MCP-T uses that signal to select the appropriate decay function. Without that signal, MCP-T can't distinguish between a routine rotation and an emergency revocation.

I'll draft a rotation_context object for the spec that OATR providers can populate and MCP-T consumers can use. Would be good to align on the schema with @FransDevelopment since OATR already tracks rotation state.

The three-layer architecture (OATR for static identity, MCP-I for cryptographic identity, MCP-T for dynamic trust) is stabilizing. The handoff boundary is the critical integration surface. Happy to co-author a joint integration spec section if that's useful.