01 / CONTROL
Authorize the call
Filter discovery, validate arguments and require approval where the policy calls for it.
Allowing or dispatching a call does not prove external execution.
OPEN SOURCE · SELF-HOSTED · MCP
Your agents act.
You set the rules.
Control what they can execute. Inspect the evidence each action leaves behind.
Policies, validation and approvals in front of your MCP servers. Signed receipts and external checks to understand what happened, with explicit trust boundaries.
python -m pip install mcp-zero-trust-layer==0.6.0Python 3.11–3.14 · Apache-2.0 · No mandatory SaaS service
01 / EXPLORE THE EVIDENCE
A timeout is not the end of the story.
A call loses its response. The gateway keeps the outcome unknown and queries the receipt without repeating the action. An observer then checks the claim against a configured source.
LOCAL SIMULATION · NO PAYMENTS OR CALLS TO STRIPE
Dispatch was attempted, but no response was observed. The effect remains unknown.
A read-only query recovers the destination’s signed committed claim. It does not establish that the external effect happened.
The receipt claims committed; the observer reports failed from the simulated source. The receipt signature can still be valid.
The observer reports succeeded with matching fields. The conclusion still depends on the source and the observer.
A later observation reports a failure. The earlier observation remains in the history.
The observed amount differs from the authorized request. The operation is not corroborated.
The simulated source reports a pending status. It is not turned into success or failure.
The query finds no record. This does not prove that the action never happened.
- Gateway
- unknown
- Destination
- —
- Observer
- —
Destination method trace
tools/call1 business call. 1 receipt query.
SIGNED EVIDENCE / v1 + v2
Every signature has a relationship to check.
Explore the documents in the selected case. Identifiers and commitments bind the authorized request to its attempt, receipt and subsequent observation.
- 01 → 02Binds the authorization
- 02 → 03Binds the complete permit
- 03 → 04Binds the v1 evidence
Fixture fieldsgateway-demo
Authorizes this exact request; it does not by itself establish dispatch.
Binds the attempt to the signed authorization through authorization_digest.
Binds the destination claim to the complete permit, request and original identifiers.
Binds the report to the complete v1 evidence and to the preceding report, if any.
There is no document of this type at this point. Preserve that absence: it is neither failure nor confirmation of an effect.
Map of bindings declared in the fixtures. Cryptographic verification uses the CLI and your trusted public keys, not this page.
Contract and step-by-step recovery ↗The interactive view needs JavaScript. You can open the public fixtures and reproduce the demo with the CLI.
Synthetic data from the 0.6.0 fixtures. Shared administration; independence is not proven. The browser displays records and does not verify signatures. Offline verification authenticates the observer, not a Stripe signature or the current external state.
Reproduce in a new directory
mcpzt evidence check-demo --directory ./mcpzt-check-demoUse a new path for each run. The demo generates local keys: do not publish the entire directory.
02 / SCOPED GUARANTEES
Know what you know. And what you don’t.
02 / RECEIPT
Authenticate the claim
Bind the signed receipt to the same authorization, request and attempt. Requires a receipt-aware destination.
A destination can sign an incorrect statement.
03 / OBSERVATION
Check a source
An observer queries a configured source and appends its report to the evidence history.
The report depends on the observer and source; it does not prove independence or unique execution.
Before dispatch: policy decides.
Results from the repository’s GitHub configuration, run against a simulated server. A denial or pending approval does not dispatch the call.
Allowed
github.search_issues
Calls to simulated destination: 1
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "Synthetic issue search result"
}
]
}
}Denied
github.delete_repository
Calls to simulated destination: 0
{
"jsonrpc": "2.0",
"id": 2,
"error": {
"code": -32001,
"message": "Request denied by policy",
"data": {
"decision": "deny",
"policy_id": null,
"reason": "default decision: deny",
"validation_errors": []
}
}
}Approval required
github.merge_pull_request
Calls to simulated destination: 0
{
"jsonrpc": "2.0",
"id": 3,
"error": {
"code": -32010,
"message": "Approval required",
"data": {
"decision": "require_approval",
"policy_id": "critical-actions-need-approval",
"reason": "matched policy critical-actions-need-approval",
"approval_id": "appr_5d1d28d871464cbe99ce7901fe74a99d",
"expires_at": "2026-09-17T19:22:12.134061+00:00"
}
}
}03 / START WITH A REALISTIC CASE
Your tools. Your boundaries.
Starter configurations to adapt to your environment. Evidence is off in these six basic examples; receipts and external checks have separate demos.
01 / MCP
Filesystem
Scoped reads and writes requiring approval.
Node.js · local filesystem root
View configuration02 / MCP
GitHub
Allowed queries and policy-controlled changes.
MCP server · GitHub credentials
View configuration03 / MCP
PostgreSQL
Validate SQL queries before dispatch.
MCP server · test database
View configuration04 / MCP
OIDC + CRM
Group-based permissions and output field redaction.
OIDC provider · CRM server
View configuration05 / MCP
Protected HTTP
Separate client identity from the upstream credential.
HTTP upstream · server credential
View configuration06 / MCP
Multi-MCP
Capability policies across multiple servers.
Example services · local configuration
View configurationExample catalog and requirements
The first connector covers stripe.refund.status.v1. The demo simulates the provider; a live test needs credentials and a prepared sandbox refund.
04 / BETWEEN AGENT AND SERVER
An explicit control boundary.
- 01Identity
- 02Policy and validation
- 03Approval, if required
- 04Audited intent
- 05Dispatch to destination
- 06Response and evidence
Conceptual overview. Receipts require trust configuration; reconciliation and external checks are subsequent read-only steps.
Policies and data
Capability-based control, argument validators and output redaction. Protection depends on policies and each validator’s scope; review the examples before using real data.
Approvals and audit
Request-bound approvals and intent/outcome records. The required evidence profile needs enforce mode, strict auditing and configured trust keys.
Transports and clients
HTTP JSON POST without SSE passthrough. Bounded, serial POSIX stdio; server-initiated messages are not supported. HTTP sessions are process-local and need affinity. Generating client configuration does not certify a provider.
Evidence limits
Signatures do not prove physical truth, causality, bank settlement, global completeness or exactly-once execution. Observations have scope and time; a historical report does not establish current state.
05 / TRY IT LOCALLY
From policy to evidence.
Install this page’s version and choose a demo. The local simulations do not need provider credentials.
01Install MCPZT
python -m pip install mcp-zero-trust-layer==0.6.0Python 3.11–3.14
02Try an HTTP gateway
mcpzt demo --output ./mcpzt-http-demo
cd mcpzt-http-demo
bash run-demo.shGenerate the files and run the script from its directory. The demo checks its results.
03Inspect a receipt after a timeout
mcpzt evidence demo --directory ./mcpzt-receipt-demoUse a new path for each run. The demo generates local keys: do not publish the entire directory.
04Check a simulated source
mcpzt evidence check-demo --directory ./mcpzt-check-demoUse a new path for each run. The demo generates local keys: do not publish the entire directory.
Docker / GHCR
docker run --rm ghcr.io/686f6c61/mcp-zero-trust-layer:0.6.0 --help