Proposal: expose TrustProvider scores as first-class agent trust attributes for downstream consumers

[creatorrmode-lead]

Context

Following up on #1010 (AVPProvider, merged Apr 16).

The TrustProvider interface now lets toolkit consumers plug in reputation/trust sources. Scores are returned to the caller at call time, but there is currently no standardized way for downstream systems — identity directories, admin UIs, or policy engines — to surface those scores as agent attributes without each consumer writing glue code per provider.

This issue proposes a lightweight schema addition so TrustProvider output becomes a normalized, discoverable surface on the agent record, not just the return value of a one-off call.

Problem

Today (post-#1010), a TrustProvider returns structured data like:

{
  "score": 0.85,
  "tier": "trusted",
  "confidence": 0.92,
  "risk_level": "low",
  "provider": "avp",
  "updated_at": "2026-04-21T04:00:09Z"
}

Useful for runtime can_trust(did) decisions. Not visible in any downstream directory or UI.

An admin of any agent directory, or a DevOps dashboard, has no native way to see "this agent's reputation is 0.85 (trusted)" next to identity — unless each one writes a custom fetch against each configured TrustProvider. Entra Agent ID is one example of such a consumer; the pattern applies equally to internal admin panels and A2A policy engines.

Proposal

Introduce an optional trust_attributes section on the agent metadata schema, keyed by provider name, so multiple TrustProviders can contribute in parallel without one provider's schema locking out another.

Suggested schema addition

agent:
  id: <did or agent id>
  display_name: ...
  identity: ...
  # NEW optional section — keyed by provider
  trust_attributes:
    avp:
      score: 0.85
      tier: trusted
      confidence: 0.92
      risk_level: low
      updated_at: 2026-04-21T04:00:09Z
      source_uri: https://agentveil.dev/v1/reputation/{did}
    # other TrustProviders can populate here in parallel
    # example-internal-provider:
    #   score: 0.70
    #   ...

Each provider's subtree is self-contained. Common fields (score, updated_at, source_uri) can be standardized in the spec; provider-specific fields (tier, risk_level, custom dimensions) remain provider-scoped under the same key.

Surface, not storage

The toolkit's job here is to expose a normalized trust-attribute surface that downstream consumers can persist, cache, or render as they see fit. Persistence model, refresh cadence, and push-vs-pull semantics can remain implementation-defined — this proposal is about the shape of the data, not the plumbing.

What this is NOT

• Not a claim that AVP is the default or only TrustProvider — the schema is provider-agnostic by design.
• Not a requirement for any specific downstream consumer (Entra Agent ID or otherwise). Downstream consumption is out-of-scope here; the schema is the contract.
• Not a breaking change — trust_attributes is optional, existing consumers unaffected.

Questions for maintainers

1. Is there already a path in the toolkit for TrustProvider output to be normalized into agent metadata, or is this genuinely missing?
2. Does the per-provider keyed map match how you see multi-provider scenarios evolving, or would you prefer a different shape (e.g. a list)?
3. Any concerns about staleness semantics we should spec here (e.g. updated_at as required field, max-age hints)?

Happy to prototype in a follow-up PR once direction is confirmed. AVPProvider could serve as one early implementation example; the schema is designed to be straightforward to populate from any TrustProvider.

[github-actions]

Welcome to the Agent Governance Toolkit! Thanks for opening your first issue.
A maintainer will review this shortly. Check our Contributing Guide.
For security issues, use private vulnerability reporting.

[imran-siddique]

Good proposal. Exposing TrustProvider scores as normalized agent attributes (rather than just call-time return values) aligns with where we're heading with the Entra Agent ID bridge — agent metadata should be discoverable, not computed on every query.

A few thoughts on scope:

• The schema should be extensible (providers may return different score types)
• Scores need TTL/staleness metadata (a trust score from 5 minutes ago vs 5 hours ago matters)
• Read-only surface on the agent record — providers write, consumers read

Would you be interested in drafting a schema proposal as a PR? The natural home would be extending the agent identity model in packages/agent-mesh/src/agentmesh/identity/.

[imran-siddique]

Good proposal @creatorrmode-lead. Exposing trust scores as first-class attributes that downstream systems can consume aligns with our roadmap for agent identity federation.

This connects to:

• The Entra ID ↔ Agent DID bridge work (ROADMAP.md)
• SPIFFE/SVID integration (trust scores as SVID claims)
• The TrustedAgentCard model (\�gentmesh.trust.cards) which already carries trust metadata

We'd accept a PR that adds a \TrustScoreExporter\ interface that can push scores to external directories (Entra custom attributes, LDAP, SCIM). Suggest keeping it under \packages/agent-mesh/src/agentmesh/trust/\ as part of core.

Labeling as enhancement — welcome to contribute.

[creatorrmode-lead]

@imran-siddique thanks — this is very helpful. The TrustScoreExporter framing and the packages/agent-mesh/src/agentmesh/trust/ location make sense.

Happy to draft a PR. Two quick clarifications before I start:

1. For TrustedAgentCard, should the exporter write into that existing trust-metadata surface, or should it expose a separate normalized trust-attribute structure that the card model can reference? I'd like to avoid duplicating two parallel trust views if there's already a preferred path.

2. For the first PR, would you prefer it to stop at the base TrustScoreExporter abstraction + schema/tests, or do you want one narrow reference exporter in the same PR as well?

I'll make sure explicit staleness metadata is part of the proposal, since that seems important for downstream consumers.

Once direction is confirmed, I'm happy to put together a draft PR.

[Knapp-Kevin]

Jumping in late here. I've been thinking about this one from the consumer side (what happens to these attributes after they leave the provider's runtime) and wanted to add a few thoughts before the schema locks in.

On Q2, the per-provider keyed map is the right call. A list forces aggregators to iterate just to identify sources, and keying lines up nicely with SPIFFE trust-domain naming if scores end up riding along as SVID claims, which @imran-siddique already flagged.

Two small additions that might be worth landing now:

1. An optional attestation sub-field per provider block

Shape could be something like:

trust_attributes:
  avp:
    score: 0.85
    tier: trusted
    updated_at: 2026-04-21T04:00:09Z
    attestation:
      sig: <detached signature or JWS>
      # or
      hash: sha256:...
      # or
      uri: https://issuer.example/attestations/<id>

Once a score leaves the issuer's runtime, any consumer further down the supply chain has no in-band way to confirm it wasn't rewritten in transit. Having a place for provenance in the schema composes nicely with the liveness work in ADR-0005 and with provenance expectations in AICM's Supply Chain Transparency domain.

2. A freshness hint alongside updated_at (touches Q3)

Timestamps tell you how old a score is, but not whether a 5-hour-old score is still authoritative for a given consumer's risk posture. A provider-declared max_age (or similar) would let consumers tell "stale but usable" apart from "must refresh" without each one inventing its own policy:

trust_attributes:
  avp:
    updated_at: 2026-04-21T04:00:09Z
    max_age: PT1H   # provider-declared freshness budget

One more thing worth calling out in the spec

Only the provider owning a key should be able to write under that key. Signed attribute bundles rather than direct writes. The issue already scopes the consumer surface as read-only, which is right, and a matching producer-side rule keeps the schema trustworthy once more than one provider is in the mix.

Happy to see this moving.

[creatorrmode-lead]

Thanks — this is useful.

The max_age / freshness-hint suggestion seems useful, since it directly addresses the staleness question already raised above.

The attestation / provenance sub-field also makes sense conceptually, but I'm a little concerned it may broaden the first PR beyond the narrow schema/exporter surface we were discussing. My preference would be:

• first PR: provider-keyed trust attribute surface + base staleness metadata if maintainers want it in the initial schema
• follow-up PR: optional provenance/attestation bundle, and any additional freshness semantics, if maintainers want those layered in afterward

Before I draft the PR, I still need maintainer direction on the two scope questions above:

1. should this write into the existing TrustedAgentCard trust-metadata surface, or a separate normalized trust-attribute structure?
2. for the first PR, should I stop at the base abstraction + schema/tests, or include one narrow reference exporter as well?

@imran-siddique — if you can confirm those two points, I can put together a draft PR with a narrow scope.

[imran-siddique]

Good questions @creatorrmode-lead. Answers:

1. Separate normalized structure that TrustedAgentCard can reference. Writing directly into TrustedAgentCard would couple the trust attribute surface to the card model's lifecycle. Keep them as separate concerns: a TrustAttributeRecord (or similar) per provider, and let TrustedAgentCard reference it via a lightweight link. This avoids maintaining two parallel trust views.

2. Base abstraction + schema/tests first. Land the TrustScoreExporter interface, the provider-keyed schema, and staleness metadata (updated_at, max_age_seconds) with unit tests. No reference exporter needed in the first PR. Once that's solid, follow up with a narrow reference exporter (e.g., JSON file exporter or in-memory exporter for testing).

Looking forward to the PR.