Idea: bounded evidence interop with Assay

[Rul1an]

Hi all,

I maintain Assay. It is a narrower tool than AGT, and that is on purpose. After spending some time with this repo, the MCP lines, and the recent ScopeBlind work in #667, I think there is a pretty intersting interop seam here if we keep it small and honest.

My read is that AGT is strongest as a runtime governance layer. Assay is strongest when it takes runtime signals and turns them into reviewable, portable evidence. So to me this is not "these projects should become each other." It is more "there may be a clean handoff between them."

The shape I would want to try is pretty small. Pick one AGT surface, not the whole platform. MCP trust proxy decisions would be a good start. Security scan output or SARIF could also make sense. Signed receipts are intersting too, but only when the verifier boundary is really explicit and pinned.

From there, I think the right move is just a tiny frozen corpus. One allow, one deny, one malformed or error case, and one imported artifact that stays observed instead of being quietly promoted into trust. That part matters a lot to me. If Assay ingests AGT output, I would want the boundary to stay really clear about what was enforced by AGT, what Assay merely observed, and what was independently verified.

The reason I think this could be worth trying is pretty simple. AGT gets a portable evidence path without changing its runtime model. Assay gets a real governance corpus instead of toy traces. And both sides stay honest about their jobs.

If that sounds useful, I’d be happy to turn this into a very small design sketch or sample instead of a broad feature request.

Tagging @microsoft/agent-governance-team since this feels more like integration design than a normal issue.

[Rul1an]

Quick follow-up from my side: I turned this into a very small v1 sketch in the Assay repo so it stays concrete rather than hand-wavy.

PR is here: Rul1an/assay#1033

The shape is intentionally small. Start with mcp-trust-proxy audit decisions as imported runtime evidence, keep trust_score as observed metadata only, and avoid translating AGT trust semantics into Assay truth.

If that direction looks useful, I am happy to tighten it further into an even smaller sample or frozen corpus.

[imran-siddique]

Thanks for the concrete sketch @Rul1an! The bounded evidence interop concept aligns well with our Annex IV exporter (#782) and ComplianceReport model. Happy to explore a lightweight adapter that maps AGT audit entries to Assay evidence format. The PR you linked is a great starting point.

[Rul1an]

Thanks, this is really helpful. That is exactly the kind of anchor I was hoping for.

The fact that this already lines up with the Annex IV exporter and the ComplianceReport model makes the direction feel a lot more real than a generic interop idea.

My instinct would still be to keep the first seam very small. I would start with raw AGT audit entries mapped into bounded Assay evidence, and keep ComplianceReport and Annex IV as upstream context rather than something Assay imports as truth.

So the next thing that would make sense on my side is a tiny sample, not a broad integration. One allow, one deny, one malformed or error case, and a very explicit observed versus derived boundary in the mapping.

If there is already a preferred audit-entry shape near mcp-trust-proxy, ComplianceReport, or the Annex IV exporter that you would want an external consumer to target, point me at that surface and I can cut the sample to match it.

Happy to keep this small and concrete.

[Rul1an]

Small follow-up from the Assay side: we now also have the MCP-native distribution path live, not just the interop sketch.

Assay is now published in the official MCP Registry as io.github.Rul1an/assay-mcp-server, backed by a real v3.5.1 release asset set rather than hand-maintained metadata:

• Release: https://github.com/Rul1an/assay/releases/tag/v3.5.1
• Registry search: https://registry.modelcontextprotocol.io/?q=io.github.Rul1an%2Fassay-mcp-server

That does not change the bounded seam we were discussing here. If anything, it just makes the MCP side of Assay a little more concrete: there is now a real MCPB-packaged server/gateway entry people can inspect and install.

I still think the right AGT path is the same small one: raw AGT audit / compliance-relevant output as bounded external evidence, without importing AGT trust semantics as Assay truth. But I wanted to close the loop now that the MCP Registry line is actually live.

[Rul1an]

Small follow-up on the AGT seam itself: I cut the tiny sample I said I would, rather than letting this stay at sketch level.

PR: Rul1an/assay#1042

The scope stays deliberately small:

• frozen mcp-trust-proxy-style audit corpus
• one allow, one deny, one malformed import case
• Assay-shaped placeholder mapping
• trust_score remains observed metadata only

So this is still not a broad AGT adapter or a schema freeze. It is just the smallest concrete sample I could make on the Assay side from the surface we discussed.

If you do have a more preferred audit-entry shape near the Annex IV exporter or ComplianceReport, I can trim the sample again to match that exact surface.

[ElamOlame31]

The bounded evidence concept maps to something we built around. In AgentGate, every decision is a SHA-256 Merkle-chained artifact sealed before the action executes — not derived from it after the fact. The constraint: evidence must precede the action it authorizes, otherwise it's a log.

Has Assay addressed this temporal ordering requirement? Would be interested in exploring interop.

https://github.com/ElamOlame31/agentgate-public

https://www.tryagentgate.com/

[Rul1an]

Thanks for the pointer.

I would separate two boundaries here:

• pre-action authorization evidence: a decision or receipt produced before the action, with its own timestamp, subject, target, policy/version, input commitment, and decision, bound together such that the binding could not have been produced after the action
• post-action observation evidence: what actually happened later, such as execution status, result digest, error class, or downstream audit records

Assay should not turn the second into the first by aggregation. If AgentGate has a pre-action Merkle-chained decision artifact, Assay could ingest that as an external observed evidence item and preserve its temporal claim, but it would still need to keep the later execution observations separate.

So yes, the temporal ordering requirement is real. My preferred interop shape would be a tiny frozen corpus with one pre-action allow, one pre-action deny, and one later observation linked back to a prior decision by digest, with the decision id and timestamp carried alongside for review. The important test is whether a reviewer can tell which claim was made before authorization and which facts were only observed after the action.

That keeps Assay as the review/evidence layer rather than pretending to be the runtime enforcement point.

[ElamOlame31]

The distinction you're drawing — pre-action authorization evidence vs post-action observation evidence — is the exact invariant AgentGate's audit trail is built around.

Every decision is Merkle-sealed before the action executes. The record contains timestamp, agent identity, resource, action, policy version, input commitment, and decision outcome — bound at authorization time, not reconstructed afterward. A post-action observation can be linked back to a prior decision by digest, but it cannot modify or retroactively produce the pre-action record.

Your interop shape is essentially what AgentGate already emits: pre-action allow, pre-action deny, each carrying a decision ID and timestamp that any downstream observer can anchor to.

Would love your read on whether the actual output matches what Assay needs to ingest — the playground surfaces the full decision artifact: tryagentgate.com/playground

[Rul1an]

@ElamOlame31 Thanks, that is the shape I was hoping to see.

For Assay, the most useful next step would be one frozen artifact sample that can be reviewed offline, not a playground-only check.

Ideally that sample has:

• one pre-action allow decision
• one pre-action deny decision
• one later observation linked back to a prior decision by digest

The fields I would look for are the policy/version, input commitment, timestamp, decision id, subject, resource/action, decision outcome, and the chain/hash material needed to verify the pre-action binding.

The key check is whether the artifact itself carries the temporal claim without needing to trust the UI or a live AgentGate instance: this decision existed before the action, this later observation only references it, and neither layer can rewrite the other.

If you have a small JSON fixture or fixture directory for that shape, I can give a much more useful read from that than from the playground.