assay-mcp-server
The assay-mcp-server provides policy-based validation and analysis for MCP tool calls, enabling deterministic enforcement, coverage analysis, and trace explanation for AI agent actions:
assay_check_args: Validate tool arguments against a policy schema, catching constraint violations before execution.assay_check_sequence: Determine if a proposed tool call is allowed given a history of previous tool calls — enabling stateful, context-aware enforcement.assay_policy_decide: Perform a straightforward allow/deny decision for a specific tool against a policy, returning a deterministic verdict with the reason.assay_check_coverage: Analyze execution traces to determine how well they cover the rules in a policy, with support for a coverage threshold and output in JSON, Markdown, or GitHub-compatible formats.assay_explain_trace: Produce a human- or machine-readable explanation of how a trace was evaluated against a policy, available in JSON, Markdown, terminal, or HTML formats.
Integrates with GitHub Actions to block PR regressions through Trust Basis diffs and produce SARIF/JUnit-ready output for policy gates.
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/.
Enforce, prove, stay honest
Enforce. A deterministic, fail-closed gate decides every
tools/callbefore 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.Prove. Each decision and observed effect becomes an offline-verifiable, tamper-evident evidence bundle: the verdict, the pre-call establish journey, and declared-vs-observed conformance — all reviewable in CI, with no hosted backend.
Stay honest. Every claim carries its basis (
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.
Quickstart
cargo install assay-cli --version 5.4.0 --locked
mkdir -p /tmp/assay-demo && echo "safe content" > /tmp/assay-demo/safe.txt
assay mcp wrap --policy examples/mcp-quickstart/policy.yaml \
-- npx @modelcontextprotocol/server-filesystem /tmp/assay-demo✅ ALLOW read_file path=/tmp/assay-demo/safe.txt reason=policy_allow
❌ DENY read_file path=/tmp/outside-demo.txt reason=path_constraint_violation
❌ DENY exec cmd=ls reason=tool_deniedProject manifests are shipped for Claude Code and Cursor; Codex uses the equivalent TOML entry documented in the editor MCP recipe. assay mcp config-path supports Claude and Cursor only. Python SDK: pip install assay-it. CI: GitHub Action. No hosted backend and no API keys for core flows. New to the threat model? The OWASP MCP Top 10 mapping lays out, per risk, what Assay covers and what it deliberately does not.
What ships
Output | What it is |
Policy gate |
|
Evidence bundle | Offline-verifiable, tamper-evident archive for audit and replay. |
Trust Basis / Trust Card | Canonical |
External receipts | Eval outcomes, runtime decisions, and model inventory as bounded receipts with JSON Schema contracts. |
Tool-decision surface | Each privileged |
SARIF / CI | GitHub Action, Security-tab integration, policy gates on PRs. |
Attestation | Export a bundle as an in-toto / DSSE statement (v0), anchor-pluggable. |
Agent ──► Assay ──► MCP Server
├─ ✅ ALLOW / ❌ DENY (policy, with reason)
├─► 📋 Evidence bundle (offline-verifiable)
└─► 📊 Trust Basis → Trust Card → SARIF / CICurrent release: v5.4.0. 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.
Related MCP server: governed-mcp
Is this for me?
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.
See it work
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):
cd examples/privileged-action-gate && ./run.sh
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.
Pick your path
You have | What you get | Start here |
Promptfoo JSONL from CI evals | Eval outcome receipts + verified bundle + Trust Basis diff | |
OpenFeature | Decision receipt + verified bundle | |
CycloneDX ML-BOM model component | Inventory receipt + verified bundle | |
MCP tool calls | Allow/deny audit trail + observed-behavior evidence | |
A GitHub PR gate | Trust Basis diff, gate status, SARIF/JUnit-ready output | |
A Runner archive / coverage annotation | Coverage descriptors + claim-class cells + a claimed-vs-observed check |
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.
Policy is simple
version: "2.0"
name: "my-policy"
tools:
allow: ["read_file", "list_dir"]
deny: ["exec", "shell", "write_file"]
schemas:
read_file:
type: object
properties:
path: { type: string, pattern: "^/app/.*" }
required: ["path"]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.
Why Assay
Canonical evidence | Assay's evidence model is the stable contract; OpenTelemetry and protocol adapters (ACP / A2A / 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 |
Learn more
MCP Quickstart · Editor MCP recipe — policy-enforcing MCP in Cursor / Claude Code / Codex
MCP 2025/2026 protocol-era parity — pinned
resultTypeand interim-result compatibility corpusCoding-agent governance · OpenTelemetry & Langfuse — observed runs → evidence
Evidence Receipts in Action — Promptfoo / OpenFeature / CycloneDX receipt families
CI Guide · Evidence Store (S3 / B2 / MinIO)
Trust 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.
Ecosystem
Repositories that compose with Assay's evidence layer:
assay-action — GitHub Action: verify bundles, PR summaries, SARIF (Marketplace).
Assay-Harness — recipe, gate, and report layer over canonical evidence artifacts.
observed-effect-v0 — worked examples of the bounded observed-effect evidence record and its neutral carriers (in-toto, SCITT, MCP evidenceRef).
gateway-evidence-replay — deterministic offline replay verifier for gateway-path evidence bundles.
RGE-Bench — a conformance kit for evidence reviewability, maintained separately under its own machine-checked neutrality guard. Reproduction there is digest-scoped and does not carry forward: the v1 71-vector digest
sha256:e769822bc6c9e31085da7b1a17b163b9747fe0d04314fbb8685d4e612087c7cbcarries one reported independent implementation by a second author on a different stack (JM-Lab/rge-bench-java, written from the contract text importing nothing from the kit, recomputing everyexpectedfrominputs) against author-supplied vectors, while the current v2-candidate digestsha256:ba0e3795d75c788fa48313ab462493f22d78759851d1b3275d8117051bb22fd0(95 vectors) has not been reproduced by anyone but the author. See its REPRODUCTIONS.md.
Open profile: privileged-mcp-action/v0
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.
Contributing
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warningsSee CONTRIBUTING.md and GitHub Discussions.
License
Maintenance
Related MCP Servers
- AlicenseAqualityAmaintenanceMCP-native agent evaluation and observability server. Log traces, evaluate output quality with 12 built-in rules (PII detection, prompt injection, cost thresholds), and track agent costs. Real-time dashboard, OTel-compatible spans. Self-hosted, MIT licensed.92527MIT
- FlicenseNot gradedqualityCmaintenanceMCP server that enforces governance on agentic decisions with auditable evidence records, providing tools for understanding, calibrating confidence, and navigating handoffs based on policy.1
- AlicenseBqualityAmaintenanceA governance proxy for AI tools — every MCP/agent tool call is policy-gated, secret-redacted, and written to a hash-chained, offline-verifiable audit trail.13MIT
- AlicenseAqualityCmaintenanceAn MCP server that gives AI assistants the ability to inspect, normalize, diff, and validate agent tool-call traces.347MIT
Related MCP Connectors
AI/LLM agent output audit MCP: policy eval, tamper-evident chain, AI safety, x402 USDC on Base.
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...
See, price, and control every tool call your AI agents make: policy checks, cost, and audit tools.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rul1an/assay'
If you have feedback or need assistance with the MCP directory API, please join our Discord server