The Agentic Standards Landscape — Where AGT Fits and Collaboration Opportunities #814
Replies: 13 comments 3 replies
-
|
The "Agent Bill of Materials" gap is the one I keep running into. You can audit every tool call and sign every decision, but if there is no standard way to declare what models, tools, and data sources an agent uses before it runs, the audit trail only tells you what happened - not whether the agent was configured correctly in the first place. The closest analog is SBOM for software supply chains, but agent systems have a wrinkle: the tool set can change at runtime (MCP discovery, dynamic tool registration). So an AI-BOM needs to capture both the static declaration and runtime deviations from it. On governance policy portability - this is where the fragmentation hurts most. Teams end up writing the same rules three times in three formats. A minimal common schema for "this agent can call these tools under these conditions" that compiles to Cedar, Rego, or YAML would go a long way. |
Beta Was this translation helpful? Give feedback.
-
|
Great mapping — especially the clarity around where standards overlap vs. diverge. I want to zoom in on Gap #2: cross-org trust federation, because we've implemented a working approach to this in practice. In Gavel (built on AGT), governance decisions are represented as hash-chained event sequences: propose → policy eval → evidence → review → approve Each event includes the SHA-256 of the previous one, making the chain tamper-evident by construction. The key idea: the chain itself becomes a portable, self-verifiable artifact. # Org A exports a completed governance decision
artifact = chain.to_artifact()
# Org B verifies independently — no API calls, no trust assumptions
result = GovernanceChain.verify_artifact(artifact)
# {"valid": true, "events": 8, "chain_id": "c-88bad30f", "errors": []}This eliminates the need for runtime trust between organizations. The artifact encodes:
So Org B can independently verify that governance policy was followed — without shared infrastructure, APIs, or prior trust agreements. We tested this with three independent GPT-4o-mini agents:
The resulting chain exported cleanly and verified offline. No simulation — full round-trip. In #276, @xsa520 references a shared envelope format — a minimal, system-agnostic schema:
This aligns directly with cross-org federation: systems don't need to agree on internal event structure — only on how to verify the integrity and provenance of the chain. I have a working reference implementation with export/verify round-trip. Happy to contribute a minimal Here is a live demo scenario example: |
Beta Was this translation helpful? Give feedback.
-
|
Update: NIST AI RMF 1.0 alignment assessment now published. 733 lines mapping all 19 RMF subcategories with code citations. 12 fully addressed, 7 partially addressed, 0 gaps. Our compliance portfolio now covers 6 frameworks:
This is the most comprehensive multi-framework compliance mapping for any open-source agent governance toolkit. |
Beta Was this translation helpful? Give feedback.
-
|
Good overview of the landscape. We've been building in the identity and trust layer and see AGT as complementary rather than overlapping — wanted to share how the pieces fit together. Where we sit relative to AGT: AGT defines governance policy enforcement — what agents are allowed to do, under what conditions, with what oversight. What it needs as input is reliable identity and trust signals about the agents being governed. That's what we provide:
AGT adapter: We've built The adapter handles the JWKS resolution and JWS verification so AGT doesn't need to understand our signing infrastructure directly. Observations on the standards landscape: The biggest gap we see across MCP, A2A, AGT, and ACI is a shared identity layer. Each protocol is developing its own notion of "who is this agent" — MCP has server names, A2A has agent cards, AGT has agent profiles. If these converged on W3C DIDs as the common identifier, interoperability becomes much simpler: one DID, multiple protocol bindings, shared trust attestations. We're actively working with the Open Agent Trust Registry (9 verified issuers) to build toward that convergence. Happy to collaborate on the AGT integration specifically if there's interest. |
Beta Was this translation helpful? Give feedback.
-
|
Great landscape mapping. Want to flag a project that addresses Gap #3 (audit trail interoperability) and Gap #4 (governance policy portability) from a different angle than AGT. Nobulex is a proof-of-behavior protocol — agents declare behavioral constraints in a Cedar-inspired DSL ( Where it connects to AGT: Gap #3 — Audit trail interoperability. Nobulex's action log uses a deterministic hash chain format: each entry contains action, outcome, timestamp, params, and the SHA-256 of the previous entry. Any verifier can replay the chain without access to the original system. This is the same pattern @jlugo63 describes with Gavel's Gap #4 — Governance policy portability. Nobulex uses a minimal constraint DSL: Cross-agent trust (Gap #2). Nobulex ships an 8-step cross-agent verification handshake — before two agents transact, they verify each other's proof-of-behavior (covenant signature, log integrity, compliance check, audience binding, task class scoping). If any step fails, the transaction is refused. This is the behavioral layer on top of AGT's identity-based trust scoring. The crosswalk is already formalized — Nobulex's proof-of-behavior mapping was merged into the agent governance vocabulary alongside SINT, InsumerAPI, and AgentNexus. 31 packages, 4,247 tests, MIT licensed. Happy to explore an AGT integration adapter if there's interest — the policy engine semantics are close enough that a bridge is feasible. Repo: https://github.com/arian-gogani/nobulex |
Beta Was this translation helpful? Give feedback.
-
|
Nice landscape overview. The gap I see: most standards focus on agent capabilities (what agents can do) but not on agent economics (what agents cost, how they pay for resources, how delegation chains propagate costs). This matters for governance because cost is a primary control lever. If you can control budget, you can control blast radius — an agent that runs out of budget stops acting, which is simpler and more reliable than trying to evaluate whether each action is "safe." Practical governance primitives we found necessary:
Wrote about the coordination and governance model: https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons |
Beta Was this translation helpful? Give feedback.
-
|
This mapping is useful because it separates overlapping standards from actual implementation surfaces. For AGT, the strongest collaboration point may be a conformance evidence model that can ingest multiple standards without forcing them into the same vocabulary. A practical object could include That would let ATF, OWASP Agentic Security, NIST AI RMF, and AI-BOM views coexist while still producing one operational answer: which agents, tools, data sources, and workflows are governed, tested, and monitored. The important boundary is that an AI-BOM should not remain inventory-only. It should feed approval refresh decisions when model, tool, dataset, prompt, runtime, or provider versions change. |
Beta Was this translation helpful? Give feedback.
-
|
This is a useful landscape mapping. One gap I want to flag that I haven't seen addressed in this thread or in the standards listed: data trustworthiness as a governance input. Every framework here governs the agent : identity, permissions, behavior constraints, trust scores, audit trails, economics. But none of them check whether the data the agent is about to consume is actually reliable at the time of access. An agent can have a verified DID, a trust score of 950, a signed behavioral covenant, and a budget envelope and still make a bad decision because the dataset it queried was 26 hours stale with two failed validation tests. The policy engine says "allowed." The data quality system (if one exists) says "do not trust this." Without a shared decision point, the agent proceeds anyway. This is not a theoretical gap. In data and analytics workflows, it shows up constantly:
The standards in this thread handle the first question well: is this agent allowed to do this? The missing primitive is the second question: is the data this agent is about to use worth trusting right now? I have been working on this pattern, combining AGT policy evaluation with external data quality signals (freshness, validation test status, quality scores, dataset ownership) as a two-layer governance check. The agent action is allowed only when both the agent authorization and the dataset trust check pass. Where this connects to the four gaps Imran listed:
|
Beta Was this translation helpful? Give feedback.
-
|
@SomeshZanwar, the gap is real. Bilateral receipts capture pre-execution authorization and post-execution result. They don't natively encode data state at the moment of access. That's a layer the current envelope underspecifies. Where it can fit: the pre-execution receipt already carries a policy_hash committing to the policy that authorized the action. The same envelope can carry a data_state_hash committing to the dataset's freshness/validation/quality snapshot at access time. Verifier replay then has both: the policy that was active and the data state that was queried. The CTEF v0.3.2 source_version field (locked this week, {scheme, value} registry, extensible via crosswalk file declaration) is the right surface. Initial schemes are block-height, ofac-list-version, policy-rev, epoch. A data-quality scheme referencing a snapshot hash (freshness timestamp + validation test status + dataset_owner_did) would fit without spec churn. On the cross-org point: the trust signal needs to travel with the data, not stay in the source system. The bilateral receipt's hash-chain handles that. Agent A's post-execution receipt becomes the data_state_hash input for agent B's pre-execution receipt downstream. Provenance chains across agents without operator trust at the chain handoff. Worth raising on the CTEF v0.3.2 thread (a2aproject/A2A#1786) if you want the data-quality scheme considered for the May 22 freeze. Happy to fold it into the field-shapes PR I'm writing now. |
Beta Was this translation helpful? Give feedback.
-
|
@arian-gogani, the source_version clarification in #1786 makes the mechanism concrete. A data-quality scheme fits the same registry pattern: { "scheme": "data-quality", "value": "<sha256_of_snapshot>" } where the snapshot encodes freshness timestamp, validation test status, and dataset_owner_did at the moment of agent access. Single composite hash, same shape as the other four schemes, parseable without pre-knowing the issuer's internal format. The cross-org chain you described maps cleanly: Agent A's post-execution receipt carries data_state_hash → that hash becomes the data-quality scheme value in Agent B's pre-execution source_version → provenance travels across the agent boundary without runtime trust at the handoff. The scope.audience-as-list pattern (multiple downstream gateways per attestation) supports exactly the case where one data quality attestation needs to be valid for multiple consuming agents. The piece this adds that my implementation didn't have: the data state at access time is verifiable offline, not just at the source system. That's what makes it useful for regulated industries where auditors need to reconstruct what the agent saw, not just what it was allowed to do. If folding a data-quality scheme into your field-shapes PR makes sense, happy to contribute the scheme definition and a conformance vector. Alternatively, I can raise it separately on #1786 , your call on which is cleaner before the freeze. |
Beta Was this translation helpful? Give feedback.
-
|
@arian-gogani @SomeshZanwar the For governance decisions, the verifier usually needs two things:
A practical evidence object could include The hash gives integrity. The typed metadata gives policy something concrete to evaluate: freshness limits, owner trust, quality threshold, regulated-data classification, or whether the dataset version is approved for that agent/task class. For AGT, this feels like an evidence artifact attached to a policy decision rather than a separate governance framework. The decision remains "allow/deny/require review," but the evidence bundle explains which data-state snapshot the decision depended on. |
Beta Was this translation helpful? Give feedback.
-
|
@musaabhasan, the distinction between integrity evidence and policy-readable metadata is the right way to split this. The typed fields you're describing : freshness_at, quality_profile_id, classification, retention_policy, snapshot_hash are exactly what a governance engine needs to make a policy decision without dereferencing an opaque blob. The hash alone doesn't give AGT enough to evaluate freshness limits, owner trust, or regulated-data classification at decision time. The way I'd reconcile this with the CTEF source_version proposal: the two layers serve different purposes and don't need to collapse into one. The hash goes in CTEF source_version : it's the portable integrity commitment that travels with the envelope across agent boundaries. Agent B can verify that the data-state snapshot Agent A acted on wasn't altered, without fetching the full object. The typed evidence artifact you're describing goes in AGT : attached to the policy decision as the readable form of the same snapshot. The governance engine evaluates the typed fields. The snapshot_hash inside that artifact is what the CTEF source_version commits to. So the chain is: typed evidence artifact (policy evaluation) → snapshot_hash inside it → CTEF source_version carries that hash (integrity across agent boundaries). Same snapshot, two representations, different jobs. The framing as an evidence artifact attached to a policy decision rather than a separate governance framework also feels right. The decision is still allow/deny/require review. The evidence bundle is what makes that decision auditable. |
Beta Was this translation helpful? Give feedback.
-
|
@musaabhasan @SomeshZanwar, the integrity-vs-typed-metadata split is the right shape. The hash in CTEF source_version travels with the envelope across agent boundaries — that's the portable integrity commitment. The typed evidence artifact (freshness_at, quality_profile_id, classification, retention_policy, snapshot_hash) at the AGT policy decision layer is what governance engines actually evaluate. Same snapshot, two representations, different jobs. The chain from typed evidence → snapshot_hash → CTEF source_version is what makes the policy decision auditable across agent handoffs without forcing AGT to deserialize an opaque blob at decision time. Folding the data-quality scheme into the v0.3.2 field-shapes PR per Somesh's offer on a2aproject/A2A#1786. The typed evidence artifact stays at the AGT layer where Musaab's framing puts it. CTEF doesn't try to absorb governance semantics — it carries the integrity hash and lets AGT do the policy work. |
Beta Was this translation helpful? Give feedback.
-
|
Useful convergence. As governance evidence becomes more structured, cross-system interoperability likely depends on decision artifacts whose integrity, policy semantics, and acceptance context remain independently verifiable across standards boundaries. Hash integrity alone may preserve snapshot authenticity, but long-term interoperability likely requires explicit separation between:
Without that separation, independently compliant systems may still produce audit-valid yet non-comparable governance outcomes. |
Beta Was this translation helpful? Give feedback.
-
|
Great overview. One gap I'd flag: most current standards treat authorization as a platform-level concern (what resources can this agent access?) but don't model behavioral trust over time (what has this agent done in the last 24 hours?). We built AgentGate for this layer — a PDP that sits between agents and their tools, scoring trust across 4 dimensions per request and detecting kill chain patterns that span multiple sessions. Where do you see stateful behavioral analysis fitting relative to what AGT covers? https://github.com/ElamOlame31/agentgate-public |
Beta Was this translation helpful? Give feedback.
-
|
Useful landscape map. Adding AlgoVoi's position since arian-gogani has already introduced CTEF here -- AlgoVoi is the substrate-author for the JCS canonicalisation layer that the CTEF evidence envelope is built on. The relevant artefact family from an AGT-alignment perspective:
All four share a single canonicalisation pin: JCS RFC 8785 ( The cross-implementation evidence: 320/320 byte-for-byte agreements across 8 language runtimes (Python / Node / Ruby / PHP / Go / Rust / Java / .NET) over 5 vector sets, attested at For AGT specifically: the compliance-receipt categorical enum maps cleanly to an AGT policy evaluation output. An AGT policy engine that has determined COMPLIANT can emit the receipt as the portable artefact for downstream verifiers (regulators, counterparty agents, audit systems) without those verifiers needing to trust AGT's runtime. Behavioral trust over time (ElamOlame31's point below) is what Agent Trust Bench covers: 138 profiles across 30 categories at https://agent-trust-bench.algovoi.co.uk -- the conformance-over-time layer that complements static policy evaluation. AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The Agentic Standards Landscape — Where AGT Fits and Collaboration Opportunities
As autonomous AI agents move to production, multiple standards and frameworks are emerging to address governance, trust, safety, and interoperability. This discussion maps the landscape and identifies where agent-governance-toolkit can collaborate, align, or contribute.
Standards & Frameworks We Track
docs/compliance/atf-conformance-assessment.mddocs/compliance/owasp-llm-top10-mapping.mdpackages/agentmesh-integrations/a2a-protocol/docs/compliance/eu-ai-act-checklist.md+ risk classifierdocs/nist-rfi-mapping.mddocs/compliance/iso-42001-mapping.mddocs/compliance/soc2-mapping.mdWhere We Lead
Where We Should Collaborate
Where Standards Are Still Missing
How to Get Involved
We believe the agentic governance space benefits from convergence, not fragmentation. Multiple standards addressing different aspects (trust, safety, interoperability, compliance) can compose — as long as implementations can speak multiple protocols.
What standards is your organization tracking? Where do you see the biggest gaps?
Beta Was this translation helpful? Give feedback.
All reactions