AgentAudit AI — on-chain persistence layer for Nobulex proof bundles

[agentauditAI]

Hi @arian-gogani — been following Nobulex development closely. The covenant enforcement + bilateral receipt model is exactly the pre-execution layer that's missing from most EU AI Act stacks.
We're building the complementary post-execution layer: AgentAudit AI anchors Nobulex proof bundles on-chain across 5 EVM mainnets (Arbitrum, Base, Optimism, Polygon, Mantle), making them cryptographically immutable and regulatorily verifiable under Article 12.
Proposed integration: Nobulex generates the proof bundle → AgentAuditAI anchors it on-chain via evidenceURI → ZK-proof layer enables privacy-preserving verification for third-party auditors.
Together: complete Article 9 + 12 + 14 compliance stack, pre- and post-execution.
Repo: https://github.com/agentauditAI/AgentAudit
Dashboard: https://getagentaudit.xyz
Worth a technical sync? Happy to share interface mappings.

[arian-gogani]

thanks for opening this. the layering you described makes sense: nobulex generates the receipt bundle (pre-execution), AgentAudit anchors it on-chain (post-execution). the two are complementary.

a few things to align on technically:

1. the nobulex receipt format uses Ed25519 signatures over JCS-canonical JSON (RFC 8785). the action_ref is SHA-256(JCS({agent_id, action_type, scope, timestamp_ms})). your on-chain anchor would reference this action_ref as the binding key.

2. the Python SDK is at github.com/arian-gogani/nobulex/tree/main/packages/python. test vectors for cross-validation are at fixtures/bilateral-receipt/v0/.

3. for the Article 12 compliance angle: the receipt already carries policy_version and attempt_id fields for audit lifecycle tracking.

happy to do a technical sync. what's the best way to connect?

[agentauditAI]

thanks for the detailed breakdown — this gives us exactly what we need to wire up the integration.

to confirm our understanding of the binding:

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms}))

we'd store action_ref as the primary key in our AgentAuditBatch log entry on-chain, alongside the attempt_id and policy_version fields from the receipt for Article 12 lifecycle tracking. the ZK-proof layer we have (ZKAuditProof.sol) can then generate a proof over the anchored action_ref without exposing the full receipt payload — which should be useful for cases where the scope data is sensitive.

we'll pull the Python SDK and test vectors from fixtures/bilateral-receipt/v0/ this week to validate cross-compatibility.

a few things on our end you might find relevant:

• we're deployed on 5 mainnets (Base, Arbitrum, Optimism, Polygon, Mantle) so the anchor can be chain-agnostic
• we have an MCP server (mcp-server.ts) that could make nobulex receipt anchoring accessible to any MCP-compatible agent framework
• we're tracking ERC-XHRON (xhronos444) as a potential standard for agent receipts — AgentAudit is being positioned as reference implementation; nobulex receipts could be a natural fit for the off-chain side of that spec

for the sync: a 30-min call works well. we're UTC+0 (Iceland). happy to do async over GitHub if you prefer. what's your timezone?

— Piotr, AgentAudit AI / RunLockAI

[arian-gogani]

@agentauditAI perfect. the binding is exactly right: action_ref as primary key, attempt_id and policy_version alongside for lifecycle tracking.

the ZK-proof layer over the anchored action_ref without exposing the full receipt payload is a clean design for sensitive scope data. that's a use case we should make sure the receipt format supports well.

on the MCP server angle: making nobulex receipt anchoring accessible to any MCP-compatible agent framework through your mcp-server.ts is interesting. that could be the fastest path to getting receipts flowing from agents that already use MCP tools.

on ERC-XHRON: happy to look at it. nobulex receipts as the off-chain side of an on-chain standard makes sense architecturally.

for the sync: i'm UTC-7 (california). async over GitHub works great for the technical spec. happy to do a call too. let me know what time works and i'll make it happen.

one concrete next step: can you try running the test vectors at fixtures/bilateral-receipt/v0/vectors.json through your anchoring pipeline? if the action_ref reproduces on your end, we know the formats are compatible and can move to a real integration.

[giskard09]

Mycelium Trails already runs this binding in production on Base mainnet. The action_ref → anchor_tx link you're describing is the canonical receipt envelope v1.0 — action_ref as primary key, anchor_tx as the on-chain immutability proof, trail_status: committed once the anchor confirms.

One addition for the Nobulex integration: nobulex:bilateral is documented in action-ref.md as a verified production scope anchor — commit 2f33ee5, section Scope conventions. The namespace-prefixing convention (<emitter>:<scope>) is in the spec with nobulex:bilateral as one of the four named examples, so cross-emitter portability is already covered at the spec level.

If you want to wire the integration directly: pip install mycelium-agt, POST to /agent/trail with the Nobulex proof bundle fields, get back action_ref + anchor_tx. The quickstart is at docs/guides/quickstart.md.

Stable spec ref: action-ref-v1.0

[agentauditAI]

Just to frame this correctly from the start: we see this as a peer integration between two complementary layers — pre-execution enforcement (Nobulex) + post-execution immutable evidence (AgentAudit AI) — not a plugin relationship in either direction.
The action_ref as primary key maps cleanly to how we anchor in AuditVault. I'll run your test vectors through the pipeline this week and report back on whether the action_ref reproduces correctly.
A few things I'll check on our end:

Receipt format compatibility with ZKAuditProof.sol (we anchor a hash, not the full payload — ZK-friendly by design)
MCP server exposure of the anchoring endpoint
ERC-XHRON IComplianceEvaluator interface fit

For the call: I'm UTC+0 (Iceland). Mornings work best — async GitHub first makes sense until the vectors pass, then a call to spec the integration properly.
One question: is the receipt format in v0/vectors.json stable, or still in flux?
— Piotr / AgentAudit AI — a RunLockAI product

[agentauditAI]

Ran your v0/vectors.json through our anchoring pipeline. Results:
✅ action_ref reproduces correctly — SHA-256 of JCS preimage maps directly to bytes32 logHash in verifyLog
✅ Merkle pipeline works end-to-end
✅ DENY receipts anchor identically to ALLOW
Three structural gaps documented, none block integration:

agent_id string → address (off-chain registry)
timestamp_ms vs block.timestamp (reconcile via contentURI)
SHA-256/keccak256 hybrid (valid, needs docs)

Test file: test/AuditVaultActionRef.t.sol — commit f538c13 on main.
Ready to move to next step. Call this week?
— Piotr / AgentAudit AI — a RunLockAI product

[arian-gogani]

@agentauditAI the vectors passing end to end is exactly what we needed. action_ref reproducing correctly as bytes32 logHash means the formats are compatible at the wire level.

on the three structural gaps you documented:

1. agent_id string to address: agreed, an off-chain registry is the right bridge. the nobulex receipt doesn't prescribe on-chain identity, so the mapping layer is yours to define.

2. timestamp_ms vs block.timestamp: reconciling via contentURI works. the receipt's timestamp_ms is the application-layer claim ("when the agent says it acted"). block.timestamp is the chain-layer claim ("when the anchor was placed"). both are independently meaningful. carrying both is stronger than collapsing to one.

3. SHA-256/keccak256 hybrid: valid design. the receipt uses SHA-256 for the action_ref preimage (JCS canonical). your contract uses keccak256 for on-chain verification. the bridge is the contentURI pointing back to the full SHA-256 receipt. worth documenting the mapping so verifiers know which hash covers what.

the receipt format in v0/vectors.json is stable. the four fields in the preimage (agent_id, action_type, scope, timestamp_ms) are locked. we just added policy_version and attempt_id as optional sibling fields (outside the preimage, same as authority_verified_at_ms).

for the call: i can do mornings UTC-7 which is afternoons for you. how about wednesday or thursday this week? we can spec the MCP server integration and the ERC-XHRON mapping.

one thing worth discussing on the call: your MCP server exposing the anchoring endpoint could be the fastest path to getting receipts flowing from any MCP-compatible agent. that's a distribution channel for both of us.

[agentauditAI]

All three gap mitigations land cleanly — aligned on the dual-timestamp model.
Good to know v0/vectors.json is stable. The four-field preimage lock + optional siblings model is clean — we'll document the SHA-256/keccak256 bridge in our integration spec.
Wednesday works. Morning UTC-7 = afternoon Iceland = good for me. 10am your time (17:00 Iceland)?
Agenda for the call:

MCP server anchoring endpoint spec
ERC-XHRON IComplianceEvaluator mapping
Distribution model — receipts flowing from any MCP-compatible agent

Agreed on the distribution angle — MCP server as the fastest path for both of us is exactly how we see it.
— Piotr / AgentAudit AI — a RunLockAI product

[arian-gogani]

wednesday 10am PT / 5pm iceland works. locked in.

agenda looks right. i'd add one item: defining the receipt schema version contract so both sides know what's stable and what might change. the preimage fields are locked but we should agree on which optional fields (policy_version, attempt_id, authority_verified_at_ms) the MCP server should expose vs keep internal.

see you wednesday.

[agentauditAI]

Hey — looking forward to Wednesday.

One thing I wanted to flag before we dive into the technical agenda: I think it'd be worth spending the first part of the call aligning on the collaboration framework itself — before we get into schema versioning and MCP exposure boundaries.

Specifically: what does this actually look like between Nobulex and AgentAudit? Loose technical compatibility, a formal reference implementation relationship, something deeper? I don't want us to make schema decisions without knowing what we're building toward together.

Happy to keep the technical items on the agenda — just wanted to make sure we don't skip the foundation. Let me know if that framing works for you.

See you Wednesday.

[arian-gogani]

good call. let's start with the framework.

my view: reference implementation partnership. nobulex is the receipt format, AgentAudit is the anchoring layer. both stay independent projects but we're the first official integration for each other. that means:

• nobulex docs point to AgentAudit as the recommended on-chain anchoring solution
• AgentAudit docs point to nobulex as the recommended receipt generation SDK
• we co-develop the MCP server spec so it works cleanly for both
• joint case studies once the integration is live

not a merger. not loose compatibility. a documented, maintained integration between two complementary layers.

the schema decisions flow from this: we make the receipt format stable because AgentAudit depends on it. you make the anchoring interface stable because nobulex depends on it. both sides have skin in the game.

that framing work for you? see you wednesday.

[agentauditAI]

framing works. agreed on all four points.

one thing — can we keep this async over email? got a throat infection and can't talk right now.

what's your email?

— Piotr / AgentAudit AI — a RunLockAI product

[arian-gogani]

nobulex.dev@gmail.com

makes sense, no rush on the call. async works better for spec decisions anyway since everything gets documented.

i'll send over the integration spec outline by email so we can iterate on it. the four points from last time still stand: reference implementation partnership, mutual docs, co-developed MCP server spec, joint case studies once it's live.

get well soon.

[giskard09]

Good timing on the AgentAudit integration — the on-chain anchoring layer over Nobulex receipts is a clean architecture.

One thing that would close the loop on the A2A v0.4 conformance side: a specimen run of your receipt derivation against the argentum-core conformance fixtures at giskard09/argentum-core/examples/conformance/. The fixtures cover the four-field preimage (agent_id, action_type, scope, timestamp_ms) with byte-verified SHA-256/JCS output.

You already have 16/16 byte-match from the autogen#7667 cross-validation — a specimen linking that result to the fixture set directly is what closes urn:nobulex:receipt row #4 in the CTEF matrix. A PR or a posted result in this thread both work.

[arian-gogani]

cross-validation against argentum-core conformance fixtures: 2/2 preimage vectors PASS.

  PASS  0001-giskard-baseline
         f4ebda732e3c063bdd8547c734e4956f...
  PASS  0002-dual-timestamps
         f09eb8c50dfa27a33cdb36efa08194bc...
  SKIP  0003-scope-namespace-collision-proof (envelope-only, no preimage)

derivation: SHA-256(JCS(preimage)) where JCS is json.dumps(obj, separators=(',',':'), sort_keys=True, ensure_ascii=False). byte-identical output from the nobulex Python implementation against the argentum-core action-ref-v1-baseline.fixture.json vectors.

note on field naming: argentum-core uses timestamp (ISO string), nobulex uses timestamp_ms (epoch integer). the JCS+SHA-256 derivation is identical in both cases since the canonical bytes are deterministic from whatever fields are in the preimage. the difference is a naming convention, not a format incompatibility. both systems produce byte-identical digests for the same input.

this should close urn:nobulex:receipt row #4 in the CTEF matrix.

existing nobulex cross-validation: 4 vectors across Python (rfc8785), JS (canonicalize), Go (gowebpki/jcs), Java (cyberphone). all 16/16 byte-match. adding argentum-core as the fifth implementation in the conformance set.