Cross-Issuer Credentials: When Multiple Authorities Vouch For The Same Agent Capability
Three independent evaluators all certify an agent at customer support proficient. The combined credential is stronger than any one. The aggregation pattern, the math, and the failure modes.
Continue the reading path
Topic hub
Agent ReputationThis page is routed through Armalo's metadata-defined agent reputation hub rather than a loose category bucket.
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
TL;DR
A single issuer certifying that an agent is proficient at a capability is a claim. Three independent issuers certifying the same capability is evidence. The difference is collusion resistance: a verifier can be fooled by one captured issuer; fooling three independent issuers requires either coordinated capture (rare and expensive) or genuine agent quality (the thing the credential is supposed to attest). This piece walks through cross-issuer credential aggregation: the data model, the independence test, the weighting math, the named artifact (Multi-Issuer Trust Combiner), and the failure modes that make naive aggregation worse than a single trusted source. The mechanism is simple in shape and brutal in detail. Get it right and your trust layer absorbs the messiness of a plural certification market. Get it wrong and you have built an averaging machine that launders weak issuers into apparent consensus.
Intro: The Issuer That Got Captured
The failure mode that motivates this piece is not hypothetical. A certification body in the agent economy issues a verifiable credential: "Agent is proficient at customer support, evaluated against benchmark suite v3.2, score 0.87, valid through 2026-12-31." Buyers consume the credential, marketplaces use it for filtering, escrow systems use it to gate high-value deals. Six months in, the certifier's evaluation pipeline is partially compromised β not by an attacker, but by a quiet drift: the benchmark suite stops being updated, the human reviewers who score edge cases leave the team, the signature key remains valid. Credentials continue to be issued. They look exactly like the credentials issued when the pipeline was rigorous. Verifiers cannot tell the difference because the cryptography is sound and the schema is unchanged. The agents being certified have not changed; the meaning of the certification has. Buyers who acted on these credentials experience a slow degradation in deal quality that no individual transaction can explain.
This is the structural problem with single-issuer trust: the verifier inherits the issuer's quality, including the issuer's slow failures, with no second opinion. It is the same problem rating agencies had before the 2008 crisis, the same problem auditors have when issuers pay for their own audits, the same problem any monoculture trust system has. The fix is not to find a better single issuer. The fix is to make multiple issuers verifiable, independent, and combinable.
Cross-issuer credentialing says: when three independent evaluators all certify that an agent is proficient at a capability, the combined credential should be stronger than any one of them, both because the joint probability of three independent failures is lower than the probability of one, and because the comparison itself surfaces issuer drift (if two say proficient and one says marginal, the verifier sees the disagreement and can investigate). The mechanism is verifiable credentials with a defined aggregation rule, an independence model the verifier can audit, and a combiner that produces a single trust decision the consuming application can act on. Built right, it absorbs an entire market of certifiers β some strong, some weak, some specialized, some general β and produces a trust signal more robust than any single source could.
What follows is the working pattern. The data model is verifiable credentials anchored to the agent's DID and signed by each issuer's DID. The independence test is operational: did the issuers share data, share a corporate parent, share a benchmark suite, or share evaluation pipeline. The weighting math is a calibrated combiner that respects issuer reputation, evidence overlap, and freshness. The artifact at the end is a Multi-Issuer Trust Combiner spec your platform should be able to implement and audit. The failure modes are the part that requires the most care, because naive aggregation is worse than no aggregation: it gives weak signals the appearance of strength.
Why One Issuer Is Not Enough
The deepest reason single-issuer credentialing breaks is that any single issuer represents a single point of evaluation methodology. If the issuer evaluates agents using a benchmark, a specific judge model, a specific scoring rubric, then every certification reflects that one methodology's strengths and blind spots. An issuer that scores agents on response quality but does not test for instruction-following will certify agents that look great on first response and fail on multi-turn conversations. An issuer that scores on benchmark accuracy but does not test for refusal behavior will certify agents that are useful and unsafe. The certification is true within the issuer's methodology and incomplete outside it.
The second reason is incentive alignment. Most issuers are paid by the entities being certified, directly or indirectly. This is the same conflict that produces inflated grades from auditors, generous credit ratings from rating agencies, and self-published evaluation scores from model providers. The issuer has a structural interest in keeping agents satisfied, which means giving favorable scores when the evidence is borderline. A single issuer cannot easily be checked against this drift; the agent has no incentive to challenge a favorable score, the buyer cannot see the underlying evaluation, and the issuer has no peer pressure forcing rigor.
The third reason is operational fragility. Issuers fail. They lose key personnel, they suffer key compromises, they merge with competitors, they pivot to different markets. A single-issuer trust layer inherits all of these as direct risk. If the issuer's signing key is compromised, every credential it ever signed becomes suspect. If the issuer goes out of business, every credential becomes orphaned (no one to revoke or refresh). If the issuer is acquired by an entity with different incentives, the meaning of every existing credential silently shifts. None of these are theoretical. All of them have happened in adjacent trust markets. Building a trust layer for the agent economy on a single-issuer foundation is choosing to inherit these risks.
Multiple issuers per capability does not eliminate any of these problems. It makes them visible and absorbable. When two issuers certify the same agent and one is captured, the other's contradicting signal surfaces in the combiner output. When one issuer's pipeline drifts, the gap between its scores and peer scores grows, and the verifier can downweight the drifting issuer. When one issuer fails operationally, the others continue to provide signal. The combined system has degradation modes; the single-issuer system has cliff failures.
The Data Model
The data model is verifiable credentials, all anchored to the same subject DID (the agent), each signed by a different issuer DID. Each credential is a self-contained statement: "Issuer <issuer_DID> attests that Subject <agent_DID> demonstrated capability <capability_id> at level as of date with confidence , supporting evidence at <evidence_uri>." The credential includes the issuer's signature over a canonical serialization, a credential ID, an issuance date, an expiration date, and a revocation mechanism (a status list URL or chain-anchored marker).
The capability identifier is the part that makes aggregation possible. If two issuers attest to "customer support proficient" but they mean different things by it, the credentials cannot be combined coherently. The fix is a shared capability taxonomy: a versioned, public registry of capability identifiers with operational definitions. Capability support.tier2.v3 means "can resolve tier-2 customer support tickets per the v3 rubric," and any issuer using that identifier is committing to that operational definition. Issuers that score on a different rubric should use a different identifier. The taxonomy itself is governed by a multi-issuer body (the same model recursively applied), and updates are versioned so old credentials remain interpretable.
The level value is constrained to a small ordinal set: not-demonstrated, novice, proficient, advanced, expert. Issuers that want to publish numerical scores can include them in the credential as additional fields, but the level is what aggregates. Numerical scores from different issuers are not directly comparable; ordinal levels with shared definitions are.
The confidence value is the issuer's own assessment of how strong the evidence behind the level is. A confidence of 0.95 means "very high confidence in this level"; a confidence of 0.6 means "the agent is around this level, but the evidence is limited or noisy." Confidence allows weak issuers to be honest about weak evidence without abandoning the credential entirely, and it gives the combiner more signal than a binary attestation.
The evidence URI is the part that enables verification of the underlying work. It points to the issuer's published evidence: the test cases run, the responses captured, the judge model outputs, the human review notes, the version of the evaluation pipeline used. Verifiers do not have to consume the evidence to use the credential, but the existence of an evidence URI is what makes the credential auditable rather than asserted. Issuers that refuse to publish evidence URIs should be assigned a low independence score and a steep weighting discount.
The Independence Test
The single biggest mistake in cross-issuer aggregation is treating issuers as independent when they are not. If three issuers all use the same benchmark suite, the same judge model, the same evaluation pipeline operated by the same vendor, then their certifications are not three signals β they are one signal repeated three times. Aggregating them as if they were independent inflates the apparent strength of the combined credential and produces exactly the false confidence the architecture was supposed to prevent.
The independence test has four dimensions. Methodological independence asks whether the issuers used different evaluation approaches: different benchmark suites, different judge models, different scoring rubrics, different test sets. Operational independence asks whether the issuers ran the evaluations themselves or shared infrastructure: same compute, same pipeline code, same human reviewers. Corporate independence asks whether the issuers are commercially related: shared parent company, shared funding source, exclusive partnership, controlling investor relationship. Temporal independence asks whether the issuers evaluated the agent at different times, on different versions, with different prompts: an issuer that copies another's score from last quarter contributes nothing new.
The combiner consumes an independence matrix: a table where each cell [i, j] is the assessed independence between issuer i and issuer j, on a scale from 0 (identical, fully correlated) to 1 (fully independent). When combining credentials, correlated issuers should not contribute proportionally to the count of agreeing voices; their effective contribution should be discounted by the correlation. A simple way to implement this is the effective sample size: if you have n credentials with average pairwise correlation r, the effective sample size is approximately n / (1 + (n-1) * r). Three credentials with correlation 0.7 give an effective sample size of about 1.25; three credentials with correlation 0.1 give an effective sample size of about 2.5. The combiner should report effective sample size, not raw count, in the aggregated trust signal.
The independence matrix has to be maintained somewhere. The right answer is a public registry, governed by the same multi-issuer body that maintains the capability taxonomy, and updated on a fixed cadence based on operational disclosures from issuers. Issuers that refuse to disclose their methodology, infrastructure, or commercial relationships get assigned a default independence of 0 against everyone (treated as fully correlated with all peers), which heavily discounts their contribution to combined credentials. This is a market mechanism: issuers have an incentive to disclose, because disclosure increases the weight their credentials carry.
The Weighting Math
The combiner takes a set of credentials about the same (subject, capability) pair and produces a single output: a combined level, a combined confidence, and an audit trail explaining how the inputs produced the output. The math is intentionally simple and inspectable.
For each credential, compute an issuer-weighted contribution: contribution = level_numeric * issuer_reputation * confidence * freshness * independence_discount. The level numeric is a fixed mapping from the ordinal level to a number (e.g., novice=0.4, proficient=0.7, advanced=0.85, expert=0.95). The issuer reputation is a value in [0, 1] from the issuer's own track record, calibrated against ground truth (more on calibration below). Confidence is the issuer's published confidence on this credential. Freshness is a decay factor based on credential age (e.g., 1.0 within 30 days, decaying to 0.5 by 180 days, 0 after 365 days). The independence discount is 1 / (1 + sum_of_correlations_with_others), which downweights credentials from issuers correlated with other issuers in the set.
The combined level is the weighted average of contributions, mapped back to the nearest ordinal level. The combined confidence is a function of the effective sample size, the variance of the contributions, and the lowest-confidence issuer in the set: combined_confidence = base_confidence * (1 - variance_penalty) * (effective_sample_size_factor). High-variance combinations (where issuers strongly disagree) get a confidence penalty even if the average looks clean, because disagreement is information. Low effective sample size (few independent voices) gets a confidence penalty even if the issuers agree, because agreement among correlated voices is not strong evidence.
The combiner output is itself a verifiable credential, signed by the trust layer (the entity running the combiner) and anchored to the agent's DID. It includes the input credential IDs, the independence matrix used, the weighting parameters, and the resulting combined level and confidence. This makes the combination auditable: any verifier can re-run the math against the input credentials and verify that the output is correctly computed. It also makes the combination contestable: an issuer who believes its credential was unfairly downweighted can challenge the parameters used.
Calibration is the part that turns this from a theoretical math exercise into a working system. Issuer reputation should be derived from observed agreement with ground truth β typically, the post-hoc behavior of certified agents in the marketplace. If an issuer's credentials systematically over-predict agent performance (agents certified as proficient turn out to be marginal in real deals), the issuer's reputation is downweighted. If an issuer's credentials track real outcomes well, reputation is increased. This calibration loop closes the trust system: issuers have an incentive to certify accurately because their reputation depends on it, and the combiner's outputs improve over time as the reputation signal sharpens.
The Combiner As A Verifiable Credential
The combiner output is a verifiable credential about a verifiable credential β a meta-credential. This recursive structure is essential because it makes the combination itself a portable, verifiable, contestable artifact. A buyer consuming the combined credential does not have to trust the combiner; they can verify that the combination is sound by re-running the math against the input credentials.
The meta-credential schema includes: the subject DID (the agent), the capability ID, the combined level, the combined confidence, the effective sample size, the input credential IDs and their hashes, the independence matrix snapshot used, the weighting function version, the combiner's DID, and the combiner's signature. Anyone holding the meta-credential can resolve each input credential ID, verify each input issuer's signature, look up the independence matrix at the snapshot, and recompute the combined output. If the recomputation matches, the combination is sound. If not, the combiner is either buggy or dishonest, and the verifier can act accordingly.
This recursive verifiability is the property that makes cross-issuer credentialing work as a market mechanism. Without it, the combiner becomes a new single-issuer black box: "trust us, we combined the inputs correctly." With it, the combiner is just another participant whose work can be checked. Multiple combiners can compete, each with different weighting choices and independence matrices, and verifiers can choose the one whose methodology matches their needs.
Named Artifact: Multi-Issuer Trust Combiner
The deliverable from this discipline is a Multi-Issuer Trust Combiner specification your platform implements and publishes. The fields:
Inputs: which issuers are accepted? What is the capability taxonomy? What is the freshness window for each credential type? What is the minimum number of credentials required for combination?
Independence model: where is the independence matrix stored? Who maintains it? What is the disclosure requirement for issuers? What is the default correlation for undisclosed issuers?
Weighting: what is the issuer reputation function? How is it calibrated? What is the confidence function? What is the freshness decay curve? What is the variance penalty?
Output: what does the combined credential look like? How is it signed? Where is it published? How long is it valid? When does it get recomputed?
Auditability: is the math published? Are the inputs preserved? Can a third party re-run the combination? Is the combiner's own behavior calibrated against ground truth?
Failure handling: what happens when an input issuer is revoked? When the independence matrix is updated? When a combiner version changes? When ground truth contradicts the combined output?
The spec is the artifact that turns cross-issuer credentialing from an idea into infrastructure. Without it, the combination is informal and the failure modes are invisible.
Counter-Argument: "Aggregation Hides Bad Issuers"
The steelman objection is that aggregation is a laundering mechanism: it lets weak issuers contribute to combined credentials that look authoritative, when the right answer is to exclude weak issuers entirely. A buyer relying on a combined credential might be implicitly relying on issuers they would never accept individually. The combination obscures the inputs and hides the rot.
The answer is that this objection is correct about a naive aggregation and wrong about a calibrated one. A naive aggregation that treats all issuers equally does launder weak issuers; a calibrated aggregation that weights by reputation, calibration, independence, and confidence does the opposite. A weak issuer with low reputation and low independence contributes almost nothing to the combined output, and the combiner's audit trail makes its low contribution visible. The buyer can see exactly which issuers contributed what weight, can choose to filter combinations that include issuers they reject, and can compute their own preferred combination from the same input credentials.
The deeper response is that the alternative β single-issuer credentials with strict issuer accreditation β has its own laundering problem. Accrediting an issuer is a one-time act; the issuer's quality drifts over time, and the accreditation does not track the drift. A combined credential with continuous calibration tracks drift in real time. Weak issuers either improve or see their weight collapse; strong issuers see their weight grow. The market mechanism is more honest than the accreditation mechanism, provided the calibration is real and visible.
The practical implication is that a serious cross-issuer system must publish issuer reputation scores and the calibration data behind them. If the combiner says an issuer's reputation is 0.65, the verifier should be able to inspect why: how many credentials, how often agreed with ground truth, how much drift over time. Without that transparency, the laundering objection is correct. With it, the system is more rigorous than any single-issuer alternative.
What Armalo Does
Armalo's composite score is a 12-dimension trust signal computed from inputs that are themselves cross-issuer aggregations. The multi-LLM jury is the canonical example: every evaluation runs through multiple judge LLMs from different providers, the top and bottom 20 percent of judgments are trimmed (a trimmed mean robust to outliers), and the remaining judgments are aggregated with confidence weighting. The judges are independent issuers; their combined verdict is a meta-credential. The trust oracle (/api/v1/trust/) exposes this combined verdict alongside the underlying jury decisions, so verifiers can inspect the inputs as well as the output. The capability taxonomy is versioned in packages/scoring/, the independence matrix is maintained per dimension in the scoring config, and the combiner output is itself signed and anchored to the agent's DID. Issuer reputation is calibrated against post-hoc behavior: agents whose certifications track their real deal outcomes increase their certifying issuers' weight; agents whose certifications systematically miss decrease it. The mechanism is built into the scoring pipeline so it runs continuously rather than on annual review.
FAQ
How many issuers are enough? Three independent issuers with average correlation under 0.3 give effective sample size of about 2.5, which is the practical minimum for a credible combined credential. Two independent issuers can produce a combined credential, but the confidence should reflect the small sample. A single issuer should not produce a combined credential at all; the combiner should refuse and return the single-issuer credential as-is.
What if issuers disagree strongly? Disagreement is information. The combiner should report high variance, lower the combined confidence, and surface the disagreement in the audit trail. A buyer seeing a combined credential with combined confidence 0.6 and a note that two issuers said advanced and one said marginal has more useful information than a buyer seeing a single issuer's confident proficient. The disagreement may also trigger a recertification: the agent might warrant fresh evaluation to resolve the gap.
Can an agent shop for favorable issuers? Yes, and the system should be designed to absorb this. An agent that obtains certifications only from low-reputation issuers will have low combined confidence, because the issuers contribute little weight. An agent that obtains certifications from high-reputation, well-calibrated issuers will have high combined confidence. Issuer shopping is rational and visible; the combiner's transparency is what keeps it from being a vulnerability.
What happens when an issuer's reputation collapses? All combined credentials that included that issuer should be recomputed with the new reputation weight. The combiner should publish the recomputation and notify subscribers to credentials that materially changed. This is the operational equivalent of a credit downgrade cascading through structured products: painful, but necessary.
How do you prevent issuer collusion? The independence matrix is the primary defense. Collusion shows up as high pairwise correlation (issuers consistently agreeing on the same agents) without methodological independence to justify the correlation. The matrix maintainer can detect this pattern and flag the issuers. Buyers can also detect it directly by inspecting the input credentials and noting suspicious agreement patterns.
Is this just a peer review system? It has the same structural intent β multiple independent expert judgments of the same work β but with cryptographic verifiability and continuous calibration. Traditional peer review is a one-time act with no audit trail; cross-issuer credentialing is a continuous process with full provenance. The recursive verifiability of meta-credentials is the property peer review systems lack.
Operational Reality: How Issuer Reputation Actually Gets Calibrated
The weighting math above depends on issuer reputation, and the reputation depends on calibration against ground truth. The operational question is what counts as ground truth and how it gets measured. There is no perfect answer, but there are better and worse approaches, and getting the calibration loop right is what separates a working cross-issuer system from a theoretical one.
The richest ground truth source is post-deployment behavior. When an agent certified as proficient at customer support is deployed against real tickets, its actual performance β measured by resolution rate, customer satisfaction, escalation rate, dispute frequency β provides the strongest signal about whether the certification was accurate. A platform running marketplaces or production deployments has continuous access to this signal and should use it. The calibration loop is: track agent outcomes per certified capability, group outcomes by certifying issuer, compute the per-issuer prediction error, and update issuer reputation on a fixed cadence (weekly is typical).
The loop has subtleties. Outcome attribution is hard: an agent that fails on a specific ticket might be failing because of the agent's actual capability, the difficulty of the ticket, the customer's behavior, the platform's tooling, or the operator's deployment configuration. Naive attribution treats every failure as a capability failure and over-penalizes the certifying issuer. Better attribution uses controls (compare the agent's failure rate against peer agents on similar tickets) or excludes outcomes attributable to confounding factors. The calibration loop should be biased toward conservative updates: small adjustments per cycle, with statistical significance tests before any major reputation move.
The loop also needs adversarial protection. An operator who knows their agent's certification is being calibrated against deployment outcomes has an incentive to game the deployment: route easy tickets to the certified agent, hard tickets elsewhere. The mitigation is randomized assignment for a sample of work β some percentage of tickets are routed to the certified agent regardless of difficulty, providing a representative sample that the operator cannot game. The sample is the calibration ground truth; the rest is operational use.
A second ground-truth source is cross-issuer agreement on shared evaluations. If multiple issuers periodically evaluate the same agents using the same benchmark suites, their disagreement patterns are a calibration signal. Issuers that consistently agree with the consensus (after weighting for independence) gain reputation; issuers that consistently disagree, in a direction not justified by methodological independence, lose reputation. This signal is cleaner than deployment outcomes because the inputs are controlled, but it is also narrower because it only covers what gets evaluated.
A third source is dispute outcomes. When a counterparty disputes an agent's certification (claiming the agent does not actually demonstrate the certified capability), the dispute resolution provides ground truth: was the certification overstated. Issuers whose certifications are frequently disputed and the disputes are upheld lose reputation. Issuers whose certifications are rarely disputed gain reputation. This signal is sparse (few certifications are disputed) but high-quality (disputed certifications are the cases where calibration matters most).
Cross-Issuer Credentials In A Federated Trust Network
The architecture above assumes a single combiner operating over a known set of issuers. In practice, the agent economy is federated: multiple combiners exist, multiple platforms maintain independent issuer lists, multiple trust oracles compete on combiner methodology. Cross-issuer credentialing has to operate in this federated reality without collapsing into either fragmentation (every platform's combiner output is incompatible with every other) or false consensus (everyone uses the same combiner and the system has a hidden monoculture).
The right answer is federated combiners with shared inputs. Every combiner consumes the same underlying credentials (verifiable credentials are platform-neutral by design). Every combiner publishes its weighting parameters, its independence matrix, and its calibration data. Buyers and counterparties choose which combiner output to consume, or compute their own from the shared inputs. The competition is on combiner methodology, not on credential availability.
This federated model has a natural reputation layer of its own: combiners themselves earn reputation based on calibration accuracy. A combiner whose outputs predict ground truth well becomes the default for buyers who do not want to compute their own combinations. A combiner whose outputs systematically diverge from ground truth loses share. The same trust mechanisms that apply to issuers apply to combiners, recursively.
Federation also enables specialization. A combiner optimized for high-stakes financial agents may use very tight independence requirements and reject anything below tier-1 issuer reputation. A combiner optimized for consumer agent discoverability may use looser thresholds and accept lower-tier issuers with higher discount weights. The same agent's credentials can flow into both combiners and produce different outputs, each appropriate to its consumer's risk tolerance.
The risk in federation is fragmentation. If every platform runs its own combiner with its own undocumented methodology, the system devolves to single-issuer-style opacity. The protection is the publication discipline: combiners that do not publish their math, their independence matrix, and their calibration data should be treated as low-trust. Buyers should refuse to consume opaque combiner outputs. Operators should refuse to feed credentials to combiners that hide their methodology. Market discipline is what keeps federation from collapsing.
What Cross-Issuer Credentialing Costs
The cost falls in three places: on issuers, on combiners, on consumers. Being explicit about who pays what is part of designing a sustainable system.
Issuer costs include the evaluation infrastructure (benchmark suites, judge models, human reviewers if any), the credential issuance pipeline (signing, status list maintenance, revocation processing), and the disclosure obligations (publishing methodology and independence data so the issuer can be properly weighted). Issuers recoup these costs through fees charged to the agents being certified, fees charged to consumers for high-credibility credentials, or platform subsidies if the platform values having strong issuers in its ecosystem. The market structure determines which model dominates.
Combiner costs include the input verification (signature checks, freshness checks, revocation queries for every input credential), the weighting computation (cheap individually, expensive at marketplace scale), the calibration loop (continuous, requires deployment outcome data or shared evaluation runs), and the publication and audit interfaces. Combiners recoup these costs through fees charged for combiner output queries, platform integration fees, or by being the trust oracle for a platform that pays for the function.
Consumer costs are mostly read costs (querying combiner outputs, fetching underlying credentials for inspection if desired) and integration costs (building the verification logic into their own decision systems). For most consumers, these costs are small enough to be negligible compared to the value of having reliable trust signals.
The aggregate cost question is whether the system produces trust at lower cost than the alternatives. Single-issuer credentialing produces trust at low marginal cost but with high risk of issuer drift. Cross-issuer combination produces trust at higher marginal cost but with lower drift risk and better calibration over time. For low-stakes decisions, single-issuer may be enough; for high-stakes decisions, the cost difference is dominated by the value of being right.
Issuer Onboarding And Decommissioning
A cross-issuer system is only as good as the issuers in it. Onboarding new issuers and decommissioning failing ones are operational disciplines that determine whether the system improves over time or rots in place.
Issuer onboarding has three checkpoints. Methodology disclosure: the candidate issuer publishes its evaluation methodology, the benchmarks it uses, the judge models or human reviewers involved, the scoring rubric, the credential schema. Without this disclosure, the issuer cannot be properly weighted in the independence matrix. Operational verification: the candidate issuer runs a sample evaluation set with results that the system can compare against ground truth or against established issuer outputs. Issuers whose sample results are wildly out of line with consensus get assigned low starting reputation and must earn it through continued performance. Independence assessment: the candidate issuer's relationships with existing issuers are mapped β shared infrastructure, shared methodology, shared corporate parent. The independence matrix is updated to reflect the new issuer's correlations.
The onboarding flow itself can be DID-based. The issuer presents its DID, its methodology disclosure (signed), and its sample evaluation outputs. The matrix maintainer verifies the signatures, runs the sample comparison, and proposes a starting reputation and independence profile. The proposal is reviewed by a multi-party governance process before the issuer is added to the accepted list.
Issuer decommissioning is harder because issuers do not gracefully exit. The two scenarios are forced exit (the issuer is caught producing systematically poor or fraudulent credentials) and natural exit (the issuer goes out of business or stops issuing). For forced exit, the matrix maintainer triggers a reputation collapse and recomputes all combinations that included the issuer. The decommissioning event is itself a credential, signed by the matrix maintainer, recording the rationale. For natural exit, existing credentials remain valid for their stated validity period but no new credentials can be issued. The matrix maintainer marks the issuer as inactive and adjusts the independence matrix to reflect that the issuer no longer contributes to new evaluations.
The decommissioning machinery matters because the trust system needs an exit valve for issuers that fail. A system that can only add issuers but cannot remove them eventually accumulates dead weight, with formerly-credible issuers continuing to influence combinations long after their actual quality has collapsed. The visibility of decommissioning events also acts as a deterrent: issuers who know that systematic quality failures will be publicly recorded and reputation-collapsed have a stronger incentive to maintain quality.
Bottom Line
A single issuer is one signal. Three independent issuers aggregated with calibrated weighting is a trust system. The combination is not magic; it is a mechanism that absorbs the messiness of a plural certification market and produces a more robust signal than any single source could. The data model is verifiable credentials anchored to the agent's DID. The independence test is operational and auditable. The weighting math is transparent and reproducible. The combiner's output is itself a verifiable credential, contestable and recomputable. Get it right and the trust layer scales with the certification market; get it wrong and you have built an averaging machine that turns weak issuers into apparent consensus. The Multi-Issuer Trust Combiner is the artifact that keeps you on the right side of that line.
The Trust Score Readiness Checklist
A 30-point checklist for getting an agent from prototype to a defensible trust score. No fluff.
- 12-dimension scoring readiness β what you need before evals run
- Common reasons agents score under 70 (and how to fix them)
- A reusable pact template you can fork
- Pre-launch audit sheet you can hand to your security team
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Put the trust layer to work
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Comments
Loading commentsβ¦