The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Assay listing page.
The open, recomputable evidence profile for privileged MCP tool actions.
Assay records what a privileged tool call decided, what was observed, and what stays unproven, so a reviewer can replay the claim offline instead of trusting the agent's account of itself. Enforcement is deterministic and fail-closed, and the enforcing proxy is the reference producer rather than the contract itself. Kernel-level (eBPF/LSM) observation on Linux is an optional stronger vantage. CI-native, no backend, bounded by design.
Quickstart · How it works · See it work · MCP example · OWASP MCP Top 10 · Discussions
Agents got real tool access through MCP — and tool poisoning, rug pulls, and confused-deputy OAuth came with it. Most tools scan a server or filter a prompt. Assay sits at the tool-call boundary and does three things, in order.
One golden path: the release-pinned agent journey records the nine driven CLI/MCP steps and their exit/stdout contracts. Its protected-action fixture lives in examples/privileged-action-gate/.
tools/call before it runs, with the precise reason for each allow or deny. On Linux it adds real kernel enforcement — an eBPF/LSM IPv4/TCP connect-egress block and a Landlock TCP-connect port allowlist, both opt-in and fail-closed. A policy it cannot express exactly is refused, never half-applied.verified, self_reported, inferred, absent), and a gate refuses to let a claim exceed what was observed. A tool returning "success" is the provider's assertion, never proof. Assay ships no single safety score and never claims more than it can prove.For v6.2.1, run the last command from a source checkout or an extracted published CLI archive.
The installer is binary-only and does not carry the bounded quickstart assets. The live
getassay.dev installer verifies the selected archive against its published SHA-256 sidecar before
extraction. Set ASSAY_REQUIRE_PROVENANCE=1 to additionally require GitHub artifact provenance;
the default reports provenance_not_requested and strict success reports provenance_verified.
A checksum proves byte equality with the published sidecar, not producer identity. Provenance
identifies the source and build, not runtime safety or semantic correctness.
Captured runner output (the bundled local mock performs no external action):
Released surfaces:
assay mcp config-path supports Claude and Cursor only.assay-mcp-server archives cover Linux x86_64/arm64. MCPB and server.json package descriptors are also published; their presence is not host-discovery proof.| Output | What it is |
|---|---|
| Policy gate | assay mcp wrap — deterministic allow/deny before tools run, with the reason. |
| Evidence bundle | Offline-verifiable, tamper-evident archive for audit and replay. |
| Trust Basis / Trust Card | Canonical trust-basis.json (bounded claim classification) plus review-friendly trustcard.{json,md,html}. |
| External receipts | Eval outcomes, runtime decisions, and model inventory as bounded receipts with JSON Schema contracts. |
| Tool-decision surface | Each privileged tools/call recorded as assay.tool_decision_surface.v0 — sensitive ids hashed, raw arguments never stored. |
| SARIF / CI | GitHub Action, Security-tab integration, policy gates on PRs. |
| Attestation | Sign an evidence bundle as a DSSE-wrapped in-toto v1 Statement with the evidence-bundle/v1 predicate. |
Current release: v6.2.1. CHANGELOG.md and release notes remain the authority for released behavior; merged changes after the tag are Unreleased, and crates.io publication is separate from merge state.
Yes if you already have eval output, runtime decisions, inventory artifacts, or MCP tool-call tests, and you want a small reviewable CI artifact instead of a dashboard — bounded auditability, not a scalar trust badge.
Not yet if you need Assay to judge model correctness for you, want a hosted dashboard as the product, or want a compliance claim rather than a bounded evidence boundary. Assay is not a trust-score engine, a generic eval dashboard, or a hosted observability product — see what it is and is not.
An agent tries a privileged action — github.add_deploy_key — through the enforcing proxy, decided per call before it forwards, offline against a local mock (no real credentials):

A deny is fail-closed caution, not a verdict on intent; an allow is the decision to forward, never proof the action happened. Declared-vs-observed conformance is recorded beside the verdict, never as a gate. Full walkthrough: privileged-action-gate.
| You have | What you get | Start here |
|---|---|---|
| Promptfoo JSONL from CI evals | Eval outcome receipts + verified bundle + Trust Basis diff | Promptfoo JSONL |
OpenFeature EvaluationDetails | Decision receipt + verified bundle | OpenFeature |
| CycloneDX ML-BOM model component | Inventory receipt + verified bundle | CycloneDX ML-BOM |
| MCP tool calls | Allow/deny audit trail + observed-behavior evidence | MCP Quick Start |
| A GitHub PR gate | Trust Basis diff, gate status, SARIF/JUnit-ready output | CI Guide |
| A Runner archive / coverage annotation | Coverage descriptors + claim-class cells + a claimed-vs-observed check | Coverage-honesty walkthrough |
The workflow stays small: import or record a bounded outcome, bundle and verify it, compile trust-basis.json, gate the Trust Basis diff. Assay doesn't make the upstream tool the source of truth; it makes the evidence boundary inspectable. For privileged tool actions, the MCP proxy records each tools/call as a structured tool-decision surface — keeping the asserted-versus-verified line honest.
assay init --from-trace trace.jsonl generates the runtime-observation policy used by the trace-generation flow (files, network, and processes); it is not an MCP authorization policy. Migrate a legacy MCP constraints: policy with assay policy migrate. See Policy Files.
| Canonical evidence | Assay's evidence model is the stable contract; OpenTelemetry and protocol adapters (ACP / A2A projection profile / UCP) map into it. |
| Deterministic | Same input, same decision — not probabilistic. |
| Bounded claims | Explicit about verified vs visible vs absent — no score-first UX. |
| Offline-first | No backend required for core enforcement and bundle verification. |
| Checkable provenance | Which piece of the source-class and coverage model shipped when, as commits you can git log rather than claims you have to take — provenance, prior art credited first. |
resultType and interim-result compatibility corpusTrust claims use explicit epistemology, not a single safety score: verified (direct evidence or offline verification), self_reported (emitted without independent corroboration), inferred (bounded, documented rules), absent (no trustworthy evidence). Assay ships no aggregate trust score or safe/unsafe badge as the main output — see ADR-033.
Tool-decision path latency on an M1 Pro fragmented-IPI harness: main protection 0.771ms p50 / 1.913ms p95; fast-path 0.345ms p50 / 1.145ms p95. These are tool-decision timings, not end-to-end model latency.
Assay-Runner is an internal measured-run subsystem behind the delegated Linux/eBPF acceptance path — publish = false, not a standalone product, no release commitment.
Repositories that compose with Assay's evidence layer:
sha256:e769822bc6c9e31085da7b1a17b163b9747fe0d04314fbb8685d4e612087c7cb and the current v2 digest sha256:ba0e3795d75c788fa48313ab462493f22d78759851d1b3275d8117051bb22fd0 (95 vectors) each carry one reported independent implementation by a second author on a different stack. JM-Lab reported the v2 95/95 reproduction on 2026-08-24, from the contract text and author-supplied inputs without reading expected. See its REPRODUCTIONS.md.privileged-mcp-action/v0
is a composition and verification contract over evidence records that already exist: what a
privileged MCP tool call decided, what was observed of its effect, and what stays unproven. It adds
no new envelope and no aggregate verdict.
It ships with a 14-vector conformance corpus (5 accept, 9 reject) whose digest is a candidate: it is not called reproduced until a non-author implementation derives the expected outcomes from the specification text alone.
That reproduction is open, and the invitation is real: #1840. Any language, any stack. The invitation names the exact commit the current digest describes. The clean-room protocol provides an opaque, attested inputs pack, a one-command scoring action, and an implementation-report template without supplying verifier logic or expected outcomes. The corpus README states the authorship boundary and the claim ceiling.
See CONTRIBUTING.md and GitHub Discussions.