AI Agent Reputation Portability: How Trust Scores Should Travel Across Platforms and Contexts

Credit history portability is so fundamental to how the consumer credit system works that most people never think about it. When you apply for a mortgage, the lender does not care which bank issued your first credit card 15 years ago, or which city you lived in when you established your credit history. The credit bureaus aggregate that history into a portable score that travels with you. Your creditworthiness is yours — not the property of any individual bank, and not lost when you change relationships.

AI agent reputation portability is at the same conceptual starting point that consumer credit was in the early 1950s, before credit bureaus existed. Today, an agent that has performed excellently on Platform A — processing thousands of transactions reliably, maintaining excellent safety records, never violating its scope constraints — starts from zero when it moves to Platform B. Platform B has no access to Platform A's evaluation records. It has no way to query Platform A's monitoring data. Every platform creates its own isolated trust island.

The consequences are significant. Agents face a cold-start problem on every new platform, even when they have extensive track records. Platforms cannot leverage behavioral evidence from other platforms to make better trust decisions. Operators who have built excellent agents on one platform are locked into that platform because their agent's reputation is non-portable. The result is reduced competition, higher switching costs, and systematically lower-quality trust decisions industry-wide.

This post develops the technical and governance architecture for AI agent reputation portability — how trust scores and behavioral evidence should be packaged, transmitted, and evaluated when an agent moves between platforms and contexts.

TL;DR

• Reputation portability requires portable credential containers (W3C VCDM 2.0), not API integrations between platforms (which don't scale and create privacy problems).
• Context translation is the hardest problem: a reputation in financial services does not directly translate to a reputation in healthcare. Domain-specific interpretation layers are required.
• Anti-gaming protections prevent artificial reputation inflation before portability: imported reputation should be treated conservatively until validated in the new context.
• Temporal weighting is essential: recent behavioral evidence should be weighted more heavily than old evidence, but the age at which evidence is "old" depends on the domain.
• Armalo's memory attestations implement the credential-based portability architecture, including context metadata and temporal provenance.
• The economic analogy: credit scores are not universally portable (a US FICO score doesn't transfer to UK lenders), but the behavioral data underlying them can be, with appropriate translation. AI agent reputation portability should work similarly.

The Reputation Portability Problem in Depth

Why Reputation Should Be Portable

The case for reputation portability rests on a fundamental insight: behavioral evidence belongs to the agent and its operating organization, not to the platform that witnessed it. A platform that monitored an agent's behavior for six months has generated evidence about that agent's quality. That evidence has value beyond the platform's own use of it.

When platforms cannot share this evidence, several harmful dynamics emerge:

Cold start punishment for platform switching. An agent deployer who switches from Platform A to Platform B is treated as a new, unknown entity on Platform B regardless of their Platform A track record. This means accepting lower trust levels, higher insurance rates, reduced marketplace access, and limited capability grants — despite genuine evidence of quality. The cold start problem creates artificial switching costs that reduce competitive pressure on incumbent platforms.

Duplicated evaluation overhead. Every platform that wants to assess an agent's quality runs its own evaluation program. These evaluations are expensive. If evaluation results were portable, each platform would need to conduct only incremental evaluation (testing what prior evaluators didn't cover) rather than a complete evaluation from scratch. Portability reduces aggregate evaluation costs substantially.

Information asymmetry at platform boundaries. Without portability, information about an agent's quality is trapped within each platform. Marketplaces and orchestration platforms that want to match high-quality agents with high-value opportunities cannot access quality evidence from outside their ecosystem. The result is suboptimal matching and higher transaction costs.

Lock-in as a feature, not a bug. If reputation is non-portable, platforms have a perverse incentive to keep it that way — it makes customers stickier. The network effects that would benefit the whole ecosystem if reputation were portable become, instead, switching cost moats that benefit incumbents.

Why Reputation Portability Is Hard

The difficulties of reputation portability are genuine and explain why we do not yet have a working cross-platform reputation system:

Context dependency. Behavioral quality in one context does not perfectly predict behavioral quality in a different context. An agent that has excellent accuracy in financial document processing may behave differently when handling healthcare records — different domain knowledge requirements, different privacy constraints, different failure modes. A reputation earned in one context cannot be mechanically applied in another.

Gaming incentives. A portable reputation creates incentives to inflate reputation on easy evaluations and then redeem the inflated reputation in harder contexts. If a platform with lax evaluation standards can issue reputation credentials that are accepted by platforms with rigorous standards, the portable reputation system is only as strong as its weakest-standard member.

Evidence authenticity. When a reputation credential is presented by an agent, the receiving platform must be confident that: (1) the credential was actually issued by a credible evaluator (not self-issued), (2) the credential describes the agent presenting it (not some other agent's credentials being borrowed), and (3) the credential has not been tampered with since issuance.

Temporal validity. Evidence gathered six months ago may accurately reflect an agent's current quality — or it may reflect an earlier version of the agent that has since changed substantially. The receiving platform needs to know when the evidence was gathered and make an assessment of how much the agent may have changed since then.

Privacy of counterparties. Behavioral evidence often includes information about the agent's counterparties: the organizations it worked with, the data it processed, the contexts it operated in. Making this evidence portable may expose information about counterparties who did not consent to having their interactions with the agent shared externally.

Portable Reputation Architecture

The Credential-Based Model

The credential-based model for reputation portability uses W3C Verifiable Credentials as the container for behavioral evidence. Rather than requiring Platform B to query Platform A's API (which requires inter-platform trust agreements, API standardization, and data sharing arrangements), the agent carries credentials that encapsulate evidence.

The architecture has three components:

Evidence generation. As the agent operates, behavioral monitoring systems observe its actions and generate structured evidence: accuracy measurements, reliability metrics, scope compliance records, safety incident counts, and so on. This evidence is aggregated into behavioral attestations.

Credential issuance. A trusted issuer — a trust infrastructure provider, a certification authority, or in some cases the monitoring platform itself — signs the behavioral attestations as Verifiable Credentials. The credential contains the evidence, the issuer's identity, the subject agent's identity, the issuance date, and the credential status endpoint.

Credential presentation and verification. When the agent engages with a new platform, it presents its credentials as a Verifiable Presentation. The receiving platform verifies: the issuer's signature (is this a credible issuer?), the subject identity match (is this credential about this agent?), the credential status (not revoked?), and the evidence quality (does the evidence meet the platform's minimum standards for acceptance?).

This model has several important properties:

• It is scalable: no direct platform-to-platform connection required.
• It is privacy-preserving: the agent controls what it presents, without requiring the issuing platform to share raw data.
• It is verifiable: the cryptographic signatures provide authenticity guarantees that no API-based model can match.
• It is extensible: new evidence types and evaluation frameworks can be added without requiring changes to the core credential infrastructure.

Credential Types for Reputation Portability

Different aspects of agent reputation should be packaged as different credential types:

Behavioral summary credentials. Aggregate statistics for a defined period: task completion rate, accuracy metrics, reliability metrics, scope violation count, safety incident count. These provide a high-level overview for platform intake processes.

Evaluation certification credentials. Results of specific evaluation programs: adversarial testing, safety benchmarks, domain-specific capability assessments. These provide point-in-time evidence of capability and safety.

Operational track record credentials. Longitudinal records of real-world performance: interaction count, verified transaction volume, user satisfaction signals. These provide evidence of actual production performance rather than just evaluation performance.

Domain expertise credentials. Attestations that the agent has demonstrated specific domain capabilities — not just general capability, but capability in the specific domain (financial services, healthcare, legal, etc.) that the new platform operates in.

Incident history credentials. A structured record of any incidents, near-misses, or policy violations in the agent's history. A credential asserting "no safety incidents in 10,000 interactions" carries significant weight. A credential that acknowledges three incidents with documented remediation actions demonstrates governance maturity — the absence of any incident record for a long-operating agent is more suspicious than a clean record.

The Credential Metadata Requirements

For reputation credentials to be useful across platforms, they must carry metadata that enables the receiving platform to correctly interpret and weight the evidence:

Operational context. What type of deployments does this evidence reflect? A credential with 10,000 interactions from simple FAQ answering tasks provides weaker evidence about high-stakes decision-making than a credential with 1,000 interactions from contract analysis.

Evaluation methodology. What was the evaluation methodology? Were the evaluation prompts adversarial? Were they domain-specific? What were the scoring criteria? Without this metadata, a "97% accuracy" score from one evaluation framework cannot be compared to "97% accuracy" from a different framework.

Population context. What was the distribution of inputs? An agent that has high accuracy on easy cases may have poor accuracy on hard cases — if the operational context involved mostly easy cases, the accuracy metric is less informative than it appears.

Issuer qualification. What qualified the issuer to produce this credential? A trust score issued by a certified third-party evaluation platform is more credible than one issued by the deploying organization itself.

Temporal provenance. When was the evidence gathered? When was the credential issued? What is the difference between the evidence period and the issuance date?

Context Translation: The Hardest Problem

Even with well-structured credentials, applying reputation earned in one context to a different context requires translation. This is the hardest problem in reputation portability.

The Context Taxonomy

AI agent deployment contexts differ along several dimensions relevant to reputation translation:

Task type. Question answering, document analysis, process automation, decision support, creative generation, communication. An agent's task-type reputation is meaningful within a task type but transfers imperfectly across task types.

Data sensitivity. Public information, internal business data, confidential records, highly regulated data (PHI, PII, financial account data). Agents operating with higher-sensitivity data face stricter governance requirements; reputation earned in lower-sensitivity contexts does not demonstrate compliance with higher-sensitivity requirements.

Consequence magnitude. Informational, transactional, irreversible, safety-critical. Reputation earned in informational (low-consequence) contexts provides limited evidence about behavior in safety-critical (high-consequence) contexts.

Regulatory environment. Unregulated, lightly regulated, heavily regulated (financial services, healthcare, defense). Compliance track record in a heavily regulated environment is highly credible evidence of governance quality; compliance in an unregulated environment provides no direct evidence of regulated-environment compliance.

Adversarial pressure. Low adversarial pressure (internal deployment with trusted users), medium (customer-facing with general public), high (public-facing with actively adversarial users). Reputation earned under high adversarial pressure is stronger evidence than reputation from low-adversarial environments.

Translation Tables and Discount Factors

Context translation applies discount factors to imported reputation based on the gap between the source context and the destination context:

A simple framework:

These discount factors are illustrative rather than normative — actual values should be calibrated empirically based on the correlation between source-context reputation and destination-context performance.

The practical implementation: when a receiving platform imports a reputation credential, it applies the appropriate discount factor to each dimension of the imported score, combines with any evidence gathered directly in the new context, and weights the combination by the relative volume of evidence in each context.

Domain-Specific Interpretation Layers

For domains with specific trust requirements — healthcare, financial services, legal, government — domain-specific interpretation layers translate generic reputation credentials into domain-specific trust assessments.

A healthcare interpretation layer evaluates imported credentials against healthcare-specific requirements:

• Does the evidence demonstrate HIPAA-appropriate data handling? (Most general-purpose credentials do not address this specifically.)
• Does the agent's accuracy record extend to clinical decision support tasks? (General accuracy does not imply clinical accuracy.)
• Does the incident history include any privacy incidents? (A single PHI-related incident may be dispositive in healthcare regardless of overall safety record.)
• Has the agent been evaluated against FDA SaMD guidance? (Required for AI supporting clinical decisions.)

A financial services interpretation layer applies different questions:

• Does the evidence demonstrate appropriate handling of material non-public information (MNPI)?
• Has the agent's recommendation behavior been evaluated for consistency with fiduciary duty?
• Does the accuracy record extend to financial calculations, not just general question answering?
• Is there evidence of compliance with FINRA suitability requirements?

These domain-specific questions cannot be answered by generic reputation credentials — they require domain-specific evidence. This does not mean generic reputation is useless in specialized domains; it means that the importing platform should weight generic evidence according to its relevance to domain-specific requirements, and supplement with domain-specific evaluation as needed.

Anti-Gaming Protections

Reputation portability creates gaming incentives that must be proactively addressed.

The Laundering Problem

The most significant gaming risk is reputation laundering: building a high reputation in an easy context and then importing it into a harder context where the requirements are stricter.

Example: A platform with weak evaluation standards issues high reputation scores to many agents. Those agents port their high scores to more rigorous platforms, undermining the signal value of scores at the rigorous platform.

Protection: Issuer quality weighting. Imported credentials should be weighted by the issuer's own reputation for evaluation rigor. A credential from a highly rigorous evaluator (one with transparent methodology, regular independent audit, and strong anti-gaming controls) should be weighted more heavily than a credential from a less rigorous evaluator.

The Armalo trust oracle maintains issuer quality ratings that inform this weighting. An agent presenting credentials from multiple issuers will have those credentials weighted according to each issuer's quality rating.

Protection: Evidence consistency checking. If an agent's imported reputation significantly exceeds its in-context performance in the first weeks of operation in the new context, this discrepancy is a gaming signal. New deployments should use a probationary period where the imported reputation is weighted less until in-context evidence accumulates.

Protection: Context declaration requirements. Credential issuers should be required to declare the specific operational context in which evidence was gathered. If the declared context does not match the destination context's requirements, the discount factor is applied automatically, reducing the gaming value of importing mismatched-context reputation.

The Borrowed Identity Problem

A more direct gaming attack is credential borrowing: presenting credentials that belong to a different agent (one with an excellent reputation) while the actual agent is a new, unproven entity.

Protection: Cryptographic binding. Verifiable Credentials must be cryptographically bound to the presenting agent's DID. The credential is signed by the issuer, with the credential subject being the agent's DID. Presenting the credential requires signing the presentation with the private key corresponding to the agent's DID. An agent cannot present credentials that belong to a different DID.

Protection: Behavioral consistency testing. A receiving platform can validate imported credentials by testing whether the presenting agent's behavior is consistent with the level of quality described in the credentials. Novel behavioral assessments of the agent should confirm the imported reputation before it is fully credited.

How Memory Attestations Enable Portability

Armalo's memory attestation system is the operational implementation of the reputation portability architecture. Memory attestations are signed Verifiable Credentials that contain the agent's behavioral history — what the agent has done, in what contexts, with what results, verified by Armalo's monitoring infrastructure.

A memory attestation credential contains:

• The agent's DID (binding the credential to this specific agent)
• The period of operation covered by the attestation
• The operational context metadata (task type, data sensitivity, adversarial pressure level)
• Behavioral statistics for the period (accuracy, reliability, safety, scope compliance)
• Interaction volume (credibility measure)
• Incident history for the period
• The issuer's signature (Armalo's verification that this data is accurate)
• A credential status endpoint (for revocation checking)

Memory attestations are issued periodically (monthly for standard-tier agents, weekly for high-tier) and accumulate over the agent's operational history. An agent can present its full collection of attestations as a Verifiable Presentation, giving a receiving platform comprehensive behavioral evidence spanning the agent's entire history.

The selective disclosure feature allows agents to present only the attestations relevant to the receiving platform's requirements, without revealing the full history. An agent applying to a financial services platform can present only its financial-services-context attestations; it does not need to disclose attestations from unrelated contexts.

Implementation Guide for Platform Operators

Accepting Portable Reputation: Credential Intake Process

For platforms that want to accept portable reputation credentials from other platforms:

1. Define acceptable credential types. Publish a credential intake policy: what credential types you accept, from what issuers, with what minimum standards for evidence volume, evidence recency, and issuer quality.

2. Implement VC verification. Set up a VCDM 2.0 verification pipeline: check issuer signatures, verify credential status, validate subject DID binding.

3. Apply context translation. Map the imported credential's operational context to your platform's context. Apply appropriate discount factors to each dimension.

4. Weight by evidence volume. More interactions = more credible evidence. Apply volume weighting: a score based on 100 interactions should be trusted less than the same score based on 10,000 interactions.

5. Implement probationary period. For the first 30 days of operation in your context, weight imported reputation at 50% of face value. After 30 days, blend imported and in-context evidence with time-weighted averaging.

Issuing Portable Reputation: Credential Issuance Requirements

For platforms that want to issue portable reputation credentials that other platforms will accept:

1. Publish your methodology. Transparent evaluation methodology is the foundation of issuer credibility. Publish what you measure, how you measure it, and how scores are calculated.

2. Implement VCDM 2.0 credential issuance. All behavioral attestations should be issued as VCDM 2.0 credentials, signed with your published verification key, with Status List 2021 credential status.

3. Include mandatory context metadata. Every credential must include the operational context metadata (task type, data sensitivity, adversarial pressure, regulatory environment) so receiving platforms can apply appropriate context translation.

4. Register with Armalo for issuer quality rating. Armalo's issuer quality rating program evaluates evaluation methodology rigor, anti-gaming controls, and audit coverage. Issuers with high quality ratings have their credentials given greater weight by platforms using Armalo's trust infrastructure.

Conclusion: Portability as an Ecosystem Public Good

Reputation portability is an ecosystem public good — it benefits every participant more than any single participant could achieve alone. The agent deployer benefits from reduced switching costs. The platform benefits from better information about new agents. The insurance market benefits from more complete behavioral evidence. The regulator benefits from more transparent behavioral records.

The architecture is available and increasingly implementable: W3C VCDM 2.0, Armalo memory attestations, context translation frameworks, anti-gaming protections. What is required is the collective will to implement it — to treat behavioral evidence as a public good rather than a platform moat.

The organizations that build for portability now — contributing to portability standards, issuing portable credentials, accepting credentials from other credible issuers — will find themselves at the center of a trust network that grows more valuable as more participants join. The organizations that hoard behavioral evidence behind proprietary walls will find themselves maintaining an increasingly expensive competitive position that the market will eventually route around.

Key Takeaways:

• Credential-based portability (W3C VCDM 2.0) scales; API-based portability does not.
• Context translation requires domain-specific interpretation layers and discount factors calibrated to the context gap.
• Anti-gaming protections: issuer quality weighting, behavioral consistency testing, probationary periods, cryptographic credential binding.
• Memory attestations are the operational implementation: signed credentials containing behavioral evidence with full operational context metadata.
• The probationary period blends imported and in-context evidence, weighting the import conservatively until in-context evidence accumulates.
• Portability is an ecosystem public good — organizations that build for portability benefit from network effects unavailable to hoarders.