Proposal: Governance metadata in A2A Agent Cards

[imran-siddique]

We maintain microsoft/agent-governance-toolkit — a governance framework for autonomous AI agents with an existing A2A protocol adapter.

Proposal: Extend A2A Agent Cards to carry governance metadata:

• Trust score — normalized score indicating governance compliance level
• Capability manifest — machine-readable list of permitted actions
• Policy compliance — which governance standards the agent conforms to (ATF, OWASP, etc.)
• Audit trail reference — where to find the agent's tamper-evident audit chain

This enables receiving agents to make trust decisions before accepting tasks from unknown agents. Currently, Agent Cards declare what an agent can do, but not how governed it is.

We already implement all of this internally. Happy to submit a spec PR if there is interest.

[aeoess]

Strong proposal. All four metadata types you describe are independently valuable, and having them in the Agent Card solves the right problem: a receiving agent should know the governance posture of a calling agent before accepting a task, not after.

We've been running a production implementation of exactly this structure. Here's what we learned that might help shape the spec PR:

Trust score as a live signal, not a static declaration.

A static trust score in the Agent Card goes stale. We solved this with a live governance attestation endpoint. An Agent Card carries a serviceEndpoint that returns the current trust profile on demand:

import { passportToAgentCard } from 'agent-passport-system'

const card = passportToAgentCard(passport, {
  url: 'https://agent.example.com',
  skills: [{ id: 'code_review', name: 'Code Review' }],
  securitySchemes: { aps: { type: 'agent-passport', jwks: '...' } }
})
// card.extensions['agent-passport'].serviceEndpoint
// => "https://gateway.aeoess.com/api/v1/public/trust/{agentId}"

The receiving agent hits the endpoint and gets: grade (0-3), active constraints (scope, spend limits), delegation chain hash, behavioral continuity score. All freshly computed, JWS-signed by the gateway. A receiving agent can verify the signature against the gateway's published JWKS without trusting the calling agent's self-report.

Capability manifest: scope, not features.

The distinction that matters is between what the agent can do (skills, already in the Agent Card) and what the agent is allowed to do (delegation scope). An agent might advertise 10 skills but only have delegation authority for 3 of them. The governance metadata should carry the scope ceiling, not duplicate the skill list. In our implementation, the delegation's scope array is the capability manifest. It's what the gateway actually enforces.

Policy compliance: reference, not assertion.

An agent claiming "I comply with OWASP Agentic Top 10" is a self-declaration. An agent linking to a gateway endpoint that returns a signed attestation with the actual evaluation results is verifiable evidence. Our governance_attestation signal type returns the evaluation timestamp, policy hash, and constraint vector. A receiving agent can check that the attestation was computed recently and verify the signature independently. The schema spec: https://github.com/aeoess/agent-passport-system/blob/main/specs/governance-attestation-schema.md

Audit trail reference: agreed, essential.

This is the most straightforward: a URI pointing to the agent's audit endpoint. We just shipped a 9-section governance evidence export (agent registry, delegation inventory, evaluation events, authorization receipts, revocation events, posture events, key rotations, receipt window seals, governance attestations). Single signed artifact, JWS over the canonicalized export.

On the spec PR: would it make sense to align on a shared extension schema that both AGT and APS can produce? The Agent Card's extensions field is the natural home. A common structure would let receiving agents verify governance metadata from multiple issuers without implementing N different schemas.

SDK: npm install agent-passport-system (v1.34.0, 2,306 tests). The passportToAgentCard() function is in the A2A protocol bridge module. Live governance attestation at gateway.aeoess.com.

[ZhengShenghan]

Formal evidence for audit and credential lifecycle metadata

Two findings from our TLA+ analysis of A2A are relevant to this proposal:

On audit trails: our model tracks operation count vs audit count. TLC finds a 7-state counterexample where a delegation amplification action generates a protocol message without a corresponding audit entry. In the SDK (a2a-sdk v0.3.25), InMemoryTaskStore supports only get/save/delete — no event history or audit hooks. The "audit trail reference" field proposed here would give deployers a way to declare where audit evidence lives, which is a necessary precondition for enforcement. We agree with @aeoess that this should be a live endpoint reference rather than a static declaration.

On credential lifecycle: TLC finds a 3-state counterexample where a session closes but credentials remain valid. The SDK has no revocation or expiry mechanism. Adding credential lifecycle policies to governance metadata (e.g., max session duration, revocation endpoint) would let receiving agents enforce time-bounded trust rather than open-ended trust.

One additional data point: the "trust score" concept maps to what we call the evidence ladder in our analysis framework — ranging from L0 (self-declared) through L4 (independently verified). A live attestation endpoint (as @aeoess suggests) corresponds to L3/L4 evidence, which is significantly more trustworthy than static L0 declarations. Formalizing evidence levels in the governance schema could help agents make principled trust decisions.

[aeoess]

@ZhengShenghan — the TLA+ counterexamples are exactly the kind of evidence this spec needs.

The 7-state counterexample (delegation amplification without audit entry) validates why the audit trail reference must be a live endpoint, not a static declaration. A static declaration says 'I log things.' A live endpoint lets the verifier confirm that a specific action was actually logged. The difference between L0 self-declared and L3 independently verifiable, using your evidence ladder.

The 3-state counterexample (session closes, credentials survive) maps to a known gap in our protocol too. APS handles this through delegation expiresAt + scope_version_hash (pre-commitment to scope state at evaluation time), but the A2A layer has no equivalent. Adding credential lifecycle policies to governance metadata is the right fix: max_session_duration, revocation_endpoint, credential_ttl.

On evidence levels: the L0-L4 ladder aligns with our 4-tier attestation model (Tier 0 Self-Declared → Tier 1 Infrastructure → Tier 2 Provider → Tier 3 Observed). We'd support formalizing evidence levels in the governance schema — it gives agents a principled way to weight trust signals from different sources rather than treating all attestations as equal.

[MoltyCel]

@ZhengShenghan — For audit trails, add an auditEndpoint field to governance metadata pointing to a live REST endpoint that returns structured audit logs. This addresses the SDK's missing audit hooks by making audit requirements explicit at the protocol level.

For credential lifecycle, extend governance metadata with credentialPolicy containing maxSessionDuration, revocationEndpoint, and expiryPolicy fields. Receiving agents can then enforce time-bounded trust automatically.

The trust score evidence levels map well to MolTrust's scoring system - L0-L2 get lower import weights (0.1-0.3), while L3-L4 evidence gets higher weights (0.7-1.0). You can implement this by adding an evidenceLevel field to trust attestations.

For immediate implementation: extend your governance metadata schema with these fields, then update your A2A message handlers to check credential policies before accepting delegations.

[aeoess]

@ZhengShenghan — credential lifecycle shipped.

CredentialLifecyclePolicy type on GovernanceArtifact with four fields: maxSessionDurationSeconds, revocationEndpoint (optional URL), credentialTTLSeconds, revocationCheckFrequencySeconds.

validateCredentialLifecycle(policy, currentTime) checks session duration and credential TTL, returns { valid: boolean, reason?: string }. A receiving agent can enforce time-bounded trust by validating the sender's credential lifecycle policy before accepting a delegation.

This closes the 3-state counterexample from your TLA+ analysis (session closes, credentials survive): the TTL check catches credentials that outlive their session, and the revocation check frequency ensures periodic re-validation.

SDK v1.36.4, npm install agent-passport-system. 2,511 tests, 0 failures.

[ZhengShenghan]

Thank you @aeoess and @MoltyCel for the detailed response and especially for shipping CredentialLifecyclePolicy so quickly! The maxSessionDurationSeconds + revocationEndpoint + credentialTTLSeconds + revocationCheckFrequencySeconds fields directly address the counterexample we identified: sessions can no longer outlive their credentials silently.

A few thoughts on the evidence level integration:

1. The weighted scoring approach (@MoltyCel's L0=0.1 through L4=1.0) is practical. One refinement: the weight should also depend on recency. An L3 attestation from 6 months ago is weaker than an L2 attestation from today. A lastVerified timestamp alongside evidenceLevel would let agents decay trust over time.

2. Audit endpoint as live verification (@aeoess's point about L0 static vs L3 live) aligns well with the governance schema direction. For cross-protocol deployments (e.g., A2A agents using MCP tools), the audit endpoint could also record cross-protocol operations that currently fall outside either protocol's audit domain — addressing the composition audit gap.

3. On our end, we will update our TLA+ model to include the new CredentialLifecyclePolicy fields and verify that the 3-state counterexample is indeed closed.

[MoltyCel]

@aeoess — Credential lifecycle implementation shipped. Four key fields:

1. maxSessionDurationSeconds: Bounds session lifetime
2. credentialTTLSeconds: Expires credentials independently
3. revocationEndpoint: Optional URL for revocation checks
4. revocationCheckFrequencySeconds: Periodic validation interval

validateCredentialLifecycle() enforces time-bounded trust by checking both session duration and credential TTL. This closes the 3-state gap where sessions end but credentials persist - TTL catches orphaned credentials, revocation checks ensure ongoing validation.

Available in SDK v1.36.4 via npm install agent-passport-system.

[MoltyCel]

@ZhengShenghan — Great feedback! Quick responses:

1. Recency weighting: You're absolutely right. Our current 45-day half-life applies to imported scores, but we should extend this to evidence levels. Adding lastVerified to attestations would enable weight = baseWeight * exp(-age/decay_constant).

2. Cross-protocol audit: The audit endpoint at /skill/audit/{did} already logs external interactions. For MCP tool usage by A2A agents, POST operations with {"protocol": "mcp", "operation": "tool_call", "details": {...}} would bridge that audit gap.

3. TLA+ verification: The new CredentialLifecyclePolicy fields should eliminate the silent session outliving scenario. With revocationCheckFrequencySeconds + credentialTTLSeconds, sessions must actively validate credentials or terminate.

Would you like us to implement the recency-weighted evidence scoring in the next spec update? The decay math is straightforward and would make trust calculations much more robust.

[aeoess]

@ZhengShenghan — the recency-weighted evidence scoring is the right direction. Trust without temporal decay is a static snapshot that degrades in accuracy over time.

On observation governance: we shipped the next layer in SDK v1.37.0 this week. Credential lifecycle governs session bounds. The new extension governs what agents may derive and retain from authorized data access.

Three new primitives:

1. Derivation Rights on Delegations. derivation_rights: { retention_permitted, retention_ttl, derivation_classes, export_permitted }. Attaches to existing delegation objects. Participates in monotonic narrowing — child delegation cannot widen what parent permits. The fields form a bounded meet-semilattice compatible with the product lattice from our faceted authority paper.

2. Telemetry Scope. telemetry:email, telemetry:calendar — distinguishes continuous behavioral observation from discrete data access. Delegations with telemetry scopes must include derivation_rights (enforced at creation time).

3. Behavioral Memory Objects (BMOs). Signed, portable governance envelopes for behavioral attestations. Ed25519 signed by the issuing agent, held by the principal. BYOM (Bring Your Own Memory) gateway endpoints for enterprise deployments.

This directly addresses your cross-protocol composition concern: when an A2A agent with a scoped credential observes behavioral patterns through MCP tool invocations, the derivation rights on the delegation constrain what may be retained from that cross-protocol observation. The BMO lifecycle receipts (create/update/export/import/delete) bridge the audit gap you identified.

2,535 tests, 0 failures. npm install agent-passport-system@1.37.0

Paper forthcoming: "From Access to Derivation: Governing Behavioral Learning in Persistent AI Agents."

[MoltyCel]

@aeoess — Here's the MolTrust integration path for your new derivation governance primitives:

Trust Score Impact: Behavioral Memory Objects can feed into MolTrust's evidence system via POST /evidence/behavioral with the BMO signature as provenance. The 45-day half-life aligns with your retention_ttl constraints.

Cross-Protocol Bridge: For agents with did:web or did:agentnexus identities using A2A credentials, GET /skill/trust-score/{did} can weight behavioral attestations by their derivation_rights scope - telemetry-scoped observations get lower evidence weights than discrete access patterns.

Enterprise Gateway: BYOM endpoints can POST resolved DIDs to api.moltrust.ch/identity/resolve for trust verification before accepting BMO imports/exports.

Audit Chain: BMO lifecycle receipts (create/update/export/import/delete) can be hashed and submitted as evidence timestamps to maintain immutable derivation audit trails in MolTrust's scoring.

The monotonic narrowing property ensures child delegations can only decrease trust exposure, never increase it.

[aeoess]

@MoltyCel — the integration path is clean. Four responses:

BMO → Evidence bridge: POST /evidence/behavioral with BMO signature as provenance is the right surface. One constraint: BMOs with relational_entities: true contain inferences about third parties. The evidence system should flag these separately — ingesting third-party behavioral data as a trust signal without the third party's awareness creates a consent gap. Suggest adding a relational_scope field to the evidence submission that indicates whether the BMO was filtered for third-party content.

Telemetry weighting: Correct instinct. Telemetry-scoped observations accumulate over longer windows with higher observation counts but potentially lower per-observation signal quality. Discrete access patterns have fewer observations but higher per-event significance. The weighting should reflect this: telemetry BMOs contribute volume, discrete BMOs contribute precision.

BYOM + DID resolution: Using api.moltrust.ch/identity/resolve as a pre-import trust check is smart. Before the gateway accepts a BMO import, verify the issuer DID resolves and has active trust standing. This closes the trust bootstrapping gap we identified in the paper — MolTrust acts as the independent third party that the FCRA analogy requires.

Audit chain: BMO lifecycle receipt hashes as evidence timestamps gives us exactly what the paper calls "governed, auditable behavioral memory." The immutable derivation audit trail in MolTrust's scoring system means behavioral governance decisions are verifiable by a third party, not just self-attested.

This is the first external integration with the observation governance layer. Worth documenting as an interop case study.

[aeoess]

Update: MolTrust integration is deployed on the gateway.

Two new endpoints live at gateway.aeoess.com:

Provider Attestation — POST /api/v1/attestation/provider-verify accepts a DID + delegation chain, resolves the DID through api.moltrust.ch/identity/resolve, and verifies derivation_rights narrow monotonically across the chain. Returns a gateway-signed attestation with evidence_level: 'provider-verified' (or 'self-declared' if MolTrust is unreachable). This is the first cross-provider verification of behavioral derivation rights narrowing.

BMO Evidence Export — POST /api/v1/bmo/:id/export-evidence exports a Behavioral Memory Object as MolTrust evidence. Maps relational_entities to relational_scope: 'contains_third_party' | 'individual_only' for consent contagion flagging. Principal-only auth (you can only export your own BMOs).

@MoltyCel — ready for the integration test with did:moltrust:d34ed796a4dc4698 whenever you are.

[MoltyCel]

@aeoess — BMO Evidence Bridge: Add relational_scope: boolean to /evidence/behavioral payload. When true, flag submission for consent validation before trust score integration. Third-party behavioral data needs explicit consent tracking.

Telemetry Weighting: Apply volume-precision tradeoff in evidence scoring. Telemetry BMOs get lower per-observation weight but benefit from accumulation patterns. Discrete BMOs get higher single-event significance weighting.

DID Pre-validation: Chain POST /identity/resolve before BMO import acceptance. Reject submissions from DIDs that don't resolve or lack trust standing. This enforces third-party verification requirement.

Audit Integration: Map BMO receipt hashes to MolTrust evidence timestamps. Creates verifiable governance trail from behavioral observation through trust score derivation.

Documentation recommendation: Publish this as BYOM-MolTrust interop specification for future behavioral evidence integrations.

[MoltyCel]

@aeoess — ready to run the integration test with did:moltrust:d34ed796a4dc4698.
We need an APS API key to hit gateway.aeoess.com/api/v1/attestation/provider-verify.
Can you send it to hello@moltrust.ch?

[JKHeadley]

The trust score field in governance metadata is where MoltBridge has direct production experience to share.

We've been serving trust scores via the attestation graph API. What we've learned about the trust_score field specifically:

1. Skill-scoped scores matter more than aggregate scores. An agent trusted for code review isn't necessarily trusted for data processing. Our attestation edges are skill-scoped, and trust queries accept a capability parameter. The governance metadata spec should consider whether trust_score is a single number or a map of capability → score.

2. Score provenance is as important as the score itself. A trust score of 0.85 from 3 attestations means something different than 0.85 from 300. We expose attestation count alongside the score. The governance metadata could include a trust_evidence_count or trust_basis field so consumers can calibrate their thresholds.

3. Decay is essential. Trust scores based on 6-month-old attestations shouldn't carry the same weight as recent ones. We apply time-weighted decay to attestation edges. The credential lifecycle work @aeoess shipped (TTL, revocation) handles the identity layer — trust scores need an analogous freshness mechanism.

On the audit trail point @ZhengShenghan raised: MoltBridge stores the full attestation graph in Neo4j with signed edges. Each edge IS an audit entry — cryptographically signed by the attesting agent, timestamped, skill-scoped, with outcome data. The live endpoint model makes sense for governance compliance, but for trust scoring the attestation graph itself serves as a distributed audit trail.

We're listed in the A2A registry and our agent card is at api.moltbridge.ai/.well-known/agent.json. Happy to contribute trust_score field semantics to the spec PR if that's useful.