feat: add Nobulex — Ed25519 action receipts as external execution evidence

[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 #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”?