Skip to main content
Back to docsEvidence and coverage
Written to be contradicted

What is proven, and what is not.

A security claim that cannot be refuted is not a claim, it is an advertisement. This page states the evidence level of each profile in the same words the internal plan uses, so an outside reader can check it against what we published.

The four levels

Every work package closes by declaring one of these, next to PASS, FAIL or SKIP and the denominators. There is no fifth level and no comfortable middle.

design

Specified and reviewed. Nothing has been executed. Describing how something would work never earns a PASS.

simulated

Executed against fixtures, with the provider and the approvals identified as fixtures. It is not an integration and is never described as one.

real integration

Executed against a real provider, in an authorized account, for the exact profile tested — and only for that profile.

not evaluated

No probe ran. This is the default, not an omission, and it never counts as a pass.

Proven today

The rules above exist to keep this list honest, not to avoid having one. Each item is a property of the code, checkable without asking us.

An authorization is consumed once

A single use is a type-level literal in the grant schema, and any other value is rejected on validation. It is not a counter someone remembered to decrement.

Receipts verify without the network

There are zero network calls anywhere in the verification path. A receipt checked in five years does not depend on us being reachable, or on a mutable registry.

An adapter cannot redefine what was granted

The provider client receives the effect and an idempotency key. It never receives the grant or the authority, so it has nothing to widen.

A mutation is never retried blind

Reconciliation is the only second call to a provider. If reconciliation itself fails, the outcome is recorded as indeterminate rather than assumed.

The cloud cannot widen the local ceiling

The local policy check is deny-only and fixes tenant, gateway, provider, adapter digest, authority, accepted policy versions, resource rules and monetary limits. It requires a signed local policy to be installed, which production mode refuses to start without.

Two of these depend on how you deploy: the local ceiling needs a signed policy installed — in sandbox without one there is no ceiling — and credential isolation depends on the connector and the deployment mode you choose.

The rules that make it refutable

  • SKIP and not-evaluated never count as a pass.
  • A route without a probe stays not evaluated. It does not inherit coverage from another route.
  • The coverage manifest is a claim the test harness must be able to refute: if a bypass achieves an effect, declared coverage becomes contradicted and the gate fails, even where the file says protected.
  • Applicability is fixed before the runtime exists. Nothing can be marked not-applicable after it fails.
  • Testing a connector with MFA or quorum does not credit a delegated multi-step profile. Each claim names the chain and the versions it tested.
  • Approval fixtures are not real MFA or quorum, and a simulated approval is never presented as a human one.

What a receipt establishes

An Action Receipt proves what passed through an enrolled Guardian and the outcome that Guardian was able to establish. A timeout is reconciled by reading the provider back, never retried blind, and an ambiguous result stays indeterminate rather than being rounded up to success.

Named threats

The ones we mitigate, with the gaps still open.

Tool poisoning

A host alters tool descriptions so the model calls them with manipulated arguments. The tool catalog is server-authoritative — the server serves a fixed list and accepts no tool definitions from the client — and an allowlist limits what a given client may invoke. Open gap: the served manifest is not yet signed, so its integrity rests on the transport.

Hostile host or client

The process orchestrating the agent is itself hostile. Scopes and the tool allowlist bound the damage, every call is audited and keys revoke immediately. Open gap: an API key is a bearer credential, so a hostile host holding one acts as the tenant until it is revoked. Short-lived delegated tokens exist to narrow this.

Prompt injection through analyzed content

A message tries to inject instructions through the content being analyzed. The guard classifies and analyzes; it does not execute what it reads, and the response carries extracted facts rather than instructions. An out-of-contract effect is refused whether or not any detector saw the injection.

Catalog change after review

What you approved is not what launches later. A pinned snapshot is compared against the current catalog and a material change asks for review instead of applying itself.

Impersonation in a directory

A third party publishes a fake listing. The canonical endpoint and manifest are served by the service itself. Open gap: no published manifest signature or domain verification yet.

Outside the guarantee

Named, not implied.

  • The host administrator. Whoever controls the machine controls what runs on it.
  • A compromised Guardian or signing key.
  • Actions taken outside the enrolled execution path. The receipt is silent about them by construction.
  • A side channel nobody observed.
  • Harm the approved mandate already permitted. Authorization is not proof of truth, benignity or correctness.
  • Legal ownership of the provider account, which no receipt establishes.

No universal observation

There is no view of a host's whole context, mail, memory or the traffic of other MCP servers. What is known is the bridge's own catalog, the calls that pass through it and snapshots explicitly imported. A configuration hash describes a profile; it is not a cryptographic attestation of the host. A container on its own, without demonstrating its network and its mounts, does not prove isolation.

On signatures

A manifest signature attests integrity and provenance. It does not attest benignity, and no badge — ours included — makes an MCP server safe.

How a claim on this page changes

Not by editing it. A new capability claim is verified against the code and dated before it appears, and the verification table lives in the repository next to the copy. A page that failed a check keeps the failure visible rather than being quietly rewritten — a later run creates a new version instead of replacing the old result. There is no funded bug bounty and no independent third-party audit, and neither will be announced before it exists.

Status of this page

The evidence levels and rules above are in force today. The per-profile table will publish the observed results of each work package as they close, with denominators, versions and configuration. Until a profile has a real-provider result of its own, it is listed as simulated or not evaluated — never extrapolated from a mock or from a different connector.

Evidence and coverage — what is proven, and what is not | SecureStamp Foundation