[arian-gogani]

What this adds

Nobulex integration under integrations/nobulex/.

Nobulex emits Ed25519-signed, JCS-canonical (RFC 8785) receipts for agent actions. Each receipt carries action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms})) as a content-derived identifier — the same construction described in trace-spec #34 for external execution evidence.

Claim verification

All claims in the README are reproducible against the released PyPI package:

pip install nobulex
python3 -c "
from nobulex import Agent
agent = Agent('my-agent')
receipt = agent.act('tool_call', scope='resource:read')
assert receipt.verify(), 'signature verification failed'
assert len(receipt.action_ref) == 64, 'action_ref not SHA-256 hex'
print('PASS')
"

What this does NOT claim

Nobulex receipts are not TRACE Trust Records. The README is explicit: these are per-action signed assertions that a verifier can optionally check alongside a Trust Record, as described in trace-spec #34. No TRACE conformance level is claimed.

Related

• trace-spec build(deps): bump scikit-learn from 1.5.2 to 1.9.0 #34 — external execution evidence verification guidance (this integration is the reference for what an issuer produces)
• Add Nobulex to Audit & Accountability awesome-ai-governance#7 — Nobulex already listed there (closed)

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	NONE
Overall	HIGH

Automated check by AGT Contributor Check.

[carloshvp]

Nice fit for the external-evidence family, and I like that the README clearly says Nobulex receipts are not TRACE Trust Records.

One mapping detail from the cMCP #301 thread may be worth making explicit before merge. #301’s current external_execution_evidence envelope is issuer, issuer_key_id, signature, evidence_hash, evidence_type, and linked_call_id, with the verifier checking linked_call_id == audit_entry.call_id.

The Nobulex receipt shape is close in spirit, but not the same wire shape: it exposes agent_id, action_type, scope, timestamp_ms, verdict, action_ref, signature, and signer_public_key, where action_ref is a hash over {agent_id, action_type, scope, timestamp_ms}. So if the intended cMCP mapping is “use action_ref as linked_call_id,” the integration should spell out the adapter rule: either cMCP’s call_id must be set to that action_ref, or the Nobulex receipt needs to be wrapped inside a cMCP-compatible external_execution_evidence object whose linked_call_id equals the actual audit entry call id.

Could you add a short mapping section, or soften the wording from “can be attached as external_execution_evidence” to “can be adapted into the external-evidence pattern tracked in trace-spec#34 / cMCP #301”?

[imran-siddique]

Clean integration entry. Claims are accurate and scoped correctly — the README is explicit that Nobulex receipts are not TRACE Trust Records, which is the right framing. Verify command in the PR body is reproducible. Merging.

[imran-siddique]

@arian-gogani, thanks for your work on the Nobulex integration in the AgenTrust marketplace.

We’ve launched the AgenTrust LinkedIn page and will soon start highlighting community work. If that interests you, follow the page for updates.

If you’d like to suggest something for us to cover, use the Message button on the AgenTrust page and send a link plus a few lines about your integration, a demo, or a lesson from building it. Please send suggestions to the page inbox so we can keep them together there.

[arian-gogani]

You merged the bilateral receipt signing work into the toolkit back in April, and the integration entry in September, so you have seen how I work rather than just a pitch.

I am taking on paid work now, and you are the person I most want to ask, because Opaque sits exactly where the failure I keep finding lives: a control that is supposed to refuse and returns a pass instead.

The specific thing I do: take one enforcement path, reproduce its current behavior on a pinned revision, find the inputs where it permits what it should block, and leave a regression test that fails on the old code and passes on the fix. Recent examples, all public and all in other people's repositories: a governance sample that executed on an unrecognised verdict, a key-distinctness check whose own error string promised a separateness it never verified, and an idempotency claim that metered a retried event zero times while returning success.

Two ways this could be useful to you, and I am guessing at which, so tell me if neither fits:

One bounded review of a single enforcement path in the toolkit or in Opaque's own agent surface, delivered as a written finding set plus the regression tests, $2,000 fixed. I would tell you before starting if I thought the path was too large to do properly at that price.

Or, if a review is not the shape you need, an ongoing arrangement where I work through the toolkit's enforcement surfaces at a fixed monthly amount and you get the findings and tests as they land.

If the answer is no, I would genuinely value knowing whether it is the price, the scope, or that this is not something Opaque would pay anyone for. I have been doing this work free for eight months and I am trying to find out whether it has a buyer at all, so a clear no is worth more to me than a polite maybe.

[arian-gogani]

Correction to my comment above: I said all three examples were in other people’s repositories. That was wrong. The key-separation check is in my own repository, Nobulex (research/receipt-billing-edge). The OpenMeter undercount issue is openmeterio/openmeter#5118, authored by @aurumflux20; that is their finding, not mine, and I did not discover it. The AutoGen example is my report in microsoft/autogen#8301. I should not have presented these as three examples of my work in others’ repositories. Please assess my offer without that claim. I apologize.