Atrib

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.

| Surface | What atrib gives you | What it composes with | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Action control | A host can sign an allow, block, escalate, or approval decision before a selected action runs. The outcome cites the decision, so later review can see what was proposed and what actually happened. | [@atrib/action-gate](packages/action-gate/README.md), policy engines, approvals | | Cross-session continuity | Signed action hashes can travel with follow-up work. Later sessions and agents can cite accepted records instead of relying on a transcript, replay link, or runtime-local memory. | Memory systems, shared context layers, recall tools, agent runtimes | | Browser and desktop review | Clicks, form fills, desktop actions, support replies, admin changes, and payment-impacting steps become decision/outcome pairs that can be recalled or verified later. | Browserbase, browser-use, OpenAI Computer Use, support teams, admin teams | | Verified handoffs | A receiving agent can verify incoming record hashes, body commitments, signer trust, context policy, freshness, and inclusion proofs before signing follow-up work through informed_by. | [@atrib/verify](packages/verify/README.md), [@atrib/verify-mcp](services/atrib-verify/README.md), [continuation packets](packages/verify/README.md#verifyhandoffclaimsclaims-options-promisehandoffverificationresult) | | Investigations and audit | Support, incident, billing, and RCA agents can sign ticket intake, scoped log reads, code-path checks, hypotheses, diagnostics, revisions, and human handoffs. A reviewer can verify the path without trusting the original runtime. | Observability tools, logs, traces, support systems, SOC 2 evidence | | Evals and repair loops | A harness can link task setup, tool calls, verifier checks, diagnostic outcomes, and scorer output through informed_by, then publish evidence another team can replay. | Eval harnesses, benchmark reports, inspection tools | | Commerce settlement | The same signed record set can feed a deterministic settlement document under an agreed policy. Any merchant or auditor can recompute the [§4.6](atrib-spec.md#46-the-calculation-algorithm) result. | AP2, Verifiable Intent, x402, ACP, merchant policies | | Private evidence by default | The public log stores commitments, not private work product. Verifiers can check signatures, hashes, inclusion proofs, and selected evidence without dumping tool arguments, tool results, memory text, authorization material, or workflow context into the public payload. | Local mirrors, sidecars, opt-in archive evidence, private evidence stores |

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 call atrib-trace from the diagnostic record. 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 seven cognitive primitives.

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.

| What you already have | Use | What atrib adds | | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Tool calls through MCP or an SDK callback | [@atrib/mcp](packages/mcp/README.md), [@atrib/mcp-wrap](packages/mcp-wrap/README.md), or [@atrib/agent](packages/agent/README.md) | Signed action records with chain continuity and optional local sidecars. | | Pre-action policy gates, approval hooks, or host lifecycle hooks | [@atrib/action-gate](packages/action-gate/README.md), [@atrib/mcp-wrap](packages/mcp-wrap/README.md) preCallTransform, host-specific adapters, and [signer proxies](packages/integration/examples/signer-proxy/README.md) | Verifiable control points around high-impact actions. The host records the decision, execution result, outcome hash, and selected evidence. | | OpenTelemetry or OpenInference spans | [@atrib/openinference](packages/openinference/README.md) | Signed records and recall-readable sidecars from the span stream, while Langfuse, Phoenix, LangSmith, Braintrust, or another backend keeps the operations view. | | A host-owned run log, event stream, session history, checkpoint log, fork log, or compaction log | [@atrib/runtime-log](packages/runtime-log/README.md) | A log_window_manifest that commits to the bounded run window, roots, projections, receipts, and redaction policy without publishing raw log bodies by default. | | A hosted runtime API that exports session events after the fact | A future per-runtime adapter under [Pattern 5](ARCHITECTURE.md#runtime-integration-patterns) | Consumer-side attestation over what the vendor reported, not a claim that the vendor's private runtime state is itself true. | | A handoff, support investigation, or continuation packet | [@atrib/verify](packages/verify/README.md), [@atrib/verify-mcp](services/atrib-verify/README.md), and [continuation packets](packages/verify/README.md#verifyhandoffclaimsclaims-options-promisehandoffverificationresult) | Verifier-accepted record hashes that the receiving agent can cite through informed_by. |

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](packages/agent/README.md), [@atrib/mcp](packages/mcp/README.md), and [@atrib/mcp-wrap](packages/mcp-wrap/README.md).

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](packages/mcp-wrap/README.md) for MCP tool calls, host-specific signing code for native tool hooks, [@atrib/openinference](packages/openinference/README.md) for OpenInference-shaped span intake, [@atrib/runtime-log](packages/runtime-log/README.md) for bounded run windows, [@atrib/action-gate](packages/action-gate/README.md) for pre-action policy gates, [@atrib/verify](packages/verify/README.md) for accepted handoff claims, and 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](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](DECISIONS.md#d118-primary-trace-path-is-a-presentation-rule-over-trace-and-chain))

• A pure-function calculation maps graph + policy to value distribution when commerce closes
• A public-key directory ([§6](atrib-spec.md#6-key-directory)) resolves opaque keys to identity claims; rotation and revocation are normative ([§1.9](atrib-spec.md#19-key-rotation-and-revocation)); identity claims may declare capability envelopes ([§6.7](atrib-spec.md#67-capability-declarations)) that verifiers check records against
• Transaction records require cross-attestation: at least 2 distinct verified signer keys (agent + counterparty) per [§1.7.6](atrib-spec.md#176-cross-attestation-requirement-for-transaction-records)
• Cross-log replication ([§2.11](atrib-spec.md#211-cross-log-replication)) lets consumers submit records to multiple independent logs and detect equivocation
• Privacy is configurable per record ([§8](atrib-spec.md#8-privacy-postures) 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](atrib-spec.md#87-adversarial-threat-model)) 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 receip

…

## Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [creatornader](https://github.com/creatornader)
- **Source:** [creatornader/atrib](https://github.com/creatornader/atrib)
- **License:** Apache-2.0
- **Homepage:** https://atrib.dev

Install and usage instructions live in the source repository linked above.