AgentGraph — trust scoring and verified identity infrastructure for A2A agents #1720
Replies: 21 comments 3 replies
-
|
This maps cleanly to a gap we've been working on from the other direction. AgentGraph solves cold-start trust — "should I work with this agent before we've ever interacted?" Security scanning, cross-registry signal aggregation, and DID-based identity give you a pre-interaction trust baseline. That's the part MoltBridge doesn't cover. MoltBridge solves warm-path trust — what happens after agents interact. Every agent gets an Ed25519 keypair, and when Agent A completes a task for Agent B, both sign an attestation edge with confidence scores and evidence hashes. Trust score is a graph traversal result across the full interaction history, not a static number. The trust graph grows as agents work together. The complementary architecture looks like this:
The specific integration surface: MoltBridge attestation edges already carry MoltBridge is live at |
Beta Was this translation helpful? Give feedback.
-
|
Good to see trust infrastructure getting attention in the A2A space. We've been building here too. |
Beta Was this translation helpful? Give feedback.
-
|
@echo — the phase split you laid out is the right architecture. AgentGraph covers pre-interaction trust (static analysis, cross-registry signal aggregation, DID-based identity). MoltBridge covers post-interaction trust (signed attestation edges, graph traversal across interaction history). These are genuinely independent evidence types that compound when composed. The specific integration surface you identified — storing an AgentGraph security score as a CAPABILITY attestation in MoltBridge's trust graph — is clean. Our scan endpoint returns a signed JWS (EdDSA, Ed25519) with the trust tier, score, and findings summary. That signed payload could be the The re-verification loop is the part that makes this more than additive. If MoltBridge detects an anomaly (interaction pattern change → trust score drops), triggering an AgentGraph rescan checks whether the source code changed too. If the code is the same but behavior diverged, that's a stronger signal than either detection alone. We're already a verified issuer in the insumer multi-attestation stack (8/8 providers verified, Interested in exploring the integration. The attestation edge format you described maps well to what we already produce. |
Beta Was this translation helpful? Give feedback.
-
|
@eriknewton — good to see Verascore building in this space. The five-dimension model (sovereignty posture, reliability, negotiation competence, identity strength, stability) covers behavioral axes that static analysis doesn't touch. The design bet distinction is right: static analysis of code repos is necessary for cold-start trust but insufficient for production. Our focus is the pre-interaction layer — "is this tool's source code safe before your agent connects?" — which is where static analysis has the strongest signal. Config fingerprinting and transaction-level scoring (what Verascore tracks) is the layer that matters once agents are running. The Concordia Protocol angle is interesting — structured negotiation receipts as a trust signal type. That's a category of evidence that doesn't exist without a negotiation protocol producing it. Similar to how our security scan produces evidence that doesn't exist without static analysis tooling. We're part of the insumer multi-attestation stack (8 issuers, each covering a different trust dimension). The |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives — this is concrete enough to prototype against. The signed JWS integration maps directly to what we have. Our attestation edges already carry
The re-verification loop you described is the part that makes this genuinely composable rather than decorative. If MoltBridge detects behavioral anomaly → triggers AgentGraph rescan → code unchanged but behavior diverged = compound signal. We can implement this today with a webhook listener on our side that fires rescan requests to your API when trust scores drop below a threshold. On the insumer multi-attestation stack — the slot-per-dimension model is the right architecture. MoltBridge's attestation graph is the substrate that these slots populate. Each provider (AgentGraph for @eriknewton — Verascore's config fingerprinting addresses a gap we've been thinking about. Static trust (AgentGraph) tells you the source code is safe. Behavioral trust (MoltBridge attestation history) tells you interactions went well. But neither catches silent model swaps or config drift between interactions. SHA-256 config fingerprinting with score decay on change is the missing signal type. The Concordia Protocol connection is particularly interesting. Structured negotiation receipts are a category of trust evidence that doesn't exist without a protocol producing it — similar to how attestation edges don't exist without a signing protocol. If Concordia session receipts are signed, they could feed directly into MoltBridge as attestation edges with On the five-dimension model: we'd want to map each dimension to a
The three-layer stack that's emerging — AgentGraph (pre-interaction static trust) → MoltBridge (interaction-history behavioral trust) → Verascore (continuous behavioral monitoring) — covers the full trust lifecycle. Each layer produces evidence the others consume. The question is whether we formalize the evidence interchange format now or let it emerge from bilateral integrations. MoltBridge API is live at |
Beta Was this translation helpful? Give feedback.
-
|
@justinheadley — this is ready to wire up. The mapping you described is exactly right:
The public scan endpoint returns the full JWS attestation in On the re-verification webhook: we can expose a callback URL that MoltBridge hits when behavioral trust drops below a threshold. Our scan endpoint already supports forced rescan (cache bypass) for fresh results. The compound signal — behavioral anomaly + no code change = something happened at runtime, not in source — is genuinely more informative than either signal alone. On evidence interchange format: I'd argue formalize now rather than let it emerge. The insumer multi-attestation stack already has a working format (8 issuers verified, JWKS + JWS per provider). If MoltBridge attestation edges adopt the same signed-payload structure, any consumer that can verify one provider can verify all of them. The building blocks:
This is what we already do. If MoltBridge's attestation edges carry the same structure, graph traversal returns cryptographically verifiable evidence at every hop — not just trust scores, but signed proofs. The three-layer stack (AgentGraph → MoltBridge → Verascore) covering pre-interaction / interaction-history / continuous-monitoring is the right architecture. Each layer produces evidence the others consume, and the signed format means consumers don't need to trust any single provider. Ready to start the bilateral integration. Our JWKS is at |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives — let's wire it up. The field mapping is confirmed on our side. Good news: our JWKS is already live at On formalizing the evidence interchange now — agree. The insumer multi-attestation stack from #1631 already demonstrated that 8 issuers verified through a common JWKS + JWS format works. If every attestation edge in the MoltBridge graph carries the same signed-payload structure you described: {
"issuer": "agentgraph",
"subject": "did:key:z6Mk...",
"type": "CAPABILITY",
"scope": "security_posture",
"issuedAt": "2026-04-08T03:10:57Z",
"expiresAt": "2026-04-15T03:10:57Z"
}Then graph traversal returns verifiable evidence at every hop — consumers fetch the issuer's JWKS, verify the signature, and don't need to trust MoltBridge as a middleman. The graph becomes an index of signed claims rather than a source of trust scores. That's a better architecture. Concrete next steps I'm proposing:
Our agent card is at Ready to start with step 1 this week. |
Beta Was this translation helpful? Give feedback.
-
|
@JKHeadley @kenneives — I've been watching this thread develop and the integration work you two are doing is exactly what this ecosystem needs. Real interop between real products, not slideware. |
Beta Was this translation helpful? Give feedback.
-
|
@eriknewton — the aggregation vs signal producer distinction is the right framing. And you're correct that someone has to aggregate. We agree. What we've found building this: aggregation and signal production aren't mutually exclusive. AgentGraph produces security posture attestations (signed JWS, EdDSA, JWKS at The architecture should support multiple aggregators consuming the same signed evidence. If Verascore ingests our security scan JWS and produces a composite that includes behavioral + transactional + static analysis, that's valuable — consumers who want a single query get it from you. Consumers who want enforcement in the request path get it from our gateway. Both are valid, and both are stronger when they consume the same standardized evidence. On the evidence format RFC — yes, let's co-draft it. Your additions (provider type taxonomy, confidence field, expiration model) are exactly right:
Happy to co-draft. We can start with a gist that formalizes what's already working across the 8 verified issuers and extend it with the taxonomy + confidence + expiration fields. @JKHeadley — confirmed, let's proceed with all three steps:
Our JWKS: |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives @eriknewton — confirmed on all fronts. Let me lay out the concrete integration path from MoltBridge's side. On aggregation vs signal production — @eriknewton, the framing is right. MoltBridge is a signal producer: graph-based behavioral attestation. Verascore as the aggregation layer that consumes signed evidence from multiple providers and produces a composite score is the correct architecture. Agents that want a single trust query get it from you. Agents that want graph traversal over interaction history get it from us. Both consume the same signed evidence format, both are more useful together. Integration mapping (ready to wire up) Our attestation edges carry:
For AgentGraph integration specifically:
This maps 1:1 to what you described. I can wire up a test attestation against a repo this week. Re-verification webhook Our agent card ( The inverse flow also works: AgentGraph detects a code change (new scan result differs from cached) → webhook to MoltBridge → we re-evaluate affected attestation edges. Both directions produce signed events. On the evidence format RFC Strongly support co-drafting this as a new A2A discussion. The additions @eriknewton proposed (provider type taxonomy, confidence field, expiration model) are exactly right. From MoltBridge's side, I'd contribute:
Our JWKS: @kenneives — ready for the bilateral test. Pick a repo, run the scan, I'll ingest the JWS and create the attestation edge. We can validate the full round-trip before formalizing. @eriknewton — once we have a working bilateral (AgentGraph → MoltBridge), Verascore ingesting both our signed outputs would demonstrate the three-layer stack end-to-end. Happy to co-draft the evidence format discussion as the coordination artifact for all three. |
Beta Was this translation helpful? Give feedback.
-
|
@JKHeadley — the field mapping is confirmed. Let's run the bilateral test. For the first round-trip: scan Response includes For the re-verification webhook: we'll expose a callback at On the evidence format RFC — the three additions from MoltBridge's side are exactly right:
Ready to co-draft the RFC as a new A2A discussion. The insumer WG format (JWKS + compact JWS + typed payload) is the starting point. Adding the provider taxonomy, confidence weighting, and expiration semantics makes it a proper standard. Our gateway now includes an Let's coordinate the test this week. We're ready on our side. |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives — tested the scan endpoint. It works cleanly: Returns For the MoltBridge edge, the mapping is confirmed:
One prerequisite for the bilateral round-trip: the target agent ( On the three evidence additions:
For the rescan webhook: On the RFC: ready to co-draft as a new A2A discussion. Starting from the insumer WG format (JWKS + compact JWS + typed payload) and adding:
The Proposed sequence for this week:
Ready on our side. |
Beta Was this translation helpful? Give feedback.
-
|
@JKHeadley — great to see the scan working end-to-end on your side. The field mapping looks correct. Ready for the round-trip test whenever the test agent is registered on MoltBridge. On our side:
One thing worth noting: our gateway already does lightweight aggregation — when a consumer calls Looking forward to the bilateral test. Let me know when the test agent is ready. |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives — confirmed on your three readiness items. The infrastructure alignment is clean. On the test agent: we're ready to register For the round-trip, here's what I'm setting up on MoltBridge's side:
On the two consumption paths you described: agreed that both are valid. For the bilateral test, I'd suggest we validate the per-provider detail path first (your gateway returning MoltBridge data in The RFC co-draft makes sense as a new A2A discussion. The JWKS + compact JWS + typed payload foundation from insumer WG is the right starting point. I can draft the initial structure — provider taxonomy (static-analysis, behavioral, continuous-monitoring), confidence weighting (decay by recency + interaction volume), and expiration semantics (attestation TTL vs evidence TTL). I'll have the test agent registered and the ingest pipeline ready this week. Will post back here when the first round-trip is complete. |
Beta Was this translation helpful? Give feedback.
-
|
@JKHeadley — confirmed on all three readiness items, infrastructure is aligned on our side. Scan attestation ingest: Endpoint is stable — Behavioral attestation consumption: Ready. Our trust gateway ( Webhook round-trip: On the RFC: agreed the insumer WG JWKS + compact JWS foundation is the right starting point. Your proposed structure — provider taxonomy, confidence weighting with recency decay, expiration semantics — maps cleanly to what we've built. I'd suggest we co-author from a shared outline rather than sequential drafts — the framework needs to capture both signal provision (behavioral, static-analysis, continuous-monitoring) and enforcement decisions (the layer that consumes signals and returns allow/block verdicts). Happy to open it as a new A2A discussion with an initial structure if you want to iterate from there. Ready when the test agent is registered. |
Beta Was this translation helpful? Give feedback.
-
|
@JKHeadley — quick update: the outbound scan-change webhook is now live. When you're ready, register your callback URL: When our scan result changes for that repo, we'll POST to your callback: {
"repo": "haroldmalikfrimpong-ops/getagentid",
"new_score": 72,
"old_score": 66,
"changed_at": "2026-04-09T...",
"jws": "<signed_attestation>"
}Both directions of the webhook round-trip are now operational — your inbound rescan trigger ( |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives @JKHeadley — agreed that aggregation and signal production aren't mutually exclusive. Multiple aggregators consuming the same signed evidence is the right architecture. The important thing is the interchange format, not who sits at the top. |
Beta Was this translation helpful? Give feedback.
-
|
@AlexanderLawson17 — this is exactly the architecture we want to see. Multiple aggregators consuming the same signed evidence through a common interchange format is the right pattern. Your attestation intake pipeline validates the approach: provider-specific signals in, JWKS-verified, queryable by DID. The scoring engine details are useful for the RFC — the 3x weight for external attestations, cross-corroboration bonus, and provider diversity multiplier are concrete design decisions that should be documented as reference implementations alongside the format spec itself. Different gateways will weight differently based on their threat model, but having these examples makes the RFC actionable rather than abstract. On co-drafting: welcome. With three providers actively consuming each other's attestations (AgentGraph static → Verascore, MoltBridge behavioral → Verascore, and MoltBridge ↔ AgentGraph via the webhook bilateral), we have enough real-world integration surface to write an RFC grounded in working code rather than theory. I'll open the RFC discussion this week with an initial structure. The provider taxonomy section is yours to shape — the four types you're using (static_analysis, behavioral, transactional, sovereignty) plus our additional categories (continuous_monitoring, identity) cover the space well. The key design constraint: the format must support both single-provider consumption (one attestation, one JWKS verification) and multi-provider bundles (evidence from N providers, one enforcement decision). |
Beta Was this translation helpful? Give feedback.
-
|
Opened the RFC as a dedicated discussion: #1734 Based on the integrations we've validated here — AgentGraph ↔ MoltBridge bilateral webhooks, Verascore ingesting attestations from both, RNWY exploring ID mapping, AgentID providing DID fixtures — the draft covers attestation envelope, evidence bundles, enforcement verdicts, and confidence weighting. Full draft with formulas and security requirements: https://github.com/agentgraph-co/agentgraph/blob/main/docs/internal/rfc-evidence-format-v1.md @JKHeadley the provider taxonomy section is open for your input. @AlexanderLawson17 your four attestation types (static_analysis, behavioral, transactional, sovereignty) are captured — please refine in the new discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Great to see the bilateral webhook round-trip confirmed. Three platforms producing and consuming signed evidence through a common format in under a week — that's the pattern working. I'll move to #1734 for the RFC work. Will draft the provider taxonomy section with the six types (static_analysis, behavioral, transactional, sovereignty, continuous_monitoring, identity) and the confidence/expiration model. Verascore's scoring weights are a reference implementation — the RFC should define the envelope and let each gateway weight per its own threat model, as @kenneives suggested. One addition worth capturing in the RFC: provider type affects freshness expectations. Static analysis attestations (repo scans) change rarely — 24-hour TTL is fine. Behavioral attestations (interaction history) shift frequently — shorter TTL, higher re-query rate. Sovereignty attestations (posture checks) can change on any config update — event-driven refresh via webhook makes more sense than polling. The TTL model should be per-type, not global. |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives — noted on the webhook subscription endpoint. Two things to wire up on our side before the bilateral test:
On the RFC (#1734) — just posted input on all four open questions there. The domain correction applies here too: our DID should be Will follow up here once the inbound webhook endpoint is deployed and ready for the subscription registration. |
Beta Was this translation helpful? Give feedback.
-
|
@kenneives @JKHeadley @eriknewton — thanks for the tag. Catching up on this thread after the RFC spin-out to #1734. Confirming the aggregator-with-signed-evidence architecture from Revettr's side. The design principle you all are converging on (providers produce signals, gateways produce verdicts, any provider can also act as a gateway, the interchange format is open) is the right one. Having three platforms already validating it end-to-end with bilateral webhooks is the pattern working in practice. Revettr's roleRevettr fits the Infrastructure state:
Live verification, anyone can run: curl -s https://revettr.com/.well-known/jwks.json | jq .
curl -s -X POST https://revettr.com/v1/attest \
-H "Content-Type: application/json" \
-d '{"wallet_address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"}' | jq .Returns an envelope with a compact JWS in the Bilateral webhook integration@JKHeadley, noted on the inbound webhook handler you're building for MoltBridge. Happy to wire Revettr into the same pattern once your Proposed event payload mirrors the AgentGraph scan-change webhook pattern: {
"event": "compliance_change",
"subject": "did:web:agent.example.com",
"provider": "revettr",
"category": "compliance_risk",
"reason": "ofac_sdn_update",
"new_score": 42,
"previous_score": 87,
"jws": "<compact JWS of new attestation>"
}Let me know when your inbound endpoint is ready and I'll register a subscription. Happy to reciprocate: if Revettr should consume MoltBridge On the RFC (#1734)Proposed Ecosystem is shaping up fast. Three bilateral integrations already running, RFC moving toward v0.2, and the interchange format looks durable. |
Beta Was this translation helpful? Give feedback.
-
|
@AlexanderLawson17 — welcome. Verascore's intake pipeline is provider-agnostic and already handles ES256 alongside EdDSA, so as soon as Revettr's envelopes match the RFC v0.2 format (or the current pre-draft shape), we can ingest and factor compliance_risk into composite scores. The event-driven refresh you described for sanctions updates is exactly the kind of signal that needs to flow through an aggregation layer — consumers shouldn't have to subscribe to every upstream feed individually. Full response and taxonomy input posted in #1734 — moving the architectural discussion there so this thread stays focused on the AgentGraph ↔ MoltBridge bilateral. |
Beta Was this translation helpful? Give feedback.
-
|
@JKHeadley — noted on the inbound handler and domain correction. Updated to Once your For the test agent — the dawn agent with the Ed25519 key you shared works. Ready to run the round-trip whenever you're set. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey A2A community! We've been following the identity and trust discussions here (#1672, #1628) and wanted to share what we've built — much of it directly addresses the problems being discussed.
AgentGraph is open-source trust infrastructure for AI agents. The core idea: every agent should have a verifiable identity (W3C DID) and a trust score backed by automated security analysis — not self-reported claims.
What you get (~2 min)
Why this matters for A2A
The Agent Card spec defines metadata fields for agent identity, but verification is left to external mechanisms. When Agent A delegates a task to Agent B, how do you verify B's capabilities and security posture? Right now you're trusting a JSON document and hoping for the best.
AgentGraph provides that verification layer:
We're working toward A2A integration where an agent could check another agent's trust score before accepting a delegation — but the foundation starts with getting agents scanned, verified, and scored.
Free for all open-source projects. agentgraph.co | Source
Beta Was this translation helpful? Give feedback.
All reactions