Provenance from tools/call — receipts, not screenshots

2026-08-03 HUMΛN Team Governance 12 min

Every governed MCP invocation should leave an attributable receipt. If the agent acted, the ledger can say who, under which delegation, and why.

Chat logs are not an audit trail. They are literature.

When an MCP client fires tools/call against HUMΛN, the interesting artifact is not the model’s narration — it is the receipt: which principal, which delegation, which tool, which outcome, chained into provenance the org can query later.

The hook: “the agent sent it”

Support asks why a customer got an email. Someone pastes a Cursor transcript. Legal asks for the decision record. The transcript has vibes. The ledger has — or should have — attribution.

What “provenance from tools/call” means

On the org mesh and Companion paths, execution rides HumanOS: delegation checks, risk gates, and provenance emission. Observatory / CLI evidence surfaces exist so operators can inspect runs without spelunking Redis.

You should be able to answer:

  1. Who — Passport / org / agent DIDs on the grant
  2. What — tool name + parameters (redacted per policy)
  3. Under which rules — scopes and policy packs that allowed it
  4. What happened — success, denial, escalation

If any of those are missing, you do not have MCP-as-colleague — you have MCP-as-rumor.

So that attributable agents beat anonymous automation

HUMΛN’s category claim is the trust layer between people and AI. Trust without receipts is branding. MCP is where agents actually act; provenance is how those acts remain contestable.

Scroll-stopper: If you cannot name the delegation on a tools/call, you do not have governance — you have a ghost with API keys.

Pair with field notes

For the human-readable shape of a receipt, read What a decision receipt looks like. This essay is the MCP-shaped version of the same demand.

Go deeper