posts · 2026-07-20

The useful bit here is the timing: install scripts run before the agent produces any diff. Python setup.py, npm postinstall, Cargo build.rs all execute at install time, and the final diff only tracks repo file changes, not what those scripts already did. The authors built 12 scenarios across 5 attack types and tested 9 model–client combos. Obvious typosquatting was mostly caught. Separator tricks, extra registry URLs pointing to attacker-controlled sources, and known-vulnerable old versions often slipped through. Same model with a different client sometimes gave different results. The paper recommends pausing before install to inspect package name, source, and version, then running installs in a sandbox. No independent reproduction yet, and constructed scenarios don't prove real attacks are widespread. But the attack path doesn't require the agent to receive malicious instructions—installing dependencies is exactly what it's supposed to do.

This piece is useful because it splits the Agent Skills "unification" into two layers. The discovery layer is genuinely converging: Codex, Cursor, OpenCode, Gemini CLI, and the Antigravity family all scan `.agents/skills/`. Claude Code is the lone holdout—it only reads `.claude/skills/` and needs a symlink bridge. Anthropic launched the open standard, but its own client skips the shared directory. That's a bit odd. The execution layer is where things get messy. Claude Code has 14 private frontmatter fields—model, effort, hooks, disallowed-tools—that other clients ignore entirely. Gemini CLI asks for user confirmation before loading skill content. OpenCode requires the model to invoke a skill tool. Antigravity CLI just uses file tools. Working directories, tool names, and permission policies all diverge at runtime. If you want a single release-check skill to work across clients, the realistic path is: keep the core logic generic, then add thin adapters per harness. Format compatibility is step one. Runtime divergence is the real gap that still needs filling.

This piece walks through a full bug-fix task—clone, npm install, edit, test, push—and uses it to explain why approval gates, command blacklists, and dedicated tools each miss what happens after a command starts. The useful framing: risks come from three places (model mistakes, prompt injection from external content, and third-party dependency scripts), and OS isolation handles all of them by limiting file and network access at the process level, without needing to know which source caused the problem. Two things I'd flag. First, the distinction between "VM protects the host but not legitimate credentials" is well drawn: network policy controls destinations, credential proxying keeps raw tokens out of the sandbox, and external permission policy limits what a valid identity can do remotely. These three layers don't replace each other. Second, the article notes that workspace isolation lets you discard bad changes before they hit a shared branch—snapshots and git diff act as checkpoints, not security boundaries. No performance numbers or latency figures here; this isn't a benchmark. It reads more like a security map for developers who already click "allow in sandbox" daily in Cursor or Claude Code but haven't thought through why. Worth ten minutes if that's you.