Skip to content

[FEATURE] Optional Signet integration for cryptographic tool-call receipts #5568

@willamhou

Description

@willamhou

Feature Area: Integration with external tools

Is your feature request related to an existing bug? NA


Describe the problem

CrewAI has no built-in mechanism to produce tamper-evident proof of what a tool, MCP server, or delegated agent actually executed. Post-hoc audits rely on mutable logs, which doesn't meet compliance requirements (EU AI Act Article 12, SOC 2) in regulated deployments. The example at crewAI-examples#369 covers ordinary structured tools but can't reach MCPToolExecutionStartedEvent or A2ADelegationStartedEvent without core access, so MCP-heavy and multi-agent crews have no solution.

Describe the solution you'd like

Add an optional crewai.integrations.signet module that registers a BaseEventListener producing Ed25519-signed receipts for every governed action. Zero impact on users who don't opt in — installed as a crewai[signet] extra.

Why a listener rather than an example or decorator:

  • Covers all three execution surfaces. @after_tool_call hooks only cover structured tools. A listener subscribing to paired Started/Completed events for ToolUsage*, MCPToolExecution*, and A2ADelegation* covers the full surface in one integration. The Started payload provides the signed input; the Completed payload provides the signed output; a single receipt is produced over both.
  • A2A delegation maps to signed delegation chains. CrewAI's A2A delegation events are a natural match for Signet's scoped delegation-chain receipts, which hook-based integrations can't capture.
  • Precedent for first-party listeners. crewai/events/listeners/tracing/ demonstrates that domain-specific listeners with no runtime cost for non-users are acceptable in core. An optional extra follows the same contract.

Proposed shape (illustrative, details open):

from crewai.integrations.signet import install

install(key_name="my-crew-agent", audit=True)
# Every tool call + MCP call + A2A delegation now produces a signed receipt.

Internals:

lib/crewai/src/crewai/integrations/signet/
  __init__.py                  # install() public API
  listener.py                  # SignetEventListener(BaseEventListener)
  config.py                    # SignetConfig (key_name, audit, policy_path)

tests/integrations/signet/     # mocked SigningAgent, event → receipt assertions
docs/integrations/signet.md    # user-facing doc

Dependency story:

  • signet-auth is not added to CrewAI's required dependencies.
  • Listed as an optional extra: pip install crewai[signet].
  • listener.py lazy-imports signet_auth and raises a clear ImportError if the extra isn't installed.
  • Zero runtime cost for users who don't opt in.

Long-term maintenance: we commit to maintaining the integration, responding to issue escalations, and keeping it in sync with CrewAI releases.

Alternatives considered

  • Stay in examples only (crewAI-examples#369). Doesn't cover MCPToolExecutionStartedEvent or A2ADelegationStartedEvent without touching core — MCP-heavy and multi-agent crews have no path.
  • Decorator-only (@before_tool_call / @after_tool_call). Works for structured tools but misses MCP and A2A events.
  • Standalone crewai-signet package maintained by us. Viable if core isn't the right venue; discoverability is lower but we're equally open to this if maintainers prefer.

Additional context

Signet is an open-source (Apache-2.0) Ed25519 cryptographic signing SDK for AI agent tool calls. Core properties:

  • Ed25519 signatures over JCS (RFC 8785) canonicalized payloads — tamper-evident
  • Delegation chains with scoped authority — matches A2A delegation semantics
  • Policy attestation co-signed with the action — decision and evidence verifiable together

Repo: https://github.com/Prismer-AI/signet

Relevant existing discussion:

Before drafting a PR, a few questions:

  1. Are third-party signing integrations in core welcome at all? If not, we're equally interested in being referenced in official docs or a separate crewai-signet package under our org.
  2. Is crewai/integrations/ the right location? Or is there a preferred home (e.g., crewai/extras/)?
  3. Is the install() + listener pattern preferred over a decorator-only approach? Listeners cover more surface (MCP + A2A); decorators are lighter.

Willingness to Contribute

Yes, I'd be happy to submit a pull request.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions