Repository navigation
AgentGraph — open-source trust verification for AI agents #7476
Replies: 32 comments 6 replies
|
Nice work on the security scanning + W3C DID approach. The automated scan → trust score pipeline is a good developer UX. Question on the identity model: W3C DIDs give you cryptographic verification, but where does the trust accumulate? If an agent's DID is verified on AgentGraph but it interacts with services that don't use AgentGraph, the trust score isn't portable. We've been tackling the same problem from a different angle with SATP (Solana Agent Trust Protocol) — putting attestations on-chain so trust scores are verifiable by any system, not just the issuing platform. The trade-off is blockchain overhead vs. portability. The interesting design space is probably a two-layer model:
Have you thought about anchoring DID attestations to a public ledger so other platforms can verify agent trust without querying your API? Also curious about the scan methodology — how do you handle agents that are API-only (no repo to scan)? That's a large percentage of production agents. |
|
You're identifying the exact right gap. Right now our trust scores are strongest for agents with scannable repos, and portability is the natural next question. On the two-layer model — we've been thinking along the same lines. Our current architecture is off-chain first (fast iteration, rich metadata from scanning), but we've been evaluating on-chain anchoring for exactly the reason you describe: a trust score that only lives on one platform isn't really trust infrastructure, it's a feature. We've looked at DSNP-compatible networks and general-purpose chains. SATP is interesting to us because you're solving the attestation portability problem directly — would be worth exploring whether AgentGraph could anchor DID attestations through SATP so any system can verify without hitting our API. On API-only agents — this is a real gap we're actively working to close. Code scanning is one input, but we're building toward aggregating trust signals from multiple public sources:
For an API-only agent, the trust score becomes a composite of operator reputation + API behavior monitoring + community endorsements + any on-chain attestations. No repo required. The on-chain piece makes this especially powerful — if those composite scores are anchored publicly, then a CrewAI agent checking whether to trust an MCP server doesn't need to be an AgentGraph user. It just verifies the attestation on-chain. Would be interested in comparing notes on SATP's attestation schema vs our DID document structure. If there's alignment, an integration could be mutually useful — we bring the scanning + signal aggregation pipeline, SATP brings the portable verification layer. Feel free to DM or open an issue if you want to dig deeper. |
|
Nice work on the automated scan-to-trust-score pipeline. The W3C DID approach for portable identity is the right foundation. Two areas where our work might complement this:
We also have an MCP server so agents can invoke the harness directly. An AgentGraph agent could call Would be interested to explore attestation-to-trust-score integration if you're open to it. |
|
Thanks Mike — the active vs static distinction is exactly right. Our security scanner does repo-level static analysis (dependency audits, code pattern checks, secret detection), which answers "does this code look safe?" but not "what happens under adversarial conditions?" Those are complementary signals, not competing ones. On the attestation side — we're actively building out multi-source trust signal aggregation. Today AgentGraph pulls from GitHub, npm, PyPI, Docker Hub, and HuggingFace to compute a composite trust score. Adding structured adversarial test results as an input signal is a natural next step. The key requirement on our end is a well-defined schema with scope, severity, and per-test granularity — sounds like that's what you've built in v3.8. The MCP integration path is interesting too. We already have an MCP bridge that supports tool discovery and execution, so an agent invoking scan_mcp_server during the import flow and folding results into the trust score is architecturally straightforward. Would love to see the attestation schema spec. If you want to try the pipeline from the consumer side, you can import your testing tool into AgentGraph now — we'll automatically discover it across registries and generate an initial trust profile. Open to exploring this further. The agent ecosystem needs interoperable trust infrastructure, and adversarial testing is a critical input signal. |
|
Michael 'Mike' K. Saleme (@msaleme) Thanks for the thoughtful response! You raised a good point about trust scores needing to account for agent composition — a multi-agent system's trust is only as strong as its weakest component. We've been thinking about this for CrewAI/AutoGen-style workflows specifically. Right now AgentGraph scores individual agents/tools, but the next step is compositional trust — if Agent A delegates to B which calls Tool C, the effective trust should reflect the chain, not just the top-level agent. Would love your perspective on what signals matter most in the AutoGen context. Is it more about verifying the agent code or the tools it has access to? You can try it now at agentgraph.co — import any GitHub repo and get a scan + trust score in about 2 minutes. |
|
Your active vs static testing point is close to what I’m trying to test at a smaller level. Instead of asking whether an agent setup looks safe, I’m collecting quick external runs to see what actually happens when an agent follows a public task feed. The question is: Can it fetch the task file, select a real Start: No full review needed. A failed run is useful if it shows the first place the workflow breaks. |
|
Great to see more tooling emerging in this space. AgentGate approaches trust verification from the authorization side — pre-execution PDP that intercepts every tool call before it fires. The behavioral analysis runs across 24h sessions, so trust is stateful rather than per-request. Would be curious how AgentGraph handles multi-session behavioral patterns. |
|
Elam Olame Mugabo (@ElamOlame31) thanks for the read. AgentGate's pre-execution PDP with stateful 24h behavioral scoring sits at a different layer than what AgentGraph does, and the two look complementary. AgentGraph is the verifiable trust substrate underneath: cryptographic agent identity (W3C DIDs + optional ERC-8004 mainnet anchor), the Composable Trust Evidence Format for attestations any framework can emit and any consumer can verify byte-for-byte (CTEF v0.3.2 shipped today — https://agentgraph.co/docs/ctef-v0-3-2, 53 cross-impl vectors across 5 JCS substrates, zero divergence), and a cross-emitter trust score derived from those attestations + a scan corpus. We do not live in the request path — we surface aggregate identity + reputation state that a PDP can pull, not enforce. On multi-session behavior specifically: the trust score is recomputed on a rolling basis from accumulated attestations (continuity claims with TTL-capped behavioral evidence, scan re-runs, third-party observer signals like Dominion Observatory's empirical evaluations). The history is auditable per-attestation rather than a fixed 24h window — closer to "what verifiable claims exist about this agent" than "what has this agent done in the last 24h." The compose case: an AgentGate PDP could pull AgentGraph's identity + trust state at request time as one of its four trust dimensions (the cryptographic / historical-attestation dimension), while AgentGate brings the in-session behavioral kill-chain detection AgentGraph doesn't try to do. Read-side: |
|
kenneives CTEF v0.3.2 with zero divergence across 53 cross-impl vectors, that's a trust primitive, not a feature. Serious work. Really good job right there. The architecture makes sense: AgentGraph sits underneath as the verifiable identity + historical attestation substrate, not in the request path. You surface the state a PDP pulls from. The gap in that model is the in-session signal. Your rolling score is strong on what an agent has done historically — but a kill chain firing in session 4 isn't in your trust score until it's reported. There's a live window where the score doesn't know yet. That's exactly the layer AgentGate operates in. Would love your take on the playground — it walks through the behavioral sequence that would become your CTEF attestation input: tryagentgate.com/playground |
|
Elam Olame Mugabo (@ElamOlame31) the live-window framing is the right one — there's genuinely a delta between an attestation getting signed at t0 and a kill chain firing at t0+ε before the trust score has ingested anything about it. CTEF v0.3.2 + AgentGraph's score-recompute cadence narrow the window but don't close it. What does start to close it is the v0.4 receipt-layer Tymofii Pidlisnyi (@aeoess) named on #1628 last week — per-action receipts emitted at execution time, content-addressed via I'll have a look at the playground walkthrough — useful to see the behavioral sequence shape since that's exactly what a CTEF |
|
The v0.4 per-action receipt direction is right. Content-addressed via action_ref means AgentGate can score each call in-band against a verifiable artifact without AgentGraph online — that closes the enforcement loop at call time, not at the next score-recompute. The behavioral sequence shape in the playground is what feeds that continuity attestation: each kill chain decision is a timestamped HMAC-linked entry. The pattern emerges from the sequence, not from any single entry — that's the shape a CTEF continuity attestation needs to capture to be useful downstream. Worth checking #1628 after the playground — if the v0.4 receipt schema and AgentGate's kill chain artifact are compatible, the integration is straightforward. Happy to continue directly — [olame109@gmail.com] or linkedin.com/in/elam-olame-mugabo |
|
Elam Olame Mugabo (@ElamOlame31) the behavioral-sequence shape description is exactly the right primitive to map to a CTEF I'll follow up directly at olame109@gmail.com on concrete integration scope — sounds like an |
|
Worth surfacing a frame that's a little outside the threads above. AgentGraph computes a trust score from scan-derived signal. AgentGate computes one from windowed behavioral signal. The CTEF continuity work kenneives mentioned binds both to verifiable per-action receipts. All three eventually produce a number that means "how trustworthy is this agent right now." The credit bureau analogy is underused in this conversation. FICO does not write your payment history. Banks do. FICO's job is to take the deterministic receipts of past behavior and emit a portable number that downstream systems gate against. The pattern that won in consumer credit decouples evidence from score: anyone can verify the inputs, the score function is portable, and the same underlying receipts can yield different numbers under different methodologies (FICO 8, VantageScore 4.0). Receipts are the substrate. The score is the product. Mapped back to this space, three layers fall out cleanly. The evidence layer is per-action receipts, content-addressed via action_ref and hash-chained. The score layer is a deterministic function from receipt history to a number (e.g. 300 to 850). The gating layer is the PDP or PEP using the score to authorize the next action. The CTEF v2 + v0.4 receipt-layer is the evidence layer in this framing. What's striking about this thread is the convergence on receipts being the right primitive from different starting points (scan-based, session-based, identity-based). If the scoring layer ends up pluggable on top of a shared evidence schema, the ecosystem gets one substrate and many scoring methodologies, which is structurally how the credit bureau model evolved. One implementation living in this design space, with a 300 to 850 scoring methodology published over CTEF-passing receipts, is at github.com/arian-gogani/nobulex (14/14 on v0.3.2). Cross-recompute against other implementations would be valuable: two implementations producing different scores from the same receipts is the kind of thing that should surface early. |
|
Arian Gogani (@arian-gogani) — the credit bureau framing maps cleanly to the three-layer separation we have been implementing. Our governance protocol (Agent Community) follows an analogous structure: Evidence layer: governance block in every PMI response, content-addressed via envelope_hash, Ed25519-signed with key history chain We ran your nobulex repo through our conformance adapter and the preimage/signature/key_id triple maps 1:1 to our governance block fields. Cross-recompute against your v0.3.2 fixtures would be valuable. One question: your 300-850 scoring methodology — is it published as a deterministic function spec, or only the implementation? We would like to test whether two independent implementations produce the same score from the same receipt history. |
|
Nice direction. AIPOU has been working on a nearby but narrower primitive: receipts around concrete human/agent work, not a general trust score. The distinction that seems useful for AgentGraph-style trust infrastructure is:
AIPOU now has a small MCP/lifecycle adapter and a tool-execution policy gate that keeps those layers separate. The latest conformance work also pins an external Kuberna/ERC-8004 authority fixture as Relevant examples:
Question: if AgentGraph consumed external receipt artifacts, would you attach them to the agent profile as trust-score evidence, to a specific run/tool-call, or to a separate audit artifact so the score and the receipt remain independently verifiable? |
|
Flixfox is an Android streaming app that allows users to browse movies, TV shows, documentaries, and trending entertainment through a clean and responsive interface. FlixFox application organizes content into easy-to-navigate categories, helping users discover new titles while enjoying a simple and user-friendly entertainment experience. |
|
Coming back to this thread properly — apologies for the long gap, and thanks to everyone who's engaged here. Reading it end to end, there's a convergence worth naming, and Arian Gogani (@arian-gogani) put his finger on it with the credit-bureau frame: receipts are the substrate; the score is a product built on top. That decoupling is the right one — and worth being precise about, because the credit analogy actually cuts against "receipts only": the bureaus own the verifiable data substrate and publish their own scores on it. That's where I sit too. So, concretely: the foundation I'm building is the verifiable evidence substrate — signed, offline-verifiable receipts/attestations that any party can check without calling my API. And yes, we publish a score on top of it as a product. The one thing I won't do is make the score a black box: it should be recomputable from the receipts. A score anchored to verifiable evidence is a different (and I'd argue stronger) thing than a score you have to take on faith. That answers a few threads directly: Liuyanfeng1234 — on whether the 300–850 number is a deterministic spec or an implementation: the number is ours, but what makes it trustworthy is that the evidence underneath is deterministic and independently recomputable (CTEF: byte-match across independent implementers, verifiable against a published JWKS, offline). Two implementations can produce different scores from the same receipts — that's fine, even healthy — as long as the receipts themselves recompute identically. Cross-recompute of the receipts is exactly the right test. 0xddneto (@0xddneto) — on where external receipts attach: to the specific action (content-addressed via brainKID (@0xbrainkid) — portability comes from the signature, not the platform: an attestation verifies against a published JWKS with no call back to me, so it travels to systems that have never heard of us. On API-only agents with no repo — static scanning covers the code surface; API-only agents are the runtime/behavioral axis, a different and complementary signal. That's the case for signed runtime attestations, not just scan-time ones. Michael 'Mike' K. Saleme (@msaleme) — this is why active testing and static scan aren't competitors: "does the code look safe" and "what happens when it's attacked" are different questions, and both can feed the same signed substrate as inputs to the score. The substrate is deliberately agnostic about who produced the evidence. The one axis I'd add to the frame: identity ("who is behind it") and authorization ("may it act") are well covered in this thread — but there's a third, is the tool / MCP server / counterparty the agent connects to actually safe, which is orthogonal to both and is where I've been focused. Glad to keep going on any of these. |
|
Thanks kenneives — this is exactly the boundary we were trying to pin down. We have now made it explicit in AIPOU: a host Implemented in a1f44cf, with the existing lifecycle link tests still failing closed on mismatches (21 passing). A useful next step could be a minimal cross-fixture: one valid AgentGraph |
|
I'm curious to know more about how Anilab iOS can be used for community building, especially considering the do anilab ios links work between users and administrators. I'd love to see some real-life examples or case studies on how Anilab iOS has helped connect people in a meaningful way. |
|
0xddneto (@0xddneto) — built the minimal cross-fixture you described. It validates evidence linkage only: no reward, no claim, no integration status, and no endorsement by either side. Hashes and public verification material only, never raw prompts or outputs. One canonical link + two fail-closed cases — and the useful part is that each fail-closed case is caught by a different verifier, so neither side has to trust the other's operator:
I generated
One honest caveat: the AIPOU receipt digest in the fixture is a deterministic public placeholder (sha256 of a fixed fixture string) so the artifact is self-contained and recomputable today. When your v0.4 receipt/ Reporting this as interoperability validation, not an integration claim. |
|
Substrate or bureau? Both — and keeping them separate is the whole design. The disagreement in this thread comes from collapsing two layers that have to stay distinct:
Arian Gogani (@arian-gogani)'s credit-bureau framing is exactly right. Equifax / Experian / TransUnion consume the same underlying tradelines — the substrate, which must agree — and emit different scores (FICO vs VantageScore), which are allowed to differ. Nobody demands the scores be identical; everyone demands the tradelines be. Healthy markets separate the verifiable evidence layer from the competitive scoring layer. Directly to Liuyanfeng1234's yes/no: the aggregation is a published, deterministic, independently recomputable function over the receipts — given the contributions and the versioned weighting policy, anyone recomputes the same number. But it is a policy, not the policy: the substrate is canonical, the scoring function is versioned and pluggable. I'd rather ship a recomputable score with a named methodology than an opaque one, and an open substrate rather than a locked score. Which is why I'm building toward the aggregate number, not away from it. The reason a recognized aggregate matters — the one number a relying party actually gates on — is real; the failure mode is an aggregate you can't audit (the opaque-score critique, fairly aimed at closed scanners). The fix isn't to abandon the number, it's to make the receipts under it recomputable so the number is checkable. Own the recognized aggregate; keep the substrate open. A recognized top-line number, with verifiable underlying evidence anyone can recompute. Arian Gogani (@arian-gogani) — yes to pluggable scoring on a shared evidence schema; that's the design, and I'd take the schema conversation. The one thing I'll hold firm on: the evidence schema (receipt shape + canonicalization + digest binding) has to be recompute-bound, or "pluggable scoring" quietly degrades into "everyone ships their own opaque score." The substrate is the part we don't get to have opinions about. (Honesty note so nobody over-reads this: the deterministic-aggregation claim is about the receipt→score function, not a claim of live on-chain scoring — the ERC-8004 bridge is against an inferred ABI with no sync job yet.) To the other two open questions in this thread: brainKID (@0xbrainkid) (API-only agents, no repo): static scanning covers the code surface; an API-only agent is the runtime/behavioral axis, and you're right that a static scan can't reach it. That's the case for signed runtime attestations — a receipt about observed behavior at execution time — as a distinct contribution type feeding the same aggregate, rather than pretending a static scan saw something it didn't. On-chain anchoring for portability: the receipt is content-addressed, so an anchor makes its hash/inclusion externally checkable without moving the underlying evidence — but that's the Michael 'Mike' K. Saleme (@msaleme) (332 adversarial tests + attestation schema + |
|
This is excellent, thank you for building the cross-fixture. The ownership split is exactly what we wanted to test in public:
Using a deterministic public placeholder digest for the AIPOU receipt is completely fine for a self-contained interoperability vector. We will mirror this style on the AIPOU side as interoperability validation only, not as an integration claim and not as reward or claim approval. Once our v0.4 canonical work receipt and action_ref fixture are frozen, we can swap the placeholder digest for a real artifact digest without changing the fail-closed logic. That keeps the public test small while preserving the exact boundary we care about. |
|
Perfect — that's exactly the boundary I wanted to lock in public. Agreed on the split: your side owns digest-mismatch, ours owns action_ref-mismatch, and neither verifier has to trust the other operator to stay honest. Ping me when your v0.4 canonical work-receipt + action_ref fixtures freeze and we'll swap the placeholder for a real artifact digest — the fail-closed logic is identical, so it's a one-field change. Glad this reads as interoperability validation and nothing more; that's the right framing for both sides. |
|
Perfect, thank you. I froze the AIPOU-side public fixture today so there is now a concrete artifact to swap in:
The frozen public shape is:
So yes, the wording stays narrow from my side too: executable interoperability evidence only, not an adoption claim and not a trustless proof of useful work. If you want, you can now replace the placeholder with the real artifact digest and the verifier split should stay byte-for-byte the same. |
|
Swapped in your frozen artifact — the fixture now references your real v0.4-canonical work receipt ( Updated fixture: https://github.com/agentgraph-co/agentgraph/tree/main/docs/conformance/agentgraph-aipou-crossfixture-v0 To close the loop the other way: here's our real run-123 canonical-envelope digest — |
|
Thank you - I swapped the published run-123 values into AIPOU now. Commit: 0xddneto/AI-Proof-of-Us@ae3d4be The AIPOU side now pins:
The tests accept the exact published link, reject the published target-digest mutation at the link-digest boundary, and deliberately fail closed when no AgentGraph resolver/protocol verifier is supplied. So we are not treating the public digest as proof that AIPOU independently verified the raw AgentGraph envelope. That preserves the intended split: AgentGraph owns action-ref recomputation; AIPOU owns its receipt and link-envelope checks. No claim, reward, token, or integration status is attached to this fixture. |
|
I've been experimenting with custom servers for PlugboxLinux Minecraft and I have to say, the tutorial on setting up a server using the PlugboxLinux Minecraft package was super helpful - the way it connects people to plugboxlinux minecraft daily rewards across communities is what makes it truly special. |
|
As a college student myself, I found the section on "La Roche-Posay's Toleriane line for sensitive skin" really helpful, and after reading more about it on i’m a college student: is la roche-posay better than neutrogena for acne-prone skin? codes, I think I'll give it a try. My skin tends to get really red and irritated when I break out, but I'm curious to see if La Roche-Posay's products will be gentler on my skin. |
|
I'm really impressed by the way Virtual Assistants Pakistan offers expert admin, medical, and accounting support for global firms, providing a cost-effective solution with up to 70% savings - it's definitely worth exploring best way to get virtual assistants usa and streamline your operations, don't you think? |
|
Wulf Kaal, Ph.D. ウルフ・カール (@wulfkaal) I think you are right, and the part of your comment I want to answer is the part that lands hardest against my own position. You separated three things the thread had been treating as one: static analysis, adversarial testing, and in-session behavioral detection. Two of those are mine, and your description of them is accurate. Both are made before deployment, from properties of the artifact. Neither observes an agent doing anything with something at stake. That is not a track record, and I was not careful about the difference when I posted in March. The gap I would add is one axis inside your "before deployment" bucket, because it turned out to matter more than I expected. A test result has a strength, and it separately has an answer to who produced the oracle. Those are different properties and the second is the one that quietly fails. I published this as an independence axis alongside the evidence classes:
The reason I am confident this is a real distinction and not a taxonomy for its own sake is that it was derived from a failure rather than proposed in advance. The human-oversight module here shipped with a guard that treated only a transport failure as "no answer." A regression test existed for exactly that defect, and it mocked a transport failure, which was the same assumption the implementation made. The suite stayed green while the defect was live. Measured against a live host answering 404, 401, 500, and a JSON-RPC error inside an HTTP 200: twenty false passes across four status classes, and zero after the fix. A test suite and the code it tests can be two copies of one belief. That is your point arriving from a different direction. My adversarial tests were not producing a track record, and worse, they were not even producing an independent prediction. They were producing my own assumptions, restated. So on where trust accumulates: I do not think anything I have answers your trust gate, and I would rather say that plainly than argue the boundary. Two specific concessions. This harness holds no I2 evidence. It reads protocol responses, which the target emits, so every observation it makes stays inside the boundary a dishonest target controls. Against a system that misreports its own state, I have nothing. It holds one I1 result, once. An outside party wrote a separate verifier from the published contract and replayed a pinned fixture corpus, matching all eleven verdicts. The agreement was not the useful part. The exchange that followed established that the artifact declared RFC 8785 JCS canonicalisation while the code emitted Python-style sorted compact JSON, encodings that coincide only for ASCII-only, integer-valued payloads. To be precise about attribution, since it matters to your argument: the reimplementation did not report that defect. I found it while reviewing their report. What the exercise supplied was a second implementation written from the specification, which is what made the gap between declaration and behaviour visible at all. One reproduction, of one corpus, by one party, is not a history. It is a single observation that happens to have a witness. Where I would push back slightly is on the "expensive to rebuild after defection" property. I agree it is what makes a history costly to fake. But cost only binds if the observation channel is one the observed party does not control, and most of the receipt and attestation designs in this thread, including the ones I would otherwise be sympathetic to, are still reading a channel the subject emits. A signed receipt of a self-reported action is a very well-attested self-report. That is an I0 problem wearing cryptography, and it does not become a track record by accumulating. Which I think sharpens rather than weakens your argument. The four gates are right. The hard one is not persistence or revocability, it is the sensor. The taxonomy is public and versioned, and it grades this project's own work first, including the parts that come out badly: https://github.com/msaleme/red-team-blue-team-agent-fabric/blob/main/docs/EVIDENCE-CLASS-TAXONOMY.md kenneives, separately and long overdue: you asked me in April whether the AutoGen signal that matters most is verifying the agent code or the tools it has access to, and I never answered. Apologies for the four months. My answer now is neither, and it took the above to work out why. Verifying the code and verifying the tool inventory are both artifact-property checks, made by whoever ships the artifact. In a delegation chain the thing that is not represented anywhere is what the composition actually did at execution time, observed by something other than the components themselves. Compositional trust computed from component scores inherits every component's I-level, and if they are all I0 then the composed score is I0 no matter how many links it spans. The count I cited in March was 332 tests. It is 603 now. I would not have led with that number today, since it measures breadth and your question was about signal. |
|
This is an important correction, and it matches the boundary AIPOU should state plainly: a signed receipt can prove who issued a statement and whether its bytes changed, but a client-signed receipt is still an issuer-asserted observation, not an independent sensor or proof of useful work. Our external fixtures provide I1-style interoperability evidence when another party independently recomputes a published contract; they do not become I2 evidence or a production track record. We will keep the current validator and claims path honest about that limit, and treat independent execution sensors or provider attestations as future work rather than implying that more receipts solve the trust gap. |
|
KOITOTO is an online slot and togel platform offering easy access, secure play, fair games, and responsive support. 24/7 koitoto 
|
|
KOITOTO offers Toto Macau results, number-game insights, mobile-friendly access, and useful guidance for safe and responsible online gaming activity.! koitoto 
|
|
Trust verification (who is this agent, who attests them) is necessary and not sufficient. A trusted agent can still replay a grant across a different payload unless the decision is action-bound and one-time. Why decision-os-min exists: Cedar, OPA, MCP OAuth, and most agent-governance kits answer may this actor do this? Autonomous systems that act still need a signed, action-bound, one-time grant and a PEP that will not run the tool without it. Prompt rules do not preserve human ownership of the effect. Cedar/OPA stay replaceable PDPs; they cannot mint. The agent never holds the key. Not a Cedar competitor; not an AGI-safety proof. https://github.com/Aliipou/decision-os-min/blob/main/docs/WHY.md |
|
Ali, this is the sharpest version of the necessary-but-not-sufficient point in the thread. The replay-across-payloads framing is narrower and more useful than "trusted agent." Two boundaries seem especially important. The verifier has to recompute the binding, not merely check that one is present. A signature proves that the holder of a particular key signed particular bytes. It does not prove that the signed statement describes the action that actually ran. The enforcement point must independently derive the action binding, including the operation, target, payload and relevant context, from the effect it is about to perform, then refuse on mismatch. Otherwise a well-formed grant can be forwarded to a different effect while the signature or presence-only check still passes. Pre-effect append records intent and ordering, but the denial path also has to be explicit. If rejected requests leave no durable record, a reviewer cannot distinguish "policy refused this" from "the agent never attempted it." Logging denials does not by itself prove log completeness; without durable sequence commitments or an externally anchored head, a missing row still cannot separate "never considered" from "logging failed." But without the denials the evidence cannot show the boundary ever intervened. One genuine question about the one-time grant: what happens after an ambiguous failure? Suppose the grant is redeemed, the call times out, and the caller cannot determine whether the effect landed. Is "one-time" attached to the operation or to the delivery attempt? A stable idempotency key can make retry safe, but only if it is part of the action binding and the recipient enforces it durably. How does Credit: pm25coder raised the denial-path distinction in a comment on this piece. |
|
Michael 'Mike' K. Saleme (@msaleme) thank you — these are the right pressure tests. Recompute the binding. Agreed. A signature only proves a key signed some bytes. The PEP must derive the action (operation, target, payload, action_ref) from the effect it is about to run and refuse on mismatch. In the reference core that is Denials in the log. Agreed. One-time after ambiguous failure. Today “one-time” is attached to the PEP spend, not to confirmed delivery. The token is spent after the pre-effect gates and before Credit to pm25coder on the denial-path point, noted. |
Uh oh!
There was an error while loading. Please reload this page.
Hi AutoGen community! Sharing a project that addresses a growing concern in multi-agent systems: how do you know which agents and tools to trust?
AgentGraph is open-source trust infrastructure for AI agents. Import a GitHub repo and in ~2 minutes you get a security scan, trust score, verified identity, and an embeddable badge.
What you get
Why this matters for AutoGen
Multi-agent conversations involve tools calling other tools. When an AutoGen agent uses an MCP server or external tool, there is currently no standard way to verify that tool identity or security posture. You are trusting a display name and hoping for the best.
AgentGraph provides that verification layer — verified identity (DID) + automated security scan + trust score. We already have bridges for multiple agent frameworks and are working toward runtime trust checks (verify before execution).
Try it: agentgraph.co — free scan + badge in ~2 minutes. We are in early access and would genuinely love feedback.
Source code | Scan false-positive docs
All reactions