atrib

Verifiable agent actions. Every action becomes signed context for the next.

atrib signs agent actions as records that later agents, teams, and verifiers can check. A record can describe a tool call, browser click, desktop action, policy decision, handoff, transaction, or intentional note from the agent.

Agent work already crosses tools, memory, identity, authorization, observability, evals, handoffs, and payment rails. atrib does not replace those systems. It gives them a common record that carries the action, selected evidence, and graph links across sessions, agents, teams, organizations, and protocols.

Product teams can put atrib in the execution path. A harness can sign an allow, block, or escalate decision before a high-impact browser click, desktop action, support reply, admin change, deployment, or payment-impacting step. The outcome then becomes signed context for later recall, review, handoff, or verification.

Browser and computer-use agents make the product concrete. Follow-up work can cite the decision and outcome without exposing raw browser state, desktop state, private tool payloads, or full runtime logs in public records.

Shared memory and context systems still decide what an agent should remember. Observability tools still inspect live runs. Authorization systems still issue policy and credentials. atrib signs the action trail so those systems can carry forward the same verifiable facts without trusting the runtime that stored them.

What this enables

Everything below depends on one substrate property: an action is signed when it happens and remains verifiable later.

Substrate vs harness

atrib is the substrate underneath the action layer. Consuming it well (surfacing an agent's history at session start, exposing recall tools the agent can call, persisting signed records locally for replay, and putting policy gates around high-impact actions) is the job of an agent harness or runtime. atrib does not prescribe a harness. The substrate is independently useful to any harness (Claude Code, Cursor, custom agent products, in-house agent runtimes) that wants to give agents and teams contextual awareness, coordination, control, and proof over work the agent performs.

Hard boundary: the public Merkle log proves a commitment, but it is not enough context for a future agent to continue the work. A continuation agent needs Tier 2 and Tier 3 material: canonical record bodies or archive references, redacted evidence references, skill pack identities and hashes, the latest chain tail, parent dispatch anchors for subagent work, and provenance anchors. Without those, it can prove a record existed but still has to guess what happened.

One canonical harness pattern is signed diagnostic outcome + trace replay: sign the action, sign the diagnostic outcome that evaluates it with informed_by back to the action, then let the next repair step walk informed_by back from the diagnostic record with recall. This keeps "what happened" and "what it supersedes" in one verifiable path without requiring a whole-session transcript dump.

Derived evidence products sit above the protocol. A harness can build a prior-work packet, suspect report, or eval summary from signed records, body commitments, verifier checks, and inclusion proofs. Those products can decide which records are useful for a task, which stale records to avoid, and which risks remain open. They do not change the record format, the graph derivation rules, or the attest/recall verb surface.

Logs and traces

Logs and traces are primary integration inputs for atrib, but the word "trace" can point at several different objects. The boundary matters.

The short rule: observability tools inspect and debug live traces; runtime systems own logs that reconstruct or resume a run; atrib signs actions and verifies claims over selected windows. Those layers compose, but they should not collapse into one product.

Frameworks and host runtimes

The "any agent framework" claim is about tool-call middleware, not every host runtime feature. It covers SDK and MCP surfaces where application code owns the agent loop: raw MCP SDK, Claude Agent SDK, Cloudflare Agents, Vercel AI SDK, LangChain JS, and similar SDKs. Those integrations live in @atrib/agent, @atrib/mcp, and @atrib/mcp-wrap.

Host runtime adapters cover a different shell: Claude Code, Codex, OpenClaw, Hermes, Cursor, Goose, hosted runtimes, or another harness that owns sessions, lifecycle hooks, approvals, subagents, checkpoints, telemetry, and run logs. Those adapters use @atrib/mcp-wrap for MCP tool calls, host-specific signing code for native tool hooks, @atrib/openinference for OpenInference-shaped span intake, @atrib/runtime-log for bounded run windows, @atrib/action-gate for pre-action policy gates, @atrib/verify for accepted handoff claims, and atrib-attest-cli (or the forwarded atrib-emit-cli) or the local substrate for hook-class observations.

The implementation rule: one host event has one signing owner. If an MCP wrapper already signs a tool call, the host adapter should correlate ids and skip a second tool_call record. The private integration package pins this rule in packages/integration/src/host-runtime-proof.ts so future OpenClaw, Hermes, and other host proofs share the same vocabulary.

How it works

• Each record is signed by the actor's Ed25519 key and JCS-canonicalized
• A Merkle log stores commitments (hashes, not content) with RFC 6962 inclusion proofs and C2SP-canonical signed-note checkpoints
• Nine deterministic edge types connect actions into one graph with two reading planes: chronology edges (CHAIN_PRECEDES, SESSION_PRECEDES, SESSION_PARALLEL, CROSS_SESSION, CONVERGES_ON) and declared-relationship edges (INFORMED_BY, PROVENANCE_OF, ANNOTATES, REVISES)
• The explorer's primary trace path composes /v1/trace and /v1/chain for readability without adding a new graph edge, validity rule, or settlement input (D118)
• A pure-function calculation maps graph + policy to value distribution when commerce closes
• A public-key directory (§6) resolves opaque keys to identity claims; rotation and revocation are normative (§1.9); identity claims may declare capability envelopes (§6.7) that verifiers check records against
• Transaction records require cross-attestation: at least 2 distinct verified signer keys (agent + counterparty) per §1.7.6
• Cross-log replication (§2.11) lets consumers submit records to multiple independent logs and detect equivocation
• Privacy is configurable per record (§8 privacy postures): tool_name forms (verbatim, opaque, hashed), commitment schemes (plain, salted-sha256, hmac-sha256), timestamp granularity (ms through day)
• Adversarial threat model (§8.7) enumerates the 10-layer trust assessment stack the substrate provides

No custom cryptography. No content exposure unless the harness opts in. No trust required.

Try the demo

One command, no setup beyond cloning. Generates a fresh key, spins up an in-process Merkle log, fake merchant, and fake agent, runs two tool calls plus one transaction, and prints what landed in the log.

ATRIB_PRIVATE_KEY=$(node -e 'console.log(Buffer.from(crypto.randomBytes(32)).toString("base64url"))') \
  pnpm --filter @atrib/integration demo

Expected output:

[demo] starting dev log...
[demo] dev log running at http://127.0.0.1:58958
[demo] starting merchant tool server (fake search API)...
[demo] starting agent client...
[demo] agent connected to merchant

[demo] step 1: agent calls 'search' for the first time (genesis)
[log] +tool_call   ctx=7f71199d… chain=sha256:064692c27… idx=0

[demo] step 2: agent calls 'search' again (chained from step 1)
[log] +tool_call   ctx=7f71199d… chain=sha256:381c22ac6… idx=1

[demo] step 3: agent observes a fake x402 payment receipt
[log] +transaction ctx=7f71199d… chain=sha256:96ac3e962… idx=2

[demo] final state
[demo] 3 records in the log
[demo]   2 tool_call records
[demo]   1 transaction record
[demo] chain length: 3
[demo] done.

The signatures, chain hashes, and transaction detection are production code. Only the surrounding environment (merchant, agent, network) is stubbed.

Quick start

Now that you've seen the demo, pick the install path that matches what you're doing:

• Sign tool calls your MCP server handles: @atrib/mcp (below)
• Sign tool calls your agent makes: @atrib/agent (below)
• Gate high-impact actions before they run: @atrib/action-gate
• Attach signed records to an existing OpenInference span stream: @atrib/openinference
• Prove a bounded run window from a host-owned runtime log: @atrib/runtime-log
• Verify records someone else produced: @atrib/verify (below)

Sign tool calls (your MCP server)

import { atrib } from '@atrib/mcp'
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'

const server = atrib(new McpServer({ name: 'my-tool', version: '1.0.0' }), {
  creatorKey: process.env.ATRIB_PRIVATE_KEY,
  serverUrl: 'https://my-tool.example.com',
})

One line. Every successful tool call emits a signed attribution record, propagates W3C trace context, and submits to the log asynchronously.

Sign tool calls (your agent)

@atrib/agent exports one interceptor plus a helper per framework; side-by-side quick-starts live in its README. Every runnable example and proof, one per framework or runtime surface, is cataloged in Examples and proofs below.

Verify records (any third party)

import { AtribVerifier } from '@atrib/verify'

const verifier = new AtribVerifier({
  merchantKey: process.env.ATRIB_MERCHANT_KEY,
})

const result = await verifier.verify(recommendationDoc)
// { valid: true, signatureOk: true, calcMatch: true, distribution: {...} }

Verification re-runs the payments profile §8 calculation locally and compares the result. No trust in any intermediary.

What atrib certifies, what it does not

atrib certifies five verifiable axes of agent activity: who acted (identity), what they did (event_type), when (timestamp), what came before what in the chronology plane, and what the signer claimed informed, anchored, annotated, or revised the action in the declared-relationship plane.

atrib does NOT certify that the agent's reasoning is truthful, that prior records actually influenced subsequent decisions, or that tool responses were real absent tool-side attestation. A signature proves who committed to a claim, never that the claim is true. The first two limits are intrinsic to signed claims. The third narrows when another party signs its own evidence: the tool signs its response, a counterparty co-signs a transaction, an evaluator signs a diagnostic, or a witness attests the outcome. Those signatures corroborate the action, not the agent's reasoning. The substrate is content-preserving (commitments, not content) and disclosure-configurable: harnesses pick how much each record reveals via the privacy postures in spec §8.

This positioning keeps the claim honest. See spec §3 "What atrib chains, what it does not" for the detailed enumeration and spec §7.6 for the outcome-verification patterns that close the tool-response gap.

Framework support

This table covers framework tool-call middleware, not full host runtime integration. Host runtime work has its own boundary in Architecture and in the OpenClaw/Hermes map.

Examples and proofs

Each row is a runnable example or a pinned proof artifact under packages/integration/examples/ (proof packets under proof-packets/). Start with the row matching your stack.