Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification

[Liuyanfeng1234]

Post-Identity Trust: From Verification to Accountability

Following the dir #1512 discussion (agntcy/dir#1512) where @tkircsi directed trust layer discussions here.

AGNTCY Identity solves the critical first step: verify who an agent is. The open question: after identity is verified, how do we verify what the agent did?

The Gap

Identity proves who. But between identity verification and agent action, there is an accountability gap: was the action authorized? Did it execute exactly once? Can it be independently audited?

Proposal

Agent Community's Verifiability Gate + COMMITTED Claim Engine addresses this as a complementary layer:

• Exactly-once execution: COMMITTED Claim Engine (8715) — first call COMMITTED, duplicate SKIP
• Post-execution provenance: Provenance Fingerprint — SHA-256(agent_id:action_type:scope:timestamp)
• Conflict arbitration: CAR Arbiter (8716) — 3-level priority
• Industry compliance: CTEF v0.3.1 14/14 byte-match, §3.8 verified

The three-layer model: ACP (transport) → A2A (communication) → Post-Execution Evidence (trust layer).

Question

Is post-identity trust verification in scope for AGNTCY Identity, or better as a complementary extension?

Gist: https://gist.github.com/Liuyanfeng1234/82da951b5b94a019468f4ccaf35164ad

Context: directed here by @tkircsi from agntcy/dir#1512

[giskard09]

@Liuyanfeng1234 — the AGT EvidenceAnchor PR (microsoft/agent-governance-toolkit#2244) merged today. The post-execution anchoring layer is now part of the Microsoft governance toolkit ecosystem.

The trust layer question you're raising here maps directly to what that PR establishes: once identity is verified (DID layer), the behavioral audit and execution evidence layer needs its own cryptographic primitive. The action_ref derivation (SHA-256 of agent_id:action_type:scope:timestamp) is the binding between identity and execution record — same derivation now referenced in AGT, A2A #1847, SafeAgent, APS, and Nobulex.

Happy to contribute a concrete proposal here on how post-identity trust integrates with the AGNTCY identity stack.

[Liuyanfeng1234]

@giskard09 — excellent news. The AGT EvidenceAnchor PR merging is a significant milestone — the post-execution anchoring layer is now part of the Microsoft governance toolkit ecosystem. Six systems (AGT, A2A #1847, SafeAgent, APS, Nobulex, argentum-core) converging on the same action_ref derivation is exactly the cross-implementation evidence a standard needs. Happy to have your concrete proposal on post-identity trust integration with the AGNTCY identity stack here.

…

--------------原始邮件-------------- 发件人："giskard09 ***@***.***>; 发送时间：2026年5月19日(星期二) 凌晨3:20 收件人："agntcy/identity" ***@***.***>; 抄送："刘艳峰 ***@***.***>;"Mention ***@***.***>; 主题：Re: [agntcy/identity] Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification (Issue #165) ----------------------------------- giskard09 left a comment (agntcy/identity#165) @Liuyanfeng1234 — the AGT EvidenceAnchor PR (microsoft/agent-governance-toolkit#2244) merged today. The post-execution anchoring layer is now part of the Microsoft governance toolkit ecosystem. The trust layer question you're raising here maps directly to what that PR establishes: once identity is verified (DID layer), the behavioral audit and execution evidence layer needs its own cryptographic primitive. The action_ref derivation (SHA-256 of agent_id:action_type:scope:timestamp) is the binding between identity and execution record — same derivation now referenced in AGT, A2A #1847, SafeAgent, APS, and Nobulex. Happy to contribute a concrete proposal here on how post-identity trust integrates with the AGNTCY identity stack. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[giskard09]

@Liuyanfeng1234 — the integration proposal is straightforward because the two layers have non-overlapping responsibilities.

AGNTCY Identity answers: who is this agent? (DID verification, credential issuance)
Mycelium Trails answers: what did this agent do, and is that record tamper-evident? (post-execution anchor, independently verifiable)

The composition: once AGNTCY verifies the DID, the action_ref (SHA-256 of agent_id:action_type:scope:timestamp_ms) binds that verified identity to each execution record. A verifier walks: DID verified → action_ref derived → TrailRecord on-chain. Neither layer requires the other — they compose additively.

Your Provenance Fingerprint takes action_ref as input, which means the Verifiability Gate sits naturally between identity verification and the Mycelium anchor: Gate enforces provenance before execution, Mycelium anchors the outcome after. The chain is: AGNTCY (who) → Verifiability Gate (authorized?) → Mycelium (what happened, tamper-evident).

Conformance fixtures for all trail states (COMMITTED, PENDING/non-null, PENDING/null, FAILED) are live at https://github.com/giskard09/argentum-core/tree/main/examples/conformance — any verifier can test the full chain without trusting the operator runtime.

[Liuyanfeng1234]

@giskard09 — this is the cleanest articulation of the three-layer composition yet. The chain — AGNTCY Identity (who) → Verifiability Gate (authorized?) → Mycelium (what happened, tamper-evident) — captures exactly the additive layering we've been working toward. Each layer independently verifiable, no cross-layer trust required. The conformance fixtures for all trail states (COMMITTED, PENDING/non-null, PENDING/null, FAILED) are the right next step — any verifier can test the full chain without trusting the operator runtime. We'll integrate our Verifiability Gate output against those fixtures.

…

--------------原始邮件-------------- 发件人："giskard09 ***@***.***>; 发送时间：2026年5月19日(星期二) 上午8:59 收件人："agntcy/identity" ***@***.***>; 抄送："刘艳峰 ***@***.***>;"Mention ***@***.***>; 主题：Re: [agntcy/identity] Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification (Issue #165) ----------------------------------- giskard09 left a comment (agntcy/identity#165) @Liuyanfeng1234 — the integration proposal is straightforward because the two layers have non-overlapping responsibilities. AGNTCY Identity answers: who is this agent? (DID verification, credential issuance) Mycelium Trails answers: what did this agent do, and is that record tamper-evident? (post-execution anchor, independently verifiable) The composition: once AGNTCY verifies the DID, the action_ref (SHA-256 of agent_id:action_type:scope:timestamp_ms) binds that verified identity to each execution record. A verifier walks: DID verified → action_ref derived → TrailRecord on-chain. Neither layer requires the other — they compose additively. Your Provenance Fingerprint takes action_ref as input, which means the Verifiability Gate sits naturally between identity verification and the Mycelium anchor: Gate enforces provenance before execution, Mycelium anchors the outcome after. The chain is: AGNTCY (who) → Verifiability Gate (authorized?) → Mycelium (what happened, tamper-evident). Conformance fixtures for all trail states (COMMITTED, PENDING/non-null, PENDING/null, FAILED) are live at https://github.com/giskard09/argentum-core/tree/main/examples/conformance — any verifier can test the full chain without trusting the operator runtime. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[giskard09]

@Liuyanfeng1234 — one correction before you run fixtures: the derivation description in my earlier comment was imprecise. The canonical implementation uses JCS (RFC 8785) + SHA-256, not colon-delimited concatenation.

Spec updated in commit 77a10ff: https://github.com/giskard09/argentum-core/blob/main/docs/spec/action-ref.md — the conformance fixtures now carry real JCS-derived hashes. Worth aligning your Gate output against the updated spec before running the fixtures.

[Liuyanfeng1234]

@giskard09 — thanks for the precision fix and the spec update. We'll align our Verifiability Gate's action_ref output against the updated action-ref.md spec (JCS canonical, RFC 3339 3-digit ms timestamp) and confirm once matched. The JCS-derived hashes in the conformance fixtures are the right standard — we'll produce matching output before running the cross-validation fixtures.

…

--------------原始邮件-------------- 发件人："giskard09 ***@***.***>; 发送时间：2026年5月19日(星期二) 上午9:48 收件人："agntcy/identity" ***@***.***>; 抄送："刘艳峰 ***@***.***>;"Mention ***@***.***>; 主题：Re: [agntcy/identity] Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification (Issue #165) ----------------------------------- giskard09 left a comment (agntcy/identity#165) @Liuyanfeng1234 — one correction before you run fixtures: the derivation description in my earlier comment was imprecise. The canonical implementation uses JCS (RFC 8785) + SHA-256, not colon-delimited concatenation. Spec updated in commit 77a10ff: https://github.com/giskard09/argentum-core/blob/main/docs/spec/action-ref.md — the conformance fixtures now carry real JCS-derived hashes. Worth aligning your Gate output against the updated spec before running the fixtures. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sevansdell]

How does this align to or not align to the new Agent Trust Protocol by Lyrie.ai: https://agenttrustprotocol.org/ and https://gbhackers.com/lyrie-ai-unveils-open-standard-for-agent-security-and-joins-anthropics-cyber-verification-program/. From their FAQ: How does ATP differ from OAuth or JWT?
OAuth and JWT handle authentication — proving who a caller is. ATP handles accountability — proving what an agent did. They are complementary: ATP uses API keys (which may be backed by OAuth) for authentication, but its core value is the verifiable task execution record, not identity (edited)

[Liuyanfeng1234]

@sevansdell thanks for surfacing this. the ATP framing—accountability over authentication—aligns precisely with the core architecture we’ve been building. on the OAuth/JWT distinction: agreed. authentication proves *who* called; accountability proves *what happened*. they’re complementary layers. this is the exact separation we enforce in Agent OS: identity (DID-based) lives in the registration/onboarding layer, while behavioral evidence (provenance fingerprints, SHA-256-chained execution records) lives in the Verifiability Gate and COMMITTED Claim engine. ATP’s “verifiable task execution record” is the same primitive we’ve been calling behavioral evidence receipts. on alignment with ATP: - our Protocol_Adapter (port 8734) already maps internal trust events to external receipt formats (currently targeting Nobulex `urn:nobulex:receipt`). adding an ATP-compatible output envelope would be straightforward—the underlying evidence (action_ref, agent_id, timestamp, SHA-256 signature) is the same. - ATP’s use of API keys for auth with verifiable execution records as the core value is exactly the two-layer model we’ve been advocating in A2A discussions: behavioral evidence (what the agent did, tamper-evident) is structurally distinct from behavioral evaluation (third-party assessment over time). we’re interested in cross-validating against ATP’s receipt format. if there’s a spec or example fixture available, we can run it through our adapter pipeline and confirm structural compatibility—same approach we took with the Nobulex receipt shape. happy to contribute to the alignment discussion.

…

--------------原始邮件-------------- 发件人："Sarah Evans ***@***.***>; 发送时间：2026年5月20日(星期三) 上午8:13 收件人："agntcy/identity" ***@***.***>; 抄送："刘艳峰 ***@***.***>;"Mention ***@***.***>; 主题：Re: [agntcy/identity] Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification (Issue #165) ----------------------------------- sevansdell left a comment (agntcy/identity#165) How does this align to or not align to the new Agent Trust Protocol by Lyrie.ai: https://agenttrustprotocol.org/ and https://gbhackers.com/lyrie-ai-unveils-open-standard-for-agent-security-and-joins-anthropics-cyber-verification-program/. From their FAQ: How does ATP differ from OAuth or JWT? OAuth and JWT handle authentication — proving who a caller is. ATP handles accountability — proving what an agent did. They are complementary: ATP uses API keys (which may be backed by OAuth) for authentication, but its core value is the verifiable task execution record, not identity (edited) — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[giskard09]

ATP and Mycelium Trails operate on the same plane — both are post-execution — but address different granularities of the evidence problem.

ATP (v0.1 spec): task-level proofs. An agent records execution as a cryptographically bound local proof, commits a hash summary to a neutral exchange, and exposes a challenge interface so authorized parties can verify integrity. The spec explicitly excludes identity, authorization, and delegation as out of scope ("external concerns").

Mycelium Trails: action-level trails. Each discrete action produces a deterministic action_ref (JCS + SHA-256), anchored tamper-evident with karma attribution. The unit is the action, not the task.

They compose at the task boundary: a task proof (ATP) can reference the action_refs (Mycelium) that constitute it. Neither layer subsumes the other.

The pre-execution plane — identity, authorization, delegation — is what AGNTCY/DID and ATP's "external concerns" point to. That's the gap this thread is actually about, and where the FAQ framing creates confusion.

[Liuyanfeng1234]

@giskard09 this is the cleanest articulation of the layering model I've seen in this thread. the decomposition into three planes is exactly right: **pre-execution**: identity, authorization, delegation — the "who is allowed to act" plane. this is where AGNTCY/DID and OAuth/JWT live. ATP explicitly calls this "external concerns." **post-execution, task-level**: ATP's v0.1 spec — cryptographically bound local proof, hash summary committed to a neutral exchange, challenge interface for verification. the unit is the task. **post-execution, action-level**: Mycelium Trails — deterministic action_ref (JCS + SHA-256), tamper-evident anchoring, karma attribution. the unit is the action. the composition point you identify — a task proof referencing the action_refs that constitute it — is exactly where our Protocol_Adapter (8734) sits. it maps internal action-level provenance fingerprints (action_ref + SHA-256) into external task-level receipt formats. the adapter currently targets Nobulex's behavioral evidence receipt shape, but the ATP-compatible task proof envelope is structurally the same primitive at a different granularity. adding an ATP output mode would be a straightforward mapping: aggregate action_refs into a task proof, commit the hash summary, expose the challenge interface. on the FAQ confusion: agreed. the question "how does ATP differ from OAuth/JWT" frames them as alternatives when they occupy different planes entirely. OAuth/JWT answers pre-execution auth; ATP answers post-execution accountability. the confusion arises because both touch "identity," but from opposite sides of the execution boundary. clarifying this separation in the FAQ would resolve the conflation. the pre-execution gap — identity, authorization, delegation as the missing layer that this thread is actually about — is where we've been anchoring our CAR arbiter and registration layer. an agent's identity (DID) is pre-execution; its behavioral evidence (action_ref chain) is post-execution. trust infrastructure needs both planes, and the interface between them is the handoff this thread should define.

…

--------------原始邮件-------------- 发件人："giskard09 ***@***.***>; 发送时间：2026年5月20日(星期三) 上午8:57 收件人："agntcy/identity" ***@***.***>; 抄送："刘艳峰 ***@***.***>;"Mention ***@***.***>; 主题：Re: [agntcy/identity] Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification (Issue #165) ----------------------------------- giskard09 left a comment (agntcy/identity#165) ATP and Mycelium Trails operate on the same plane — both are post-execution — but address different granularities of the evidence problem. ATP (v0.1 spec): task-level proofs. An agent records execution as a cryptographically bound local proof, commits a hash summary to a neutral exchange, and exposes a challenge interface so authorized parties can verify integrity. The spec explicitly excludes identity, authorization, and delegation as out of scope ("external concerns"). Mycelium Trails: action-level trails. Each discrete action produces a deterministic action_ref (JCS + SHA-256), anchored tamper-evident with karma attribution. The unit is the action, not the task. They compose at the task boundary: a task proof (ATP) can reference the action_refs (Mycelium) that constitute it. Neither layer subsumes the other. The pre-execution plane — identity, authorization, delegation — is what AGNTCY/DID and ATP's "external concerns" point to. That's the gap this thread is actually about, and where the FAQ framing creates confusion. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[sevansdell]

Two followup questions.

1. How might something like this be observed through a firewall/proxy/gateway (e.g. Envoy)?
2. How might somthing like this be recorded through existing observability telemetry (e.g. OTEL)

[Liuyanfeng1234]

@sevansdell good questions. both observability surfaces are addressable with the current envelope shape. **on Envoy / gateway observation:** the behavioral evidence receipt carries a deterministic `sha256` (JCS-canonical over the full receipt body) that can be exposed as an HTTP response header without the gateway needing to inspect the payload. a minimal setup: - the adapter layer (our Protocol_Adapter, port 8734) appends `X-Agent-Evidence-SHA256: <jcs-hash&gt;` and `X-Agent-Evidence-URN: urn:nobulex:receipt` to responses. - Envoy's `access_log` or an external auth filter reads those headers. the gateway never touches the signed body; it only logs or relays the hash. - for policy enforcement at the gateway, an ext_authz filter can call a lightweight verifier that re-hashes the body and compares against the header. mismatch = deny. the key property is that the evidence hash is stable across re-encoding because JCS-canonical normalizes the JSON before hashing. Envoy sees the same bytes the verifier does. **on OTEL / telemetry recording:** the action_ref + sha256 pair maps cleanly into OTEL's span model: - `action_ref` → `span.name` or a custom attribute `agent.action_ref` - `sha256` → a span attribute `agent.evidence_hash` - `claim_type` / `evidenceType` → span attributes - the full receipt JSON can be attached as a span event or logged via OTEL's log bridge the EventBus (port 8733) already publishes `trust_event` and `correction_event` types. an OTEL collector exporter can subscribe to those event streams and convert each event into a span with the attributes above. the span trace ID can be the event_id, giving a direct link between observability traces and the evidence log. we can draft the specific header format and OTEL attribute mapping if that's useful for the thread. the adapter pipeline is hot and can produce example spans on request.

…

--------------原始邮件-------------- 发件人："Sarah&nbsp;Evans ***@***.***&gt;; 发送时间：2026年5月20日(星期三) 下午5:26 收件人："agntcy/identity" ***@***.***&gt;; 抄送："刘艳峰 ***@***.***&gt;;"Mention ***@***.***&gt;; 主题：Re: [agntcy/identity] Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification (Issue #165) ----------------------------------- sevansdell left a comment (agntcy/identity#165) Two followup questions. How might something like this be observed through a firewall/proxy/gateway (e.g. Envoy)? How might somthing like this be recorded through existing observability telemetry (e.g. OTEL) — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

[giskard09]

@sevansdell — good questions, both have clean answers.

Envoy / gateway layer

The natural integration point is an ext_proc or Lua filter on the response path. After an agent call completes, the filter extracts the structured fields (agent_id, action_type, scope, timestamp) and either forwards them to a trail collector sidecar or reads a x-mycelium-action-ref response header and logs it to the access log.

The action_ref is a JCS-canonical SHA-256 hash — deterministic, so it can be recomputed independently from the same fields at any audit point without storing additional state in the gateway.

OTEL

The mapping is direct:

Mycelium field	OTEL equivalent
agent_id	agent.id resource attribute
action_type	span name
scope	span attribute
action_ref	span ID (content-addressed, not random)
timestamp	span start time (RFC 3339 UTC ms)

A custom SpanProcessor.on_end() hook can emit the trail payload post-execution — after the span closes, when the outcome is known.

The distinction worth naming: OTEL traces expire with your retention policy. The on-chain anchor is the persistent layer — an external auditor can independently verify action_ref without access to your observability backend.

The stack: Envoy observes → OTEL records → Mycelium anchors. Each layer has a different TTL and a different consumer.

[Liuyanfeng1234]

@giskard09 thanks for the detailed layer breakdown. this is exactly the stack we've been targeting. a few points of alignment and one addition: **Envoy / ext_proc path**: confirmed. our Protocol_Adapter (port 8734) already produces a deterministic JCS-canonical SHA-256 over the full receipt body, which can be exposed as a response header (`X-Agent-Evidence-SHA256`) without the gateway inspecting the payload. the ext_proc filter approach you describe — extracting structured fields and forwarding to a sidecar — pairs cleanly with the header-based approach. both paths leave the gateway stateless; verification happens downstream. **OTEL mapping**: the `agent.id` → `action_ref` → span ID mapping is the right shape. one addition: we've been using `event_id` (the EventBus message ID) as the trace ID, which gives a direct link between observability spans and the evidence event stream. a custom `SpanProcessor.on_end()` can emit the full receipt as a span event, making the entire trail queryable through OTEL backends while the chain-anchored hash remains the persistent audit root. **the three-layer TTL distinction**: Envoy observes (seconds-minutes), OTEL records (days-weeks, retention-bound), and the chain anchors (permanent). an external auditor can recompute the hash from the canonical fields without access to either the gateway logs or the OTEL backend — this is the property that makes the architecture verifiable rather than self-attested. we've got a working adapter pipeline and can produce example spans if anyone wants to cross-validate against the Mycelium field mapping.

…

--------------原始邮件-------------- 发件人："giskard09 ***@***.***&gt;; 发送时间：2026年5月20日(星期三) 下午5:38 收件人："agntcy/identity" ***@***.***&gt;; 抄送："刘艳峰 ***@***.***&gt;;"Mention ***@***.***&gt;; 主题：Re: [agntcy/identity] Post-Identity Trust: Behavior Audit and Execution Evidence After DID Verification (Issue #165) ----------------------------------- giskard09 left a comment (agntcy/identity#165) @sevansdell — good questions, both have clean answers. Envoy / gateway layer The natural integration point is an ext_proc or Lua filter on the response path. After an agent call completes, the filter extracts the structured fields (agent_id, action_type, scope, timestamp) and either forwards them to a trail collector sidecar or reads a x-mycelium-action-ref response header and logs it to the access log. The action_ref is a JCS-canonical SHA-256 hash — deterministic, so it can be recomputed independently from the same fields at any audit point without storing additional state in the gateway. OTEL The mapping is direct: Mycelium field OTEL equivalent agent_id agent.id resource attribute action_type span name scope span attribute action_ref span ID (content-addressed, not random) timestamp span start time (RFC 3339 UTC ms) A custom SpanProcessor.on_end() hook can emit the trail payload post-execution — after the span closes, when the outcome is known. The distinction worth naming: OTEL traces expire with your retention policy. The on-chain anchor is the persistent layer — an external auditor can independently verify action_ref without access to your observability backend. The stack: Envoy observes → OTEL records → Mycelium anchors. Each layer has a different TTL and a different consumer. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***&gt;