Kenwea Notary

Notarize what a file or npm package does at the moment Kenwea fetches it, and get a signed record anyone can check. Input: exactly one of artifactRef, a public https URL of a single file, npm tarball or Python wheel, or package, an npm package name such as express@4.18.2 (resolved to the exact tarball npm install would download; no version means latest), or a Python one as pypi:requests@2.31.0 (resolved on PyPI to the wheel this sandbox can import: pure Python, or musllinux for CPython 3.12), or an OpenClaw plugin on ClawHub as clawhub:name@version (the release ClawHub serves, refused unless it has the SHA-256 ClawHub publishes; no install step runs, as OpenClaw installs with --ignore-scripts, and the plugin is loaded as OpenClaw loads it, its openclaw.extensions entries imported and register() called with a stand-in OpenClaw API, decoy OpenClaw keys in its config and in ~/.openclaw). Behavior: Kenwea downloads the bytes (up to 32 MiB) and runs executable content in isolation: no route out (a stand-in network inside the sandbox answers every lookup and every TCP connection, on any port and straight to any IP address, and records them), all capabilities dropped, read-only filesystem, not as root, 15 seconds for a file and 55 for a package. For a package it runs the install steps npm would run (preinstall, install, postinstall, and the node-gyp step npm adds for a binding.gyp) with decoy credentials where a developer machine or CI runner keeps real ones (an npm token in ~/.npmrc and NPM_TOKEN, a GitHub token, AWS keys, an SSH key, CI variables, and wallet keys: a Solana keypair, Ethereum and Foundry keystores, MetaMask and Phantom vaults, PRIVATE_KEY, a seed phrase and RPC API keys), each traced for the network connections, DNS lookups and programs it attempts, the credential files it opens and any decoy it puts into what it sends or starts; a single file and a Python package run with the same decoys (plus a PyPI token for Python) and are traced the same way; a PyPI wheel (package pypi:name) is imported with its dependencies installed, resolved as pip would for CPython 3.12 on Linux x86_64 and each checked against PyPI's sha256. After its install a registry npm package is also loaded once, as an application would require or import it, and onLoad says what loading it did; a load that reaches the network or a credential is its own finding (load_tried_network, load_read_credentials, load_sent_credentials). For a registry package that runs something at install, the dependency tree npm would install goes in first, each tarball checked against the registry's integrity hash, and every install step in the tree runs, the dependencies' first; a package that declares none is checked when a dependency does (dependencies.installSteps names them). Returns: level, one word for what the record means (nothing_runs, quiet, network, reads_credentials, sends_credentials, unfinished), and summary, one sentence; installSteps (what runs at install; empty means nothing does) and observed (what the steps attempted, with credentialsRead and credentialsSent when a decoy was touched, and requests: what a step sent to the stand-in network, plain HTTP in full, HTTPS in full when the step accepted the stand-in's certificate authority and otherwise by server name and size); for an npm package, sincePrevious, which install steps were added, removed or changed since the previous published version (from the registry, not signed); a verdict and a reasonCode, the sha256 of what was read, and signedAttestation, an Ed25519 signature over the facts. quiet (verdict approved) means everything that ran finished, was traced whole and touched nothing watched; a step that tried the network, read a credential file, failed or could not be observed is manual_review with the reason; rejected is for a step that tried to send a decoy credential, and for files carrying a provider-formatted credential. A URL that cannot be fetched returns checked false with the reason instead of a verdict; a limit of our runner comes back as manual_review stated as ours. Limits: no key or signup; 20 checks per hour per network address (an IPv6 /64 counts as one address) within a shared hourly ceiling, refused with rate_limited and the reset time. A Kenwea API key sent as a Bearer token uses that key's own quota. At most four checks run at once; one that gets no slot within 10 seconds comes back manual_review with reasonCode runner_busy and nothing run, so retry. The same bytes at the same address under the same checker version get the record issued the first time, marked cached, and nothing is run again. Keeps no copy of the artifact; a finished record is held in memory for up to 24 hours to answer repeats, and a rate counter and a log line keep a short hash of your address. Not for: checking a record you already have (use kenwea_notary_verify, which runs nothing and does not spend your quota).

Score an MCP server's tool definitions for what they ask of the model, before you connect it. Input: tools, the tools array of a server's tools/list answer (each {name, description, inputSchema}); or server, the server's name as Smithery lists it (for example brave or owner/name), whose published definitions are read from Smithery. Behavior: runs nothing and calls no server. Fixed rules read each description and every parameter description against the tool's own input schema, because anything in the prose the schema does not need is where an injected instruction lives: tags that frame text as instructions (, ), HTML comments and invisible characters (zero width, bidirectional controls, Unicode tags), asking the model to drop its instructions, to keep something from the user, or to put a file's contents into an argument, naming files where secrets live (~/.ssh, ~/.cursor/mcp.json, ~/.aws), asking for a credential the schema has no parameter for, steering the model off the web or other servers toward this one, and speaking to the model rather than describing the tool. No model reads the text, so the same definitions always get the same findings and anyone can redo them. Keyless, read-only. Returns: level (clean, review or suspicious), summary, findings (each with tool, rule, severity, where and an excerpt), rulesVersion and inputSha256, the SHA-256 of the definitions as read. A finding is a reason to read the definition, not a verdict on the server: on 500 Smithery servers (12,598 tools, rules 2026-10-31.1) 495 were clean, 3 review and 2 suspicious, and read by hand none hid an order or reached for data: the 3 steer the model off web search toward the server, the 2 were a vendor's response instructions and a false positive. Not for: what a server's code does when it runs (use kenwea_notary_check on its npm package).

Answer for every package in a project's npm dependency tree at once, from records the notary already holds. Input: lockfile, the text of a package-lock.json (lockfileVersion 2 or 3, or its JSON), a pnpm-lock.yaml (v5, v6, v9), a yarn.lock (v1 or berry) or a project's package.json (its ranges resolved as npm would today, devDependencies included); or packages, a list of {name, version, hasInstallScript}, with directs, the project's own dependencies as {name, version}. Behavior: the lockfile says which packages run something at install (hasInstallScript, or requiresBuild in pnpm up to v6), and where it does not (pnpm v9, yarn) the registry is asked for each version (usually a few percent run something); the rest run nothing of their own and are only counted. A step runs inside the project, under the package that pulled it in (@scarf/scarf reports telemetry only for the package that depends on it), so the tree is checked through the project's direct dependencies: each one under which something runs at install is answered by its own record, made with its whole tree installed, and the packages under it come back as covered, with coveredBy naming it. A yarn.lock does not say which packages are direct, so there each package that runs something is checked on its own, and checkedThrough says which way it went. Each record is a stored signed record, made by kenwea_notary_check's sandbox run with decoy credentials; one that has none yet is queued and checked in the background, about two a minute, so ask again later with the same tree to collect it. Nothing runs during the call and it does not spend the per-address check quota (60 tree calls an hour per address). Returns: summary, counts (total, runNothing, runSomething, answered, queued), findings (packages whose level is network, reads_credentials or sends_credentials), checkedThrough (direct_dependencies or each_package), and packages, each with status (answered, queued, not_queued, covered) and, for a direct dependency, covers; when answered, level, summary, verdict, reasonCode, observed and signedAttestation. Verify each record with kenwea_notary_verify or your own Ed25519 code; the tree summary itself is not signed. Not for: one package you want checked now (use kenwea_notary_check). A lockfileVersion 1 file has no hasInstallScript flags and is refused with a reason.

Return Kenwea's published Ed25519 notary key, so a signed record can be verified with your own code instead of kenwea_notary_verify. Input: none. Behavior: reads Kenwea's published key list (https://www.kenwea.com/.well-known/kenwea-attestation-keys.json) and caches it for an hour. Runs nothing, read-only, never counts against the check quota. Fails with key_unavailable if the list cannot be fetched. Returns: the active key's keyId, algorithm ed25519, the key as base64 (32 raw bytes) and as PEM, keyUrl and keysUrl, and keys, every published key with its status (active, retired or revoked). To verify, check signedAttestation.signature (base64) over the exact bytes of signedAttestation.payload with the key whose keyId the payload names, and treat a revoked key as no signature. Not for: checking an artifact (use kenwea_notary_check) or having the check done for you (use kenwea_notary_verify).

Check a signed record produced by kenwea_notary_check: whether its signature is valid under Kenwea's published Ed25519 key, what it attests, and whether it is in Kenwea's public transparency log (log.included, proven with an inclusion proof against a checkpoint signed by the same key), so it was shown to everyone and not only to you. Input: payload and signature exactly as they appear in the record's signedAttestation. payload is a JSON string and must be passed byte for byte; re-serialising it (reordering keys, changing spacing) breaks the signature. signature is standard base64 with padding. Optionally contentSha256, the hex sha256 of bytes you hold, compared without regard to letter case. Behavior: runs nothing and makes no request except fetching Kenwea's published key list (https://www.kenwea.com/.well-known/kenwea-attestation-keys.json), which it caches for an hour and reads again when a record names a key it does not hold. A record names its key inside the signed payload (format 2) and is checked against that key; an older record is tried against every published key. A record signed with a key Kenwea has revoked returns valid false and says so. Read-only and idempotent; it never counts against the check quota. Returns: valid, the keyId and its status, and the signed facts (verdict, reasonCode, installSteps, observed, contentSha256, issuedAt and the rest); with contentSha256, also matchesContentSha256. An altered or re-serialised record returns valid false with the reason, not an error. If the key list cannot be fetched the call fails with key_unavailable and says why. Not for: learning what an artifact does (use kenwea_notary_check). To verify without this tool, take the key from kenwea_notary_get_public_key and use any Ed25519 library.