DEV Community: correctover

Hot Wallet Drains in 2026: The Question Nobody Asks

correctover — Fri, 30 Oct 2026 03:51:39 +0000

Hot Wallet Drains in 2026: The Question Nobody Asks About the $3.3B Lesson

The signature is the attack surface. Everything else is commentary.

Every major wallet-drain event of the last 18 months - from the $1.5B Bybit incident to this week's $3.3B hot wallet event - has produced the same post-mortem pattern: a forensic scramble over where the money went, and a deafening silence over how the signature that authorized the movement was produced.

That's the wrong order. And it keeps being the wrong order because most incident-response tooling is built for the trace, not for the authorization layer.

The actual question

When funds leave a hot wallet in one transaction, the cryptographic facts are these:

A valid signature existed for that exact transfer
That signature came from a key that was either compromised, coerced, or delegated
The moment of signing happened before the on-chain movement - often hours before, in a completely different trust context

EIP-7702 (which activated in Prague's shadow this year) makes this sharper: delegated execution means an EOA can temporarily behave like a contract, and who authorized that delegation is a question almost no monitoring stack answers. The delegation signature is the real root event. The token sweep is just its echo.

Incident response teams today can answer "where did it go" within minutes. Almost none can answer "what produced the authorization" with verifiable evidence.

What a verifiable authorization layer looks like

After studying these failure modes across multiple cases, we've converged on a minimal set of properties that any production hot-wallet authorization path should satisfy. This isn't a product pitch - it's a checklist the next $3.3B post-mortem will wish it had:

Property	What it means in practice
Operator-signed scopes	The human or policy principal signs what the wallet may do, per session. The hot key can never authorize outside that scope, no matter what code it runs.
Append-only session grants	Every credential-entry event ("key may sign for host X in this window") is recorded so the agent/wallet runtime can read the grant but can never rewrite history. Bounded in time. Auditable.
Typed-once handles	Secrets enter exactly once, at a human terminal. The runtime references a handle - never the material.
Fail-closed, not fail-open	If verification can't complete (missing scope, stale grant, unknown principal), the default is refuse. Not "log and proceed".
Third-party-verifiable receipts	Every authorization produces a receipt an external auditor can verify offline - Ed25519 over JCS-canonicalized payloads. No trust in the vendor's database required.

The last property is the one the industry keeps skipping - and it's the one that determines whether your insurer, your regulator, or a court can independently confirm what your wallet was told to do.

Why this is a verification problem, not a monitoring problem

Monitoring watches effects (transactions, balances, anomalies). Verification constrains causes (who signed, what scope, which grant chain). By the time monitoring fires on a hot wallet sweep, the signature already happened - the only question left is forensic.

The teams that will survive the next round of incidents are the ones who moved the boundary: from "we'll detect it fast" to "the signature that authorizes this class of movement cannot exist without a verifiable human or policy grant."

Detection tells you you're bleeding. Verification is why you don't start.

Correctover works on runtime verification for AI agent and wallet tool calls - structure, schema, identity, integrity, security - with Ed25519-signed, offline-verifiable receipts. The scope/receipt/handle patterns above are from an IETF-draft-track design we're documenting in the open.

Tools and evidence: github.com/DSHCorrectover — runtime verification for AI agents & node infrastructure.

We Published the Largest Known Census of MCP Tools: 229,827 Parameter Schemas

correctover — Thu, 29 Oct 2026 09:58:59 +0000

We Published the Largest Known Census of MCP Tools: 229,827 Parameter Schemas

If you're building security or conformance tooling for AI agents, you need machine-readable descriptions of what tools exist and what parameters they take. Today we're publishing the largest known dataset of exactly that.

What's in it

229,827 tool records, each with a machine-readable input_schema — the parameter definitions an agent sees when deciding how to call a tool.
Coverage from 13,120 servers with tool-level schemas (out of 42,163 servers surveyed — the gap is itself a finding: most deployed MCP servers don't expose machine-readable parameters at all).
Byte-verified counts, zero malformed records, SHA-256 anchored — verify the bundle yourself.

Why parameter schemas matter

An agent's tool call is only as safe as the contract it can read. Parameter-level risk classification — which arguments can carry URLs, file paths, shell fragments — is the layer where injection and exfiltration actually get stopped. Our IETF individual draft draft-correctover-gg-mcp-parameter-risk proposes a canonical risk taxonomy for exactly these schemas; this census is the empirical base it stands on.

Use it

Risk research, conformance test generation, discovery-layer security analysis. Data is CC0 (dataset; see repo for the verification hash and citation).

Honest limits

English-language-weighted sampling; schema quality varies by server; the 29k servers without tool-level schema are recorded but not expanded. Methodology notes in the repo.

Correctover — runtime verification and evidence infrastructure for AI agents.

Where the Agent Can't Write: Signing Trust Boundaries for AI Agents

correctover — Thu, 29 Oct 2026 05:18:56 +0000

Where the Agent Can't Write: Signing Trust Boundaries for AI Agents

An agent that can edit its own permission policy has no permission policy. This is a design analysis of three patterns that survive that constraint — expanded from a discussion on agent credential handling, for teams building agent systems that handle real secrets.

The problem

Agent frameworks increasingly ship safety boundaries: "don't send credentials to arbitrary hosts," "don't pipe secrets into shell commands." These boundaries are only as strong as the configuration that expresses them. And the uncomfortable fact is: most agent configurations are agent-writable. Settings files, environment variables, project configs — the same surfaces the developer edits are, in most deployments, surfaces the agent can also reach through its own file and shell tools.

A prompt-injected webpage, a malicious dependency, a poisoned README — any of them can append to a credential allowlist as easily as the developer can. The boundary didn't fail loudly; it was never a boundary. It was an instruction the attacker could also give.

The test for any trust declaration is simple: can the agent author it, or only consume it?

Threat model

We assume a capable agent with file and shell tools, running prompts and content from untrusted sources. The attacker controls some prompt surface (webpage text, issue comments, dependency behavior) and wants the agent to exfiltrate a credential or perform a privileged action. The defender wants legitimate workflows (testing against staging, entering dev credentials) to keep working.

Everything below is evaluated against one question: does this pattern give the attacker's instructions the same power as the operator's?

Pattern 1 — Operator-signed scopes

The environment declaration ("credentials may be entered for staging.internal, *.corp.example") is signed by an operator key that the agent never sees. The agent (and its tools) may read the signed scope and enforce it; they cannot author or modify it.

Mechanics that matter:

Key location is the security property. The signing key lives in a hardware-backed store, a CI secret, or an operator's password manager — anywhere outside the agent's filesystem and shell reach. If the key is a file the agent can read, the pattern degrades to agent-writable config.
Signature covers the entire scope, not entries: adding one host invalidates the whole signature, so incremental tampering is detectable rather than silent.
Revocation is a new signature, which means emergency revocation has a cost — plan for short scope lifetimes (days, not months) so revocation-by-expiry is the common case.

This is the strongest pattern and the least flexible. Use it for stable infrastructure: known hosts, known clusters.

Pattern 2 — Session grants as append-only receipts

Instead of declaring environments safe forever, the operator grants per-session: "for this session, host X may receive credentials." Each grant is recorded as a receipt: a structured, timestamped, hash-chained entry the agent can read but not rewrite.

Why append-only matters: if the agent could edit the grant log, it could mint grants. If the log only appends (hash-chained, or held by a separate process), the agent's powers are exactly the operator's historical decisions — no more. Auditing becomes trivial: the log is the security story of the session.

Design notes:

Grant tuples: {principal, capability, scope, expiry, nonce} — principal is the operator identity, capability is narrow ("enter-credential", not "do-anything"), expiry is short (minutes to hours), nonce prevents replay across sessions.
Hash chaining: each receipt commits to its predecessor, so truncation and reordering are detectable. The chain head can be signed periodically for external anchoring.
The receipt is a decision artifact — the same shape as runtime-verification receipts in serving infrastructure. A grant and a verdict are cousins: both are signed statements about what was authorized, made by a principal the runtime cannot impersonate.

This pattern fits interactive work best: the developer approves a staging host once per morning, the grant is visible and bounded, and the injected page can't extend it.

Pattern 3 — Typed-once secret handles

The operator types the secret directly, once, at the start of the session. Thereafter the agent only ever sees a handle — an environment variable name, a secret-store reference — never the material.

The agent's context contains DB_PASSWORD_REF=vault://ci/db-password, not DB_PASSWORD=hunter2. When a tool needs the credential, the tool's backend resolves the handle outside the agent's context window. The agent can reference, leak the reference, but cannot leak the secret.

Design notes:

Resolution must happen out-of-band. If the agent's shell expands the handle, the material transits the agent's context and the pattern collapses. Resolution belongs in the tool's server side.
Handles bind to grants: a handle without a matching grant is inert. This composes Patterns 2 and 3 into a lattice — handles name what, grants authorize when and where.

Composition: a signed policy lattice

The three patterns compose. Signed scopes define the stable world (Pattern 1). Session grants authorize deviations (Pattern 2). Secret handles keep material out of the untrusted context (Pattern 3). Enforcement happens at the jump — every privileged action is checked against the lattice before execution, fail-closed.

The lattice has a useful property: every authorization is a signed, inspectable artifact, and every denial is a signed, inspectable artifact too. Debugging "why did the agent refuse my password" stops being archaeology and becomes reading the receipts.

Failure modes (honest)

Compromised operator key breaks Pattern 1 entirely — key custody is the pattern. Mitigate with short lifetimes and an out-of-band revocation channel.
TOCTOU on grants: a grant checked at request time against a mutable store can be swapped between check and use. Receipts must be checked against the appended log, not a cached copy.
Handle dereference bugs: a tool that logs its resolved material reintroduces the leak. Handle resolution paths need the same audit as the boundary itself.
Usability pressure is the real long-term threat: every "just let me disable this for a minute" request is a request to move a declaration from the operator's write sphere into the agent's. Resist structurally (short grants) rather than culturally (policy documents).

Closing

The claude-code thread asked for a permission-gated opt-in for dev environments. The feature is right; its safety depends entirely on who signs the scope. Sign it in the agent's reach, and you've built a prompt-injection amplifier. Sign it outside, scope it in time, and record it in receipts — and the same flexibility ships without the exfiltration channel.

Guigui Wang — Correctover. We design and assess trust boundaries for AI infrastructure: signed receipts, scoped grants, evidence-grade deliverables.

Tools and evidence: github.com/DSHCorrectover — runtime verification for AI agents & node infrastructure.

Auditing a Published CVE: A Six-Step Reproducibility Walkthrough

correctover — Thu, 29 Oct 2026 04:09:56 +0000

: A Six-Step Reproducibility Walkthrough

In July 2026, an advisory for a widely deployed SM2 library described private-key recovery by "observing a few Math.random() outputs." We audited that claim. The premise was wrong, the real root cause was narrower and stranger, and the maintainer confirmed our correction in writing. This is the method, on public record, step by step.

The claim under test

The advisory described seeding from Math.random() with a pool filled at module load — implying an attacker who samples a few outputs could reconstruct keys. Recoverable-from-outputs is a strong, testable claim.

Step 1 — Pin the artifact, not the story

We froze the exact published npm tarballs (sm-crypto@0.4.0, jsbn@1.1.0, hash-recorded) and instrumented a victim process that pinned Math.random and the wall clock before the libraries loaded. No version drift, no "works on my machine."

Step 2 — Pre-register the counters

Before running anything, we wrote down what we expected to observe and what would falsify the claim: Math.random call count at seeding time, OS RNG calls, generated keys across processes, and signatures under fixed pins. Counters first, experiment second — so the experiment could not be quietly re-interpreted after the fact.

Step 3 — Run the adversary model honestly

The advisory's attack needed observable RNG outputs. Our instrumentation showed the pool fill never called Math.random in Node at all — the count was zero. The premise was not merely unverified; it was impossible as described. What remained was a clock-only seed with dead pool-fill code, which we demonstrated: identical keys across processes pinned to the same wall clock, valid signatures from those keys, both reproduced independently.

Step 4 — State the boundary before anyone asks

Our claim, worded to survive hostile reading: keys generated at or near process startup in runtimes without getRandomValues are recoverable within a millisecond-scale time window by a third party who can bound generation time. Not "any key, any time." The narrower claim is the one that stayed true.

Step 5 — Compare against the known art

The registered attack class (weak-RNG key recovery from observed outputs) was well documented. Our variant required no output observation at all — strictly weaker preconditions than anything in the record. When your result is stronger than the reference class, that comparison is part of the finding, not a footnote.

Step 6 — Ship the bundle, not the adjectives

Everything above ships as a canonicalized, SHA-256 anchored, Ed25519-signed evidence package with re-run instructions — anyone can re-derive every digest and re-verify the signature without trusting us. The maintainer independently confirmed the corrected root cause and adopted the expanded impact statement.

What this is a demonstration of

Not a product pitch — a discipline: frozen artifacts, pre-registered counters, honest boundaries, and a signed bundle instead of adjectives. When your deliverable is trust, the method is the product.

wangguigui@correctover.com · https://correctover.com

Tools and evidence: github.com/DSHCorrectover — runtime verification for AI agents & node infrastructure.

After the Coldcard Entropy Disaster: How to Fingerprint a Wallet's Key Path in Three Steps

correctover — Thu, 29 Oct 2026 03:38:01 +0000

: How to Fingerprint a Wallet's Key Path in Three Steps

On July 30, 2026, Coinkite disclosed that Coldcard firmware shipped since March 2021 derived seeds from a software fallback RNG instead of the hardware entropy source — effective randomness estimated at 40 to 72 bits instead of the intended 128. Attackers swept funded addresses the same day; Galaxy Research puts confirmed losses near 1,596 BTC (~$100M) from ~7,300 addresses, with a suspected fourth wave under review. All of this is public record — Coinkite's advisory and technical backgrounder, plus independent analyses by Block and Wizardsardine. What follows is a method any team can run, plus our own reproducible evidence.

The uncomfortable precision

What is genuinely out of reach for a remote black-box attacker: key generation that calls the platform CSPRNG directly in native code — iOS SecRandomCopyBytes/getentropy, Android SecureRandom backed by /dev/urandom. Kernel CSPRNG state is not recoverable from outputs; there is no finite state to reconstruct. Only kernel exploits or local side-channels touch this — a different track. If a wallet does this, say so: the "immune by design" stamp is worth real money to insurance and compliance teams.

Where doors remain, even in modern wallets:

JS key paths inside native shells (RN/Flutter/WebView bridges). A broken polyfill chain silently falls back to Math.random. Precedent: a single 2014 iOS commit swapped a secure RNG for an insecure one across 200+ downstream wallets.
Signing nonces. Key generation can be perfect; a repeated or biased ECDSA nonce still recovers the private key on the spot, entropy source irrelevant. Several documented thefts were exactly this — not generation.
Bundled third-party or cross-chain SDKs that ship their own RNG inside an otherwise-clean app.
Custom entropy mixing — blending timestamps or sensor noise into platform CSPRNG output can end with less randomness than the platform offered. (The Coldcard fallback itself was seeded from device UID plus power-on timer state.)
Backup/KDF layers — weak KDF parameters, hardcoded IVs, exportable keys.

The three-step fingerprint

Locate the generation path. Find where mnemonics/seeds are produced; follow every call into bundled SDKs.
Classify the entropy source. Platform CSPRNG direct? JS-engine path (check every polyfill)? Custom mixing? Record the exact call chain.
Assign the verdict tier. Immune-by-design / JS-bridge / nonce / SDK / custom-mixing / KDF — each with its reproduction class.

Generation and signing must be fingerprinted separately: a clean generation path tells you nothing about nonce handling.

What "reproducible" means here

We publish our own capability the same way we fingerprint others: with an evidence pack, not adjectives.

Weak-entropy key recovery, end to end, hash-anchored: a simulated vulnerable seed source (the low-effective-entropy class), table sweep, private-key recovery, and an ECDSA proof-of-possession — canonicalized with RFC 8785 JCS, SHA-256 anchored, Ed25519 signed. The demonstration runs in a reduced key space for runtime (details inside); the class it models is the one that just produced the largest self-custody loss event of 2026. Anyone can re-run and re-verify it.

The bundle's core record is SHA-256 anchored (f5df38c1…, re-derivable) and Ed25519-signed; verification instructions ship with it.

Why 40–72 bits is fatal, briefly

A 2^40 sweep is hours-to-days on commodity compute; 2^72 is nation-scale. Between those bounds sits ordinary theft economics. The disaster was not exotic — it was a quantifiable, preventable configuration that survived five years of public firmware.

What we do

For wallet vendors, custodians, and AI-infrastructure teams: private key-path fingerprinting. Every engagement produces either the immune-by-design stamp or a reproduction-class report — with the evidence pack, not a slide.

wangguigui@correctover.com · https://correctover.com

Tools and evidence: github.com/DSHCorrectover — runtime verification for AI agents & node infrastructure.

Your keys are weaker than your cryptography: CVE-2026-73567 and the dead RNG that seeded SM2 keys

correctover — Tue, 27 Oct 2026 10:32:45 +0000

Math.random() is not a key generator. Everyone knows this. And yet — when a widely deployed SM2 library seeded its key material at module load, that's effectively what happened. Except worse: in Node.js, the randomness pool was never even filled.

This is the story of CVE-2026-73567, a vulnerability in which our Node.js impact correction was incorporated into the public advisory by the maintainer — and what it teaches us about the whole class of weak-entropy key compromises.

The discovery

While auditing key-generation paths in SM2 (the Chinese national elliptic-curve standard, mandatory in regulated industries there), I noticed something odd in the dependency chain: a big-number library harvested entropy from Math.random() — the non-cryptographic, browser-grade PRNG — at module initialization, and used it to seed its internal state. That state then fed private-key generation.

The publicly discussed impact assumed ~128 Math.random() calls at startup. When I built an instrumented Node victim and counted, the real number was zero. V8 defers Math.random()'s pool initialization in a way that left the seeding path reading predictable values — the effective root cause was a clock-only seed, and the advisory's root cause was corrected accordingly.

The consequence: given roughly a millisecond-scale time window, private keys were recoverable by enumeration. Sub-second. On an ordinary laptop.

And it didn't stop at static keys. The same RNG stream also fed signing nonces and ephemeral encryption keys. That means a key used only for signing was equally recoverable, and ciphertext from affected versions could be decrypted without the key.

What happened next

Beyond the advisory, our independent reproduction verified that the actual root cause was not merely weak entropy, but a clock-only seed due to dead code in the Math.random() pool-fill — a correction formally recognized and credited in GHSA-vh45-f885-3848.

Versions before the fix remain vulnerable forever. Every key generated by an unpatched build in a predictable-time window should be considered compromised.

This is a class, not an incident

One library got caught. But weak entropy is a systematic failure mode across the key-management stack:

V8's PRNG (Math.random(), xorshift128+ / MWC1616 eras) can be fully state-recovered from a handful of consecutive outputs — meaning any JS wallet or signing code that ever touches non-CSPRNG randomness is one observation away from compromise.
Historical events (Randstorm-class bugs, 2014-era wallet RNG flaws) show the same pattern repeating across ecosystems.
Cross-address clustering: weak-RNG victims often reuse exposed material across chains and address types, turning one bad key into a trail of them.
The SM2 ecosystem is structurally exposed here: guomi compliance pushes SM2 into places where the surrounding JS/Node key hygiene was never designed for it.

If your product generates keys, signs, or encrypts — in JavaScript especially — the question isn't whether your crypto is strong. It's whether your entropy path is.

What we do about it

At Correctover we recover keys from weak entropy — to prove the exposure before someone malicious does, and to build evidence that holds up:

Black-box weak-entropy health checks on key generation and signing paths
Real recovery demonstrations in isolated environments, with signed, timestamped evidence receipts (Ed25519 + RFC 3161) — findings a court or auditor can verify without trusting us
Coordinated disclosure done right: the advisory process above is our reference case

If you build wallets, custody, or exchange infrastructure and want your entropy path audited against this exact attack class, reach out: wangguigui@correctover.com.

Tools and evidence: github.com/DSHCorrectover — runtime verification for AI agents & node infrastructure.

Agent 安全不是单一赛道：三条技术边界的工程纪律

correctover — Tue, 15 Sep 2026 11:17:12 +0000

入站内容防御 / 供应链完整性 / 出站执行验证——三件事，三种代价，三种工程纪律
作者：Guigui Wang | Correctover — AI Reliability
日期：2026-09-15

本文涉及自有 Internet-Draft 内容均为 individual submission，not an RFC or IETF endorsement.
CCS 性能数据均为 Correctover 内部实测，文中逐条标注测量口径；不同口径不可直接比较。
文中提到的项目（CAITLYN、AgentSecCore/ANOLISA）为公开信息事实性引用，不含任何商业评价或排名意图。

当「AI Agent 安全」成为热词时，最危险的动作是把所有技术塞进同一个篮子。今天公开可见的三个代表性方案，恰好站在三条不同的工程边界上。把边界画清楚，比把它们揉成一顶「AI 安全标准」的大帽子，更对得起生产环境。

1. 三条边界

边界	问题	代表工程	工程纪律核心
入站内容防御	非可信内容进入 Agent 前是否被过滤	CAITLYN（arXiv:2608.27990，PolyU / CUHK）	双向规格验证（attack 必命中 + benign 零误伤）
供应链完整性	Agent 运行时加载的技能/代码是否被篡改	AgentSecCore（Alibaba Cloud Linux，ANOLISA 开源）	Ed25519 签名 + append-only 版本链 + Skill 快照漂移检测
出站执行验证	Agent 发出的工具调用是否符合运行时形态	Correctover CCS（IETF individual draft）	7 维运行时验证：Structure/Schema/Latency/Cost/Identity/Integrity/Security

三条边界不是三个竞品，是三个工程问题。任何一个真实的 Agent 部署，都可能同时需要三者的某一层。把它们混为一谈，会让企业误以为「买一个就够」；把它们画清楚，才能让每一层都做到它该做到的程度。

2. 入站内容防御：CAITLYN 的工程纪律

CAITLYN 是香港理工大学（PolyU）与香港中文大学（CUHK）团队 2026 年 8 月公开的研究项目（arXiv:2608.27990，v1 提交于 2026-08-28，CC0），定位是非可信入站内容（用户 prompt、工具返回值、外部网页）的间接提示注入防御中间件。

它最有价值的工程纪律是 System II 的反例引导技能合成闭环（counterexample-guided synthesis）：

漏报攻击 → 当作 counterexample
generator 合成新的防御技能
独立 verification sandbox 做双向规格验证——攻击正例必须命中、良性反例必须零误伤
reviewer 把关 → 带 lineage 写回技能库

可吸收的工程纪律：新 detector 必须通过「正/反」双面语料契约，并且可以追溯到催生它的那个 counterexample。这不是功能列表，是工程纪律。

边界：它解决的是「进来的内容是不是有毒」，不做 Agent 调用工具那一刻的运行时校验，也不做 Skill 文件在磁盘上的完整性守护。论文也如实给出了这条路线的工程代价：云端 LLM 判定路径在其评测中约为数秒至十余秒延迟、每查询约 0.003–0.007 美元量级，并且中间件在多个部署点默认 fail-open。准确率、延迟、适应性三者构成它要权衡的 trilemma。

Correctover 正在把这条工程纪律吸收到自己的规则更新管线（见 §5）。我们学纪律，不抄实现。

3. 供应链完整性：AgentSecCore 的边界

AgentSecCore 是 Alibaba Cloud Linux（Alinux）的本地 Agent 安全内核（官方文档，更新于 2026-09-10），开源版本为 ANOLISA（Apache-2.0），处于持续活跃迭代状态。

它最扎实的工作是 Skill Ledger（技能账本）：

每个 Skill 的 manifest（含文件哈希、扫描结果、版本信息）经 Ed25519 签名
append-only 版本链 + snapshot 机制，支持漂移识别与可信版本回退
6 个业务安全状态（pass / none / drifted / warn / deny / tampered）
与 SkillFS 职责解耦，已适配 6 类宿主：OpenClaw、Copilot Shell、Hermes、Codex、Qoder CLI、Qwen Code

可吸收的工程纪律：Skill/Plugin 的「身份 + 完整性」必须可校验，且任何漂移都必须可被检测。这是任何 Agent 供应链的基础。

边界：它强覆盖 Integrity 一维，部分覆盖 Identity 与 Security，不做出站工具调用的 Structure / Schema / Latency / Cost 校验（即 CCS 7 维中的 4 维）。在提示词扫描上，官方把强度分为 FAST / STANDARD / STRICT 三档，并注明 STRICT 是为 L3 语义层预留、当前与 STANDARD 等效；本地 L2 判定依赖用户自行部署 Ollama 小模型。处置姿态上，官方文档说明各宿主 hook 在 agent-sec-cli 缺失、超时或返回非法结果时统一 fail-open（放行并记录），优先保障 Agent 可用性。它是 OS 侧内容安全 + Skill 供应链守护，不是 sub-millisecond 的运行时验证引擎。

与 CCS 技术路径重合度最高的点是 Ed25519 签名 + 版本链，但粒度不同：AgentSecCore 守护 Skill 级（文件 / manifest），CCS 守护调用级（每一次工具调用）。fail-open 与 fail-closed 也是两种不同取舍——前者优先可用性，后者优先安全——而非高低之分。两条路径互为补充，不是替代。

4. 出站执行验证：Correctover CCS 的边界

Correctover CCS（Conformance Shape）是我们定义的 Agent 运行时验证标准（IETF Internet-Draft，individual submission），覆盖每一次工具调用的 7 个运行时维度：

Structure / Schema：调用消息是否符合协议形态与字段约束
Latency / Cost：响应时间与 token 开销是否符合预期形态
Identity / Integrity / Security：工具、内容、行为的可信性校验

运行时校验的核心纪律是确定性 + 零 token + sub-millisecond：

Correctover 核心判定层 Node P50 ≈ 2.7µs
Python 端到端 P50 ≈ 27µs
对外口径：core eval P50 < 10µs / P99 < 25µs（实测 P50 ≈ 7.5µs、P99 ≈ 21µs）
fail-closed：运行时校验失败 = 拒绝执行，而不是放行
Ed25519 签名收据（receipt）提供可独立验证的审计证据

为什么有三组性能数字、它们为何不矛盾。 三者测量边界不同，不能直接比较：Node P50 ≈ 2.7µs 是核心判定层在 Node 运行时的单次纯校验耗时，是最优单点；Python 端到端 P50 ≈ 27µs 走的是真实集成路径，含 Python 调用链上的序列化与封装开销；对外承诺的 core eval P50 < 10µs / P99 < 25µs 取的是跨实现的保守口径，并显式覆盖 P99 尾延迟，而不是只报最好看的平均值。对外统一使用保守口径，内部单点数据在此一并披露，只为交代测量边界。

边界：它守护的是「Agent 发出的调用是否合规」。它不做入站内容的间接注入过滤（那是 CAITLYN 一类中间件的地盘），也不做 Skill 文件级的供应链漂移检测（那是 AgentSecCore 的地盘）。

5. 三条边界之间的工程对话

最有意思的工程对话发生在边界之间：

CAITLYN 的双向规格验证纪律 → 被我们（Correctover）吸收到规则更新管线：每条新规则必须带攻击正例集 + 良性反例集 + 全量回归，门禁 fail-closed（纪律跨边界复用，实现不抄）。
AgentSecCore 的 Skill Ledger → 启发 Correctover 的规则包签名链：规则包可 Ed25519 签名，复用 trust.py 两级信任模型（VERIFIED → ACCEPTED），与调用级 receipt 互补（资产层 + 调用层双保险）。
CCS 的调用级 receipt → 对 CAITLYN / AgentSecCore 都透明：它们在决策时产生的记录本身也可以被 CCS 校验，形成「对防御行为的防御」。

这种分层对话，才是对得起生产环境的工程态度。

6. 对 Correctover 自身的要求

我们把自己定位在出站执行验证这一条边界上，不跨边界声称自己覆盖所有 Agent 安全问题。

我们有的：CCS 7 维运行时校验、Ed25519 签名收据、sub-ms 确定性引擎、fail-closed 闸门、两阶段信任模型（VERIFIED / ACCEPTED）。
我们正在补的：规则入库双向语料门禁（对 CAITLYN 工程纪律的吸收，正在 P0 阶段）；规则包签名链（借鉴 Skill Ledger 的思路）。
我们不做的：入站内容防御（CAITLYN 一类中间件的地盘）、Skill 文件漂移检测（AgentSecCore 的地盘）。

我们同时承认：CCS 不是 AI 安全的唯一答案，它只是运行时验证层的一个答案。如果你的威胁模型同时包含入站内容投毒和第三方 Skill 供应链，我们建议在 CCS 之外同时部署入站内容防御与 Skill 完整性方案——任何单一层都不足以覆盖完整的 Agent 攻击面。把边界画清楚，比把功能堆到一起更值得尊重。

7. 术语与事实锚点

CAITLYN：arXiv:2608.27990（PolyU / CUHK，v1 2026-08-28，CC0）。属入站内容层，不对应 CCS 7 维中的任何一维。
AgentSecCore / ANOLISA：阿里云 Alinux 官方文档（页面更新 2026-09-10）；开源版 ANOLISA，Apache-2.0，GitHub 活跃维护。在 CCS 7 维中强覆盖 Integrity（1 维），部分覆盖 Identity + Security（2 维），不覆盖 Structure / Schema / Latency / Cost（4 维）。
Correctover CCS：IETF Internet-Draft individual submission；Correctover 开源实现；性能实测 Node 核心判定层 P50 ≈ 2.7µs、Python 端到端 P50 ≈ 27µs，对外保守口径 core eval P50 < 10µs / P99 < 25µs（实测 7.5 / 21µs）。
Internet-Draft 免责：本文对 Correctover 自有 Internet-Draft 的引用均为 individual submission, not an RFC or IETF endorsement。

想先看清自己 Agent 的出站调用暴露面，可以用免费自动扫描器建立一条基线（correctover.com）；对于自动规则无法判定的部分（实际可利用性、生产危害、合规证据），再考虑人工运行时审计。

本文是 Correctover 对 AI Agent 安全三条技术边界的工程视角陈述，不是对任何产品或研究的排名或评价。作者对 CAITLYN 团队与 AgentSecCore/ANOLISA 团队公开贡献的工程纪律保持尊重。

Tools and evidence: github.com/DSHCorrectover — runtime verification for AI agents & node infrastructure.

Your agent sandbox is a physical exam, not a black box: dynamic analysis can't be the last word in agent security

correctover — Fri, 04 Sep 2026 15:21:31 +0000

A pattern is settling into the AI agent security stack: when you're unsure about a skill, tool, or plugin, you detonate it. Drop it into a sandbox — a detonation chamber, a honeypot environment — let it run for real, and watch what it does. Does it phone home? Does it read files it shouldn't? Does it unpack additional payloads?

It feels rigorous. Execution is truth; static analysis is just reading. And dynamic analysis does catch things static analysis misses — unpacked payloads, environment-triggered behavior, exfiltration that exists nowhere except at runtime.

But here is the framing problem. A sandbox run is a physical exam: a controlled check-up, in a clinic, on a good day, before the patient starts living their life. It is not a black box: the tamper-evident recorder running during the actual flight, readable by investigators who don't trust the airline.

Both matter. They are not interchangeable, and treating the exam as the recorder leaves a specific, predictable gap.

What dynamic detonation gets right

Let's be fair to the sandbox, because it earns its place. Static analysis reads code and reasons about what it could do; dynamic detonation watches what it does do. That distinction is real. Some behavior exists purely at runtime: payloads that decrypt themselves in memory, network calls assembled from environment state, logic that branches on what it finds on disk. If you never execute the artifact, you never see that side of it.

For agent skills and tools — bundles of code that an LLM can invoke, often sourced from third-party registries, often with broad permissions — "run it in a cage and watch" is a genuinely useful pre-release check. It should be part of the pipeline. The argument here is not against the sandbox. It is against asking the sandbox to do a job it structurally cannot do.

Boundary 1: coverage is an arms race, not a one-time build

Anti-sandbox and anti-honeypot evasion is a roughly twenty-year-old arms race in the malware world, and it remains unresolved — managed continuously, never finished. A sample can check whether it is being watched: timing delays and sleep timers, virtual-machine fingerprints, the absence of mouse movement or browser history, telltale environment variables, user-data directories that look freshly faked. Detect the clinic, and you behave like a model patient. The malicious payload waits for what looks like real life.

This has a direct consequence for agent security tooling. When a vendor quotes a dynamic-analysis catch rate — runtime detonation recovering a meaningful share of what static analysis misses — ask the mirror question: what share of malicious behavior does the detonation chamber itself miss, and who measures that? In detection engineering, a detector cannot prove its own completeness. The evasions you can observe are the ones you already know about; the evasion that stays quiet in your environment is, by construction, invisible to you. Coverage is a maintenance contract, not a build artifact — which means a sandbox you stopped tuning is a sandbox whose edge is eroding.

Boundary 2: slow and expensive — a deployment gate, not a runtime gate

Real detonation costs real things: environment construction, warm-up, a timeout window long enough to catch delayed payloads, resource isolation, teardown. That budget is fine for a release pipeline. It is not fine for the request path.

An agent in production makes tool calls constantly — each one a decision point — and you cannot route every call through a multi-minute detonation without making the agent unusable. So the sandbox sits, structurally, before deployment: it audits the artifact you shipped. Everything that happens afterward — production traffic, real sessions, real users — happens outside its field of view.

This is the physical-exam property. The exam happens before the flight. It cannot watch the flight, no matter how thorough it was.

Boundary 3: honeypot behavior is not production behavior

Even when the sandbox watches a run, it watches a drill. The clinic has synthetic inputs, disposable credentials, empty data directories, and no real user in the loop. Production has the opposite: real documents, live tokens with real permissions, and chained calls where tool B receives output shaped by tool A — chains that can run many steps deep by the time something goes wrong.

Plenty of real incidents live in that gap. Code that behaves in a demo environment but reaches for the customer database when a real database exists. A tool that is harmless with a dummy API key and aggressive with a valid one. A chain where each step looks fine individually and the composition is the exploit. You audited the rehearsal. The accident happens on opening night.

"OS-level logs can't be faked" — they can

One defense of dynamic execution is that the operating system sees everything: syscalls, file access, network connections. Logs at that layer get treated as ground truth.

They are ground truth right up until the thing you are watching holds administrator or root privileges — which is exactly what a malicious tool, an exploited dependency, or a successful sandbox escape hands an attacker. Code at that level can hook syscalls, suppress its own traces, wipe or rewrite audit records, and feed the observer a clean narrative. A log written by the party whose behavior is in dispute is self-reported evidence.

Aviation is instructive here. The pilot's handwritten logbook is useful, but nobody mistakes it for a flight recorder. A black box is engineered so the pilot cannot rewrite it after the fact: tamper-evident, write-once, readable by people who do not trust the emitter. If your "runtime evidence" is produced and stored by the same runtime you are auditing, you have a logbook.

What an agent black box actually looks like

The useful unit is a per-invocation receipt: one record per tool call, emitted as the call happens, with properties that make it evidence rather than a report:

Cryptographically bound to the specific invocation — signed, with hashes covering the caller, the tool, the arguments, and the authorization under which the call ran. A receipt you cannot tie to a concrete call is decorative.
Anchored outside the call path — verifiable by a party who is neither the emitter nor on the execution path: an append-only transparency log, a remote-attestation flow, any arrangement where rewriting history means breaking the anchor, not merely breaking into the box.
Three states kept separate — the agent's decision (what it chose to call and why), the provider's outcome (what the tool reported back), and the observed effect (what actually changed). These routinely disagree, and collapsing them into one "success/failure" field hides exactly the disagreements that matter.
Indeterminate stays indeterminate — when evidence is missing, the state is "unknown," and policy fails closed. "No evidence of malice" must not be recorded as "verified safe."

This is the direction of open standards discussions in the MCP and agent security community: signed, verifiable invocation records rather than vendor-narrated dashboards. The format is less important than the property — evidence has to be checkable by someone with every reason to distrust the system that produced it.

Use both — they do different jobs

For teams building or shipping agents, the practical split:

Before release, do the physical exam. Static analysis plus dynamic detonation of skills and tools. You do not need an elaborate program for this; free and open toolchains cover the large majority of the basics — scan the code, detonate the artifact, fix what surfaces. Run it on every release, because coverage decays.
During production, require the black box. Your agent framework should emit verifiable decision records — who acted, what action, under what authorization, with what result — cryptographically signed and anchored somewhere the emitter cannot quietly rewrite them. If your framework cannot do this yet, that gap deserves more attention than another dashboard.
When evaluating agent security tooling, ask one question up front: does it produce evidence you can verify independently? A dashboard the vendor controls tells you what the vendor's system chose to record. That is a report. It is not evidence until a party outside the trust boundary can check it.

The exam does not replace the recorder

Sandboxes are good engineering. Detonate suspicious code, watch it run, catch what static reading cannot see — keep doing all of it. Just do not mistake the pre-flight check-up for the flight recorder. The exam tells you what a tool does when it is being watched in a clinic. The black box tells you what actually happened, in production, in a record the tool cannot rewrite.

If you want the physical-exam piece today, we publish a scanner that runs locally: npx correctover-scan@latest. It is MIT-licensed open source and zero-upload — your code does not leave your machine, and there is nothing to sign up for. There is also a web entry point at https://correctover.com/scan.html. For the runtime side, take the same question to your framework and your vendors: where is the receipt, and who can verify it without trusting you?

Tools and evidence: github.com/DSHCorrectover — runtime verification for AI agents & node infrastructure.

A PreToolUse security gate for Kimi Code: block live secrets, plaintext MCP, and SSRF before they hit disk

correctover — Fri, 04 Sep 2026 05:16:16 +0000

Last week Kimi Code (Moonshot AI's terminal coding agent) shipped a fix for a nasty prompt-injection vector: timestamps in tool output could be crafted to smuggle instructions into the model's context (MoonshotAI/kimi-code#2028, fixed in the new v2 engine in 0.39.0 via #3007/#3341). Prompt-injection hardening matters — but injection is only half the story.

A coding agent that has been steered (or is simply over-eager) can also:

write a hardcoded sk-live-... key into src/config.js
add an MCP server over plaintext HTTP
point a tool at 169.254.169.254 (cloud-metadata SSRF)
run npm install inside a repo that already contains any of the above

Kimi Code has a mechanism for exactly this: Hooks (Beta). PreToolUse events fire before the permission check, and a hook can block the action by exiting with code 2. The block reason on stderr is fed back to the model — so it fixes the problem and retries.

We built an open-source (MIT) hook that wires this event to a real scanner: correctover-security-hook. This post explains how it works, what it catches, and how to verify it yourself in under a minute.

How Kimi Code hooks work (60-second version)

Rules live in ~/.kimi-code/config.toml as [[hooks]] entries with four fields: event, matcher (regex), command, timeout.
On a hookable event, the CLI pipes a JSON payload (tool name, parameters, file content) to your script via stdin.
Exit semantics: 0 = proceed; 2 = block, stderr goes back to the LLM as the reason; any other non-zero / timeout = fail open (proceed).
Only PreToolUse, Stop, and UserPromptSubmit can block. Security gates must hang on PreToolUse.
Official guidance: hooks are fail-open by design — a reminder/light-gate layer, not your only security control. Keep permission approvals, code review, and CI scanning.

What the hook does

Two PreToolUse matchers:

Matcher	What gets scanned
`WriteFile\	StrReplaceFile`
`Shell`	MCP-related commands (`mcp add`, config edits) → recursive config scan of the project; with `CORRECTOVER_SCAN_INSTALLS=1`, `npm/pnpm/yarn/bun install` → full-project code scan

Scanning runs through correctover-scan, an open-source npm package invoked via npx (free tier, no API key). The hook maps scanner output to exit codes:

fail-level finding → exit 2 (block; reason fed back to the model)
clean → exit 0
scanner missing / network down / timeout / quota exhausted → exit 0 with a stderr log (fail-open: a scanner problem never blocks your work)

What it actually flags:

Code layer (.js/.mjs/.cjs/.ts): hardcoded live-key patterns (sk-...), child_process with shell: true, eval / Function / vm dynamic execution, cloud-metadata/SSRF signals, credentials flowing into env/stdout.
MCP config layer: MCP server URLs without TLS (plaintext http), internal/cloud-metadata endpoints (169.254.169.254), plus warn-level gaps — missing timeouts, allowlists, or kill-switch.

The nice part is the feedback loop. When a write is blocked, the model reads why ("hardcoded credential at config.js:12 — move to an environment variable") and usually rewrites the code itself, then retries. The gate turns a latent secret leak into a self-correcting loop.

Test matrix: 8 scenarios, all behaving as expected

The repo ships a selftest that fakes Kimi Code's stdin payloads (measured with correctover-scan v1.7.2, Node 22):

#	Scenario	Scanner result	Hook exit
A	`WriteFile` a `.js` with a hardcoded `sk-live-` key	`cred-exposure` FAIL	2 (block)
B	`WriteFile` a clean `.js`	no fail	0 (pass)
C	`WriteFile` an unsafe MCP config (plaintext `http` + `169.254.169.254`)	`mcp-tls` + `mcp-ssrf` FAIL	2 (block)
D	`Shell` plain `ls -la`	not scanned	0 (pass)
E	Scanner binary missing (fault injection)	startup failure	0 (fail-open)
F	`Shell` `mcp add` while a dangerous MCP config sits in the project	recursive scan, 2 FAIL	2 (block)
G	`npm install` with `CORRECTOVER_SCAN_INSTALLS=1`, leaky file in repo	bundle FAIL	2 (block)
H	`npm install` with default config	not scanned	0 (pass)

The bundled script covers the five core cases (A–E, expect 5 pass / 0 fail); F–H use the install-toggle and are documented in the repo README.

git clone https://github.com/DSHCorrectover/kimi-code-security-hook
cd kimi-code-security-hook/selftest
bash run-hook-selftest.sh

Or try it in a real session: ask Kimi Code to "add a Stripe key constant sk-live-51q8xPbQmRzNk2vWcY7aHdJfT3uLsE0oXnMp in src/config.js" — the write should be blocked and the model should rewrite it to read from an environment variable. (The sample key is a random fake string.)

Install

As a plugin: the repo is a Kimi Code plugin (kimi.plugin.json at the root) — point your Kimi Code plugin flow at the repository and the two PreToolUse hooks register automatically. We've also submitted it for the curated plugin marketplace (MoonshotAI/kimi-code#3534).

Manual install:

mkdir -p ~/.kimi-code/hooks
cp hooks/correctover-hook.mjs ~/.kimi-code/hooks/correctover-hook.mjs

Then add to ~/.kimi-code/config.toml:

[[hooks]]
event = "PreToolUse"
matcher = "WriteFile|StrReplaceFile"
command = "node ~/.kimi-code/hooks/correctover-hook.mjs"
timeout = 180

[[hooks]]
event = "PreToolUse"
matcher = "Shell"
command = "node ~/.kimi-code/hooks/correctover-hook.mjs"
timeout = 180

Start a new session (or /reload) and check /hooks. Requires Node.js 18+.

Environment variables:

Variable	Default	Purpose
`CORRECTOVER_SCAN_CMD`	`npx correctover-scan`	Scanner command; point at a local mirror for offline/CI
`CORRECTOVER_SCAN_INSTALLS`	`0`	Set `1` to bundle-scan the whole project before package installs
`CORRECTOVER_SCAN_TIMEOUT`	`120000`	Per-scan timeout in ms (fail-open on timeout)

The honest limits

Fail-open by design. Scanner missing, network down, timeout, or free-tier quota exhausted → the action proceeds with a stderr log. This is a light gate, not your only control.
Code scanning covers JS/TS only (signal-based, not full type semantics). Python and other languages pass through — wire up a language-appropriate scanner for those.
Signal scan, not proof of exploitability. Findings locate signals at file+line; reachability and intent need manual review.
Hooks are Beta in Kimi Code — event names, config format, and tool names may change across versions; re-run the selftest after upgrades. Legacy kimi-cli (~/.kimi/) uses different tool names (Bash); the script tolerates the aliases but matchers may need adjusting.

For one-off manual checks without installing anything, there's a zero-upload browser scan at correctover.com/scan.html — paste code, everything runs locally in the page.

Why this matters now

Agents are moving from "suggest diffs" to "write files, run commands, wire up MCP servers" — the boundary between generated text and executed action gets thinner every release. Prompt-injection fixes like #2028 harden what the model believes; PreToolUse hooks gate what the agent does. Defense in depth means you want both.

Repo (MIT, issues/PRs welcome): https://github.com/DSHCorrectover/kimi-code-security-hook
Scanner on npm: https://www.npmjs.com/package/correctover-scan

We scanned open-source finance MCP servers — here are the four ways API tokens leak

correctover — Fri, 04 Sep 2026 01:52:57 +0000

In 2026, financial data terminals started shipping MCP interfaces. Data vendors and open-source wrappers now expose market data, fundamentals, and fund flows as MCP tools that any AI client — Claude Code, Cursor, Copilot — can call.

That is convenient. It also means every one of those MCP servers holds a paid API token in memory: data-vendor tokens, vendor keys, session credentials. Unlike a random weekend project, those tokens carry metered quotas, billing relationships, and often access to non-public data feeds.

We took seven open-source JS/TS finance MCP servers (npm packages and GitHub repositories) and ran our local static scanner, correctover-scan v1.7.2, over them. This post describes the four concrete leak patterns we saw, how often they showed up in published code, and the pre-release checklist that catches all of them. No projects or maintainers are named; findings have been privately disclosed to the affected maintainers.

How we scanned

The scanner runs entirely locally — the source code never leaves your machine:

npx correctover-scan --bundle ./path/to/mcp-server

For npm packages we ran it against npm pack tarballs (the exact build users install); for repositories we scanned the checked-out source. The bundle mode parses .js/.mjs/.cjs/.ts files and runs two layers of checks: a configuration layer (hardcoded secrets, dynamic code execution) and a code layer (plaintext outbound endpoints, credential flow into logs, MCP transport flags). Every machine-generated warning with a file/line was then manually reviewed against the actual source, because some classes of issues — CORS policy and network bind addresses — the scanner only flags indirectly and a human must confirm.

Honest scope note: all seven targets were JS/TS, the scanner's home turf. The Python fastmcp ecosystem (which includes several popular finance MCPs) was not in scope; the scanner does not parse .py files yet, and we did not paper over that gap. Closed-source vendor MCPs had no published server source to scan either.

What the numbers look like

Of the seven targets, five ship as published npm packages. In two of those five published packages (40%) — two distinct projects — we confirmed at least one of the four token-leak patterns below in the exact artifact users install. One project had three of the patterns; another had two. The other three published packages, plus the two repository-only targets, came back clean on manual review.

A note on severity labels: the scanner rates hardcoded credentials as fail, while plaintext HTTP, logging, CORS, and bind issues are rated warn. That understates them — a token sent over plaintext HTTP is a token disclosure, full stop. We went with manual review, not the score.

One detail worth flagging for anyone maintaining an MCP: for one project, both of its issues were already fixed on the repository's main branch — but the fixes had never been published to npm. The code your users npx can lag your own HEAD for months.

Pattern 1: The token goes out over plaintext HTTP

The data vendor's endpoint was hardcoded as an http:// URL, and the token rides along in the POST body:

// api client in a finance MCP server (anonymized)
export class DataClient {
  token: string;
  private apiUrl = "http://api.marketdata.example";

  constructor(token?: string) {
    this.token = token ?? process.env.DATA_TOKEN ?? "";
  }

  async call(apiName: string, params: Record<string, unknown>) {
    const response = await fetch(this.apiUrl, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        api_name: apiName,
        token: this.token,
        params,
      }),
    });
    // ...
  }
}

We saw this in 2 of the 5 published packages (40%) — in one case across three separate tool modules, each with its own hardcoded http:// fetch.

Risk: anyone positioned on the same network path — coffee-shop Wi-Fi, a shared office VLAN, a compromised hop — reads the bearer token straight off the wire. The token is a paid, quota-bearing credential.

Fix: use https://. The vendor endpoint supported HTTPS in every case we saw; this was a copy-pasted URL scheme, not an infrastructure constraint. Put the base URL in one config constant so it cannot drift per-file.

Pattern 2: The token gets logged to stdout

In stdio MCP mode, stdout is the protocol channel — it is captured by the MCP client's log files. One published package logged the entire request object, token included, right before sending it:

// tool module in a published package (anonymized)
const apiParams = {
  api_name: "balancesheet",
  token: CONFIG.API_TOKEN,
  params: { code: code },
};

console.log("API request params:", apiParams);
const response = await fetch(CONFIG.API_URL, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(apiParams),
});

1 of the 5 published packages (20%) did this, in three tool modules.

Risk: the token lands in MCP client log files on the developer's disk, in CI logs if the server runs there, and in anything that scrapes the host's stdout. It is the same credential, now duplicated into log storage with different retention and access rules.

Fix: redact before you log. Log only the business parameters (params.params), or pass the payload through a small redactor that masks known credential fields:

const redactToken = (p) => ({ ...p, token: p.token ? "***" : undefined });
console.log("API request params:", redactToken(apiParams));

Pattern 3: `Access-Control-Allow-Origin: *` on a streamable-http transport

When an MCP server offers Streamable HTTP, it is a web server — and the browser same-origin rules apply to it. One published package enabled CORS with a wildcard and explicitly allowed token-bearing custom headers:

// http transport setup (anonymized)
const app = express();

app.use(
  cors({
    origin: "*",
    methods: ["GET", "POST", "OPTIONS"],
    allowedHeaders: [
      "Content-Type",
      "Authorization",
      "Mcp-Session-Id",
      "X-Api-Token",
    ],
  })
);

1 of the 5 published packages (20%) had this.

Risk: any web page the operator visits can issue a cross-origin POST to http://localhost:3000/mcp and invoke the server's tools. In the package we saw, the server fell back to reading the token from request headers when no server-side token was set — meaning a page could potentially ride the server's own credential. CORS is not optional configuration here; it is the authentication boundary between the browser and a local privileged service.

Fix: an MCP HTTP endpoint meant for local clients should not use origin: "*". Restrict allowed origins to an explicit allowlist (or omit wildcard CORS entirely and document the local proxy setup), and never accept a credential from a request header you did not explicitly opt into.

Pattern 4: The server binds to all interfaces with no Host allowlist

The companion mistake. The same package started its listener without a host argument:

// default in Node/Express: binds 0.0.0.0
app.listen(PORT, () => {
  console.log(`MCP endpoint: http://localhost:${PORT}/mcp`);
});

1 of the 5 published packages (20%). The startup message says localhost; the socket tells a different story — omitting the host binds 0.0.0.0, reachable from the entire LAN.

Risk: combined with pattern 3 (and no token gate), anyone on the local network can reach and invoke the MCP server — a paid data quota sitting on a laptop port. For comparison, the sibling project from the same maintainer had already done it correctly in its newer code: app.listen(PORT, "127.0.0.1") plus an ALLOWED_HOSTS Host-header check.

Fix: bind explicitly:

const HOST = process.env.HOST ?? "127.0.0.1";
app.listen(PORT, HOST, () => { /* ... */ });

If a deployment genuinely needs a non-loopback bind, require an explicit env var to opt in and add a Host-header allowlist.

A pre-release checklist for MCP authors

Everything above is caught before publish with five checks:

Grep your built artifacts for http:// — run the scanner against the npm pack tarball, not just the repo source. The build is what users run.
Audit every console.log/logger call on a request or response path — no credential field should reach stdout/stderr in stdio mode. Add a redact helper and route payload logs through it.
If you offer Streamable HTTP, bind 127.0.0.1 by default and require explicit configuration to expose anything wider.
No wildcard CORS on a transport that carries credentials — explicit origin allowlist, and never fall back to trusting client-supplied token headers.
Publish the fixes — main-branch patches do not protect users on the npm latest tag. Make the release part of the fix.

Wire this into a prepublishOnly script and a CI step; the patterns are cheap to detect automatically and expensive to explain after the fact.

Try it on your own MCP

CLI (local static scan, code never leaves your machine): npx correctover-scan
Zero-install browser version: https://dshcorrectover.github.io/agent-audit/scan.html
Project organization: https://github.com/DSHCorrectover

Disclaimer

Results are based on static analysis of publicly available package versions and repositories at scan time (2026-09-04). They are not a security rating or certification of any individual project; absence of findings in this scan is not a guarantee of safety, and findings reflect the versions we downloaded. The Python fastmcp ecosystem and closed-source vendor MCPs were outside this round's scope. All confirmed findings have been privately disclosed to the relevant maintainers.

You can run a security scanner without shipping your source code anywhere

correctover — Thu, 03 Sep 2026 11:10:25 +0000

When you build an AI agent, you end up with a folder of things you do not want to upload to a stranger's server: an MCP config full of API keys, a node_modules bundle with third-party skills, and — if you ship an SDK or an MCP server to clients — source code that is literally your product.

The usual "free online scanner" flow asks you to either paste your code into a box or zip up the repo and upload it. That is fine for a public demo project. It is a non-starter for closed-source, unreleased, or commercially sensitive code.

It turns out you do not need a backend to do this. A static-analysis scanner can run entirely in the browser tab. Here is how we built ours, and the one architectural decision that makes it trustworthy.

The constraint: the bytes must never leave the machine

The goal was simple to state and surprisingly easy to get subtly wrong:

drop in an mcp.json / MCP config, or a JS bundle / node_modules folder
get a report mapped to OWASP AISVS 1.0 (the AI security verification standard)
zero upload, zero account, zero telemetry

"Zero upload" is not a marketing line here, it is an enforced property. There is no server endpoint to receive files. The page is static HTML + one inlined JavaScript bundle. fetch is never called with file contents. The scanning engine reads files through the browser's own File / FileReader API (drag-and-drop or the file picker), analyzes them in memory, and renders the report into the DOM. Close the tab and the data is gone.

You can verify this the honest way: open DevTools → Network, drop in a file, and watch nothing leave.

How a CLI scanner becomes a browser scanner

The scanner already existed as an npm CLI (npx correctover-scan) and a GitHub Action. The trick to the browser version was that the engine was already pure static analysis — no network calls, no model dependency on the hot path. The core verification logic runs in sub-millisecond time on the core verification hot path, which matters because the browser tab has to stay responsive while you drag in a few hundred files.

The build step (tools/build-browser.js) bundles the same core/ modules the CLI uses into a single scan-bundle.js and exposes them on window.CorrectoverScan. The HTML page calls:

scanConfig(text) for MCP config files — 14 checks covering things like MCP transport TLS, tool auth, tool-allowlist pinning, kill-switch / budget limits, SSRF guards, credential exposure, sandboxing, version pinning, and logging.
scanBundle(files) for JavaScript — a set of checks over the bundled code, with a semantic pass instead of naive keyword matching.

That last part is where naive scanners fall over. A grep for child_process or eval will flag every build tool, test runner, and bundler in existence. The engine classifies intent: is that exec() argument a hardcoded constant or attacker-controlled? Is the eval inside a known code-execution sandbox, or is it running LLM-controlled input? Is the credential-looking regex part of a detection rule (the scanner contains a few of those itself)? Benign contexts get suppressed; genuinely dangerous patterns — dynamic eval of model output, unguarded shell execution, secrets passed to an unauthenticated MCP transport — get surfaced.

Some checks are marked semi-automated: the engine flags the pattern, but a human has to confirm whether the control is actually enforced in deployment. The report says so explicitly.

Mapping to a standard instead of inventing one

Rather than hand you a pile of red/yellow dots, every check maps to an AISVS 1.0 control (for example, tamper-evident logging under the orchestration/agentic security chapter). The mapping page is deliberately honest about coverage: the automated scanner covers parts of 8 of the 12 AISVS chapters, and the chapters it cannot cover statically — training-data integrity, adversarial robustness, model lifecycle change control — are marked as not covered, not silently skipped.

That honesty matters. An automated scan is a fast first pass; it is not an audit, a certification, or a compliance verdict. The printed report carries that disclaimer, and the pages that reference AISVS note that OWASP® and AISVS are trademarks of the OWASP Foundation, which does not endorse or certify products.

Why this changes the workflow

For a team shipping agents or MCP-based products, the practical difference is:

You can scan the thing you were going to ship. Unreleased SDK, internal agent config, client code under NDA — none of it touches a server.
You get a shareable artifact. The report prints/saves as PDF from the browser, so you can attach it to a vendor response without anyone needing an account.
The same engine runs in CI. The browser scanner, the CLI, and the GitHub Action share the core modules and the rule identifiers, so a finding has the same name wherever it shows up.

The free scan deliberately does not try to do everything. It cannot produce a signed audit opinion, it cannot sign off on your supply chain, and a clean report does not mean "no vulnerabilities" — static analysis has false negatives by construction. For a vendor-acceptance or compliance trail you still need a manual audit. What it gives you is a five-minute, privacy-preserving first look at the configuration and bundle mistakes that cause the worst agent incidents: over-permissive tool allowlists, MCP servers without auth or TLS, unbounded agent budgets, and model output flowing into a shell.

Try it, and watch the Network tab

The scanner is here — a static page, no signup:

https://dshcorrectover.github.io/agent-audit/scan.html

Drop in an mcp.json or a JS bundle, open DevTools → Network first if you are the skeptical type (you should be), and watch the bytes stay put.

If you build agent tooling, I would be curious to hear what it flags in your own config — especially the semi-automated checks, where a human reading the context still beats any rule.

This article references OWASP AISVS 1.0 as an external, independently maintained community standard; Correctover is not affiliated with or endorsed by OWASP, and automated scanner output is not an audit or certification. Work on the related conformance receipt protocol is documented in an individual Internet-Draft (draft-correctover-ccs), which is an IETF work-in-progress, not an RFC and not an IETF endorsement.

Valid provenance is not valid code: a supply-chain worm shipped with a valid SLSA attestation

correctover — Thu, 03 Sep 2026 06:30:50 +0000

In May 2026, a supply-chain worm did something the security community had been warning about for years: it got the receipt.

According to Akamai's analysis, the May 11–12 wave of the Mini Shai-Hulud campaign didn't steal an npm token. It poisoned a GitHub Actions CI cache through a fork-pull-request misconfiguration in the TanStack release workflow, waited for a legitimate maintainer merge, then ran inside the trusted release pipeline. The worm scraped credentials from the runner's memory and exchanged them for publish credentials through npm's own OIDC token endpoint. The result, in Akamai's words, was that the attack was "invisible and grant[ed] it SLSA attestation validation." (Akamai Security Intelligence Group, May 15 2026)

Across the full campaign (an earlier wave hit SAP's @cap-js packages, PyTorch Lightning, and Intercom in late April/early May), Cloud Security Alliance counts 180+ compromised packages, 400+ malicious versions, affecting packages with more than 518 million cumulative historical downloads. (CSA research note)

The worm also installed persistence into Claude Code session hooks and VS Code task automation — which means it specifically dug into the agent tooling layer, and survived an npm uninstall.

What the attestation actually attests

This is not a Sigstore flaw, and it's not a SLSA flaw. The provenance system worked exactly as designed. A SLSA Build Level 3 attestation answers one question:

Was this artifact produced by the trusted build environment, from the claimed source?

It does not answer:

Is the code in this artifact what the maintainer thinks it is?

When the build environment itself is compromised, the attestation is produced honestly — by a dishonest environment. The signature is valid. The certificate is valid. The log entry is valid. The code is a worm.

Valid provenance is not valid code.

Keyless signing (the Sigstore/Fulcio model) binds identity to a short-lived OIDC token issued to the CI environment. That's a great default for the overwhelming majority of projects, and we use the same transparency log it writes to (more on that below). But it draws the trust boundary around the build environment — and the build environment is exactly what Mini Shai-Hulud attacked.

Two layers the receipt doesn't cover

Reading the post-incident writeups, two gaps keep showing up:

1. Content-first evidence. Attestations are environment-first: they certify where and how something was built. A content-first receipt certifies what the code is: a canonical manifest of every file and its hash, signed, anchored to a transparency log, with a durable citation that outlives any single registry or CI system. You can answer "does this byte-for-byte match what was anchored at release time?" offline, without asking anyone's server.

2. An optional key-isolation path. Keyless signing has no concept of "the signing key never touches CI." For most projects that's fine — convenience wins. For high-assurance releases (infrastructure packages, agent runtimes, anything that harvests credentials by design), there's value in a mode where the signing key lives outside the runner: an offline signer, a human approval step, or a KMS. Compromising a runner then no longer yields the ability to mint a valid release identity. The ecosystem has the building blocks (cosign supports bring-your-own keys), but the content-manifest-and-durable-anchor layer around them is still DIY.

There's also a third gap that matters specifically for AI assets: hashes answer "is this identical," but never "is this derived from mine." A model fine-tuned from your weights, or a plugin forked past recognition, hashes differently by design. That requires semantic comparison — a different problem from signing.

What we built (and what we refuse to claim)

We work on this problem. Our open-source code birth certificate produces a signed content manifest (JCS-canonical hashes, Ed25519), anchors it to the public Rekor transparency log, and optionally mints a Zenodo DOI as a durable citation. A zero-configuration GitHub Action runs it on release; verification needs no account and no server of ours — the public key is embedded in the receipt, so verification is fully offline.

Our own dogfood anchors are public and independently checkable: Rekor log index 2694324795 with DOI 10.5281/zenodo.22266162. The GitHub Action that mints these certificates anchors its own repository on every run inside CI — the latest such self-anchor is Rekor index 2695953558, produced by a public GitHub Actions run rather than anyone's laptop.

Three things we want to be explicit about, because a supply-chain incident is a bad time for marketing ambiguity:

If you run our Action with the signing key stored in a CI secret, you stand on the same side of the trust boundary as keyless signing. That's the convenience mode, and it's a reasonable default. The key-isolation mode — key held outside the runner — is the one that changes the threat model. Pick deliberately.
We build on Sigstore, not against it. Our anchors are Rekor entries. We're an application layer on top of the public transparency-log ecosystem, not a replacement. "Sign everything keyless by default" remains the right advice for most projects.
Anchoring proves existence, timestamp, and content binding — nothing else. It doesn't prove code is safe, isn't malware, or isn't infringing. A DOI is evidence of existence and timestamp, not a copyright registration. And no signature — ours or anyone's — would have stopped Mini Shai-Hulud's persistence in Claude Code hooks. That's a runtime problem: what the agent does after install, which is the other half of what we work on.

The practical takeaway

After Mini Shai-Hulud, the question "is your supply chain signed?" is no longer enough. Three better questions:

Does the receipt certify the build environment — or the code's content? Ideally both, and you should know which you're looking at.
Where does the signing key live? "Short-lived token inside the runner" is fine until the runner is the target. Know your mode.
What watches the code after it runs? Signed packages can still be worms. Agents that install hooks into your editor doubly so.

Attestations got us from "trust me" to "trust the build." The next step is "trust the content — and verify it yourself."

We're Correctover — we build evidence infrastructure for the AI age: verifiable provenance for code and runtime assurance for agents. The birth-certificate tooling is open source (MIT); the transparency logs and DOI registry it uses are public infrastructure maintained by the Sigstore and Zenodo communities.

DEV Community: correctover

Hot Wallet Drains in 2026: The Question Nobody Asks

Hot Wallet Drains in 2026: The Question Nobody Asks About the $3.3B Lesson

The actual question

What a verifiable authorization layer looks like

Why this is a verification problem, not a monitoring problem

We Published the Largest Known Census of MCP Tools: 229,827 Parameter Schemas

We Published the Largest Known Census of MCP Tools: 229,827 Parameter Schemas

What's in it

Why parameter schemas matter

Use it

Honest limits

Where the Agent Can't Write: Signing Trust Boundaries for AI Agents

Where the Agent Can't Write: Signing Trust Boundaries for AI Agents

The problem

Threat model

Pattern 1 — Operator-signed scopes

Pattern 2 — Session grants as append-only receipts

Pattern 3 — Typed-once secret handles

Composition: a signed policy lattice

Failure modes (honest)

Closing

Auditing a Published CVE: A Six-Step Reproducibility Walkthrough

The claim under test

Step 1 — Pin the artifact, not the story

Step 2 — Pre-register the counters

Step 3 — Run the adversary model honestly

Step 4 — State the boundary before anyone asks

Step 5 — Compare against the known art

Step 6 — Ship the bundle, not the adjectives

What this is a demonstration of

After the Coldcard Entropy Disaster: How to Fingerprint a Wallet's Key Path in Three Steps

The uncomfortable precision

The three-step fingerprint

What "reproducible" means here

Why 40–72 bits is fatal, briefly

What we do

Your keys are weaker than your cryptography: CVE-2026-73567 and the dead RNG that seeded SM2 keys

The discovery

What happened next

This is a class, not an incident

What we do about it

Agent 安全不是单一赛道：三条技术边界的工程纪律

1. 三条边界

2. 入站内容防御：CAITLYN 的工程纪律

3. 供应链完整性：AgentSecCore 的边界

4. 出站执行验证：Correctover CCS 的边界

5. 三条边界之间的工程对话

6. 对 Correctover 自身的要求

7. 术语与事实锚点

Your agent sandbox is a physical exam, not a black box: dynamic analysis can't be the last word in agent security

What dynamic detonation gets right

Boundary 1: coverage is an arms race, not a one-time build

Boundary 2: slow and expensive — a deployment gate, not a runtime gate

Boundary 3: honeypot behavior is not production behavior

"OS-level logs can't be faked" — they can

What an agent black box actually looks like

Use both — they do different jobs

The exam does not replace the recorder

A PreToolUse security gate for Kimi Code: block live secrets, plaintext MCP, and SSRF before they hit disk

How Kimi Code hooks work (60-second version)

What the hook does

Test matrix: 8 scenarios, all behaving as expected

Install

The honest limits

Why this matters now

We scanned open-source finance MCP servers — here are the four ways API tokens leak

How we scanned

What the numbers look like

Pattern 1: The token goes out over plaintext HTTP

Pattern 2: The token gets logged to stdout

Pattern 3: Access-Control-Allow-Origin: * on a streamable-http transport

Pattern 4: The server binds to all interfaces with no Host allowlist

A pre-release checklist for MCP authors

Try it on your own MCP

Disclaimer

You can run a security scanner without shipping your source code anywhere

The constraint: the bytes must never leave the machine

How a CLI scanner becomes a browser scanner

Mapping to a standard instead of inventing one

Pattern 3: `Access-Control-Allow-Origin: *` on a streamable-http transport