Security model

Settlens is a security tool, so its own behavior has to be easy to check. It is read-only by design: it holds no funds, no wallet and no payment key, it never signs or settles a payment, and it is not a blockchain and has no token. This page lists the guarantees, the threats they answer, what remains, and how to report a problem. For how assessments are performed, see the methodology.

Guarantees

• No custody, no payment keys. No command needs a wallet or a payment key. Every report records settlementCalls: 0 and privateKeysUsed: 0. The only key Settlens handles is your own optional evidence signing key, generated and used locally.
• No payments. Passive scans never send PAYMENT-SIGNATURE. The authorized active probe sends one signature that cannot be valid. Nothing calls a facilitator's /settle.
• Explicit consent for active traffic. The probe needs --active, --authorized and an --authorization-ref, and is not available through the GitHub Action, Monitor, the HTTP API or the MCP server.
• Secrets stay where you put them. Custom headers reach only allowlisted hosts and are never written to reports.
• Evidence is checkable. Reports carry a SHA-256 digest; attestations carry an ed25519 signature; both verify offline.

Security objectives

Settlens must:

1. assess an explicitly selected HTTP(S) target without moving funds;
2. never accept or transmit a caller-provided PAYMENT-SIGNATURE;
3. prevent a modified assessment config from exfiltrating CI secrets;
4. avoid persisting credentials or response bodies in evidence;
5. distinguish passive observation from authorized active probing;
6. make post-generation report modification detectable;
7. fail CI deterministically when findings meet the selected severity.

Trust boundaries

The resource server, the facilitator, DNS, TLS termination, the CI runner and the artifact store are independent trust domains. Settlens does not assume that a resource server and the facilitator it names are run by the same party.

Threats and controls

Residual risks

• A report digest detects changes but does not identify the author. An attestation identifies a key, not a person: its value depends on comparing the public key with one the signer published. attestedAt comes from the signer's clock.
• The hosted scan API and remote MCP tools check DNS before connecting, and the HTTP client resolves again when it connects. That window is accepted because these interfaces are authenticated, passive and follow no redirects.
• A compromised CI runner can read the secrets already granted to that job.
• DNS and TLS trust are delegated to the platform running Settlens.
• Passive samples cannot exercise every server-side code path.
• The active probe tests one invalid payload class, not every way a signature can be wrong.
• Rate limiting and multi-tenant isolation are properties of the assessed service that a few samples cannot establish.

Supply chain

• 5 direct runtime dependencies, at exact versions: @noble/curves 2.2.0, @noble/hashes 2.2.0, @x402/core 2.28.0, nodemailer 10.1.1, proper-lockfile 4.1.2. Their own dependencies are locked in package-lock.json; everything else uses the Node.js standard library.
• Installs use the lockfile with install scripts disabled (npm ci --ignore-scripts).
• The GitHub Action and the repository's CI pin third-party actions to full commit SHAs.
• The container image starts from a digest-pinned node:24-alpine, installs production dependencies only, removes npm and npx, and runs as the node user.
• The code is in a private repository; pilot participants receive access. Settlens is not distributed through npm.

Safe testing rules

• Assess only endpoints you own or are allowed in writing to test.
• Use testnet assets and synthetic data.
• Record the approval for any active run in --authorization-ref.
• Never use Settlens for denial of service, credential testing, settlement, transaction replay or fund movement.

Report a vulnerability

Email contact@settlens.com. Please do not open a public issue or post details that contain an exploit, credential, customer URL or payment payload. Include:

• the affected version or commit (settlens --version);
• the smallest example that reproduces the problem;
• impact and preconditions;
• whether real funds, keys or customer systems were involved;
• how to reach you for coordinated follow-up.

Operating targets, not contractual commitments: acknowledgement within two business days, an initial severity assessment within five business days, a mitigation target of seven calendar days for critical issues, and a disclosure date agreed with the reporter. Security fixes are made on the latest release line. The site also publishes this contact in security.txt, and the security page summarizes our practices.

Questions