Safe defaults you can copy, run and check.
Point it at a config file and it tells you what is in there: a secret written inline, a server launched through a shell, an unpinned package. Then it proposes a corrected version on a copy, and checks that the correction holds.
Design · Not yet released
What already works
The kit is not released yet, but none of this waits for it. Everything below runs today, and every item is something you can check rather than take our word for.
- The MCP service is remote and always on, with a catalog the server controls and a manifest you can fetch and read before connecting anything.
- Receipts verify offline with a single command and no account: the verifier makes zero network calls and takes explicit trust anchors.
- An authorization is consumed once. A single use is a type-level rule in the schema, not a runtime convention.
- Six provider operations are implemented, each with an authority the protocol fixes and the caller cannot lower. None is called stable until we publish evidence of a hundred real executions against a live provider.
- Provider credentials are read by a daemon you run. The process closest to the model declares no provider SDK at all.
What it needs from you
Nothing. After installing, the demo and the local verification run without an account and without sending data anywhere. The kit reads the files you name and writes a redacted report you can read before sharing it. Production execution keeps its own cloud authority requirements — the local kit does not promise autonomous production use offline.
What is in it
Copyable tutorial
Synthetic drafts, a reviewable plan, minimum permissions and bypass tests. It is labelled a tutorial: on its own it does not make the kit useful, it makes it learnable.
Local utility on your own project
It inspects a config or artifact you provide, explains the findings and proposes a minimal diff or template — without overwriting anything and without copying secrets — then checks the correction on a copy.
Static diagnosis
First family: stdio MCP config in JSON, with command, args and env, plus a catalog exported from the bridge. Files you choose. Other formats are reported as explicitly unsupported rather than silently skipped.
Pin and diff
An accepted snapshot of that catalog against the current or imported one. A material change asks for review instead of applying itself.
Local reader
Explains what a message is asking for, and shows whether the reading was complete, partial or abstained. It never invents causality and never says “safe because there is no alert”.
Prepublication check
A runnable recipe against the files you list: canaries, redaction and reproducible output.
Evidence and help
The offline verifier, an intact example and a tampered one, what is covered and what is not, the estimated consumption, the reason for a rejection and the path to revise the plan.
What the static diagnosis looks for
Eight findings, each with a severity, the path inside your file and a proposed remediation. The input file is hashed so a report can be matched back to exactly what was read.
INLINE_SECRETA token, key or password written directly into the config. The report redacts the value — it never copies it — and proposes an environment-variable placeholder instead.
SHELL_EXECUTIONA server launched through sh, bash, pwsh or cmd with -c. The command line becomes the thing that decides what runs, not the config.
UNPINNED_PACKAGEA package runner invoked without a pinned version, so what launches tomorrow need not be what you reviewed today.
NON_STDIO_TRANSPORTA transport outside the family this diagnosis covers. Reported rather than guessed at.
SUSPICIOUS_ARGUMENTAn argument shaped like a credential or an escape from the declared command.
MISSING_COMMANDA server entry with nothing to launch.
INVALID_CONFIGThe file did not parse as the declared format.
UNSUPPORTED_FORMATNot a format this diagnosis covers. It says so instead of returning an empty, reassuring report.
When it finds nothing
A clean result is shown with the same weight as a finding, and it says what was actually checked so the absence means something. The kit is not a scare tool: it also tells you when SecureStamp is not what you need, and points at the alternative.
What it does not do
The boundaries are part of the tool, not a disclaimer.
It does not crawl your disk
It reads the files you name. There is no search, no walk of your home directory and no background scan.
It does not open a shell
It never executes what it is inspecting, and it does not run the servers it finds described.
It does not look at your connections
No network inspection, no traffic capture, no probing of the hosts in your config.
It does not validate tokens
It can see that a value looks like a secret. It never tries it against anything to find out.
It does not discover your MCP servers for you
It knows the catalog you pinned and the files you gave it. There is no universal view of a host's context, mail, memory or other MCP traffic.
Where we stand
Widen who gets to build and delegate — with limits anyone can check.
The point of bounding an effect is not to decide who deserves to automate. It is to let more people delegate real work without the people around them absorbing the risk: the customer whose refund it is, the employee whose access changes, the third party who never agreed to anything. Bounds that only the vendor can inspect protect the vendor. These are meant to be checked by whoever is affected.
- We do not police opinions, and we do not decide which content is true. The tool reads what a message is asking for, never whether its author is right.
- No professional credential is required to use it. A maintainer with one repository and a bank with a compliance department get the same schemas and the same verifier.
- Constraining software is not the same as constraining people. What is bounded here is what an automated actor may cause, not what anyone may say.
What we commit to
Checkable before you trust us, not after.
The proof is open, on every plan
Schemas, the cryptographic profile, the verifier, the test vectors and basic conformance are public. The same artifact verifies identically whether it came from a free account or an enterprise one. What is charged for is operation, scale and support — never trust itself.
Your data stays where you put it
Product telemetry is opt-in and separate from the audit trail a control actually needs. There is no central repository of message bodies, conversations or individual behaviour, and building one is not on the roadmap.
Changes go through a process you can join
A public proposal with its alternatives and impact, a comment period announced before it opens, a written answer to objections, a named owner with stated conflicts of interest, and versions with a migration deadline. Not a changelog after the fact.
Reporting a problem costs you nothing
Security findings go through SECURITY.md. Nobody has to publish an exploit or hand over sensitive data to be taken seriously. An incident gets facts, mitigation, the limits of what we know, and the fixes.
Disagreement stays in the record
RFCs are open to integrators, small teams, individual users and companies alike. Dissent is preserved rather than resolved away, and we do not manufacture the appearance of community support with generated opinions.
Protocol and product are separated on purpose
Decisions about the open protocol and the roadmap of the paid service are tracked apart, with a named owner for each, so nobody has to guess which one a change is serving.
What we are not
Said now, so it cannot be implied later.
- Two domains are not an institution. securestamp.org and securestamp.online are operated by one company; on their own they do not constitute a foundation or an independent council. That structure would be a later decision, taken in the open — not a claim to make in marketing.
- There is no funded bug bounty and no independent third-party audit. Neither will be announced before it exists.
- There is no universal badge, no certification that can be bought, and no automatic regulatory compliance. A signed manifest attests integrity and provenance. It says nothing about whether the thing it signs is benign.
On signatures
A signed manifest attests integrity and provenance. It does not attest benignity, and the kit never presents a valid signature as evidence that something is safe to run.
Status
Design. The diagnosis module and its findings exist and are covered by tests; the packaged CLI, its subcommand names and the published guide are not released yet. Nothing on this page describes a result obtained against a real provider.
What stays open
Schemas, the cryptographic profile, the verifier, the test vectors and basic conformance are open, and the same artifact verifies identically on every plan. What is charged for is operation, scale and support — never trust itself.