Source Map Leakage and Supply Chain Security for AI Coding Tools

1. Incident recap: what a 59 MB map file revealed

Security researchers found an approximately 59.8 MB cli.js.map file inside an npm package for an AI coding tool. The file used the standard Source Map v3 format. Its sourcesContent field held thousands of source files and tens of megabytes of unobfuscated TypeScript. Core implementation details became public overnight: the permission system, multi-agent orchestration, and unpublished internal feature codenames.

This was not the first time. About a year earlier, when the tool was still in preview, developers found a similar file in its dependency tree. The vendor’s response then was to delete the Source Map and unpublish old versions from npm. A year later, the version number had multiplied and features had grown, but Source Map cleanup in the build pipeline was still not institutionalized. The same accident repeated at larger scale. The leaked file attracted attention and copies on code-hosting platforms, and the vendor had to unpublish again.

The case is worth studying because it was not an advanced attack. It was an inconspicuous default in the build configuration.

2. How Source Maps become a leak source

Source Maps are a common debug mapping mechanism in frontend and Node.js ecosystems. After TypeScript is bundled, minified, and obfuscated into a single release file, debugging degrades. A Source Map JSON file maps generated-code locations back to original source:

{
  "version": 3,
  "file": "cli.js",
  "sources": ["src/repl.tsx", "src/coordinator/index.ts"],
  "sourcesContent": ["// full original source text..."],
  "mappings": "AAAA,SAAS..."
}

The critical field is sourcesContent. It can carry the full original text of source files. Even if the published artifact is minified and obfuscated, shipping the map lets an attacker read original, commented, well-structured source with no reverse engineering.

Toolchain defaults increase the risk. Many bundlers still emit source maps in production. If --sourcemap-style options are not explicitly disabled or cleaned up, maps land in the published package. That was the technical root cause: a debug artifact that should exist only in internal environments was carried into a public npm package by the build script.

3. Impact: more than just code

For traditional closed-source software, a source leak is mainly an IP loss. For AI agent tools, the blast radius is wider:

1. Prompts and system logic are exposed. The core asset of an agent tool is often not the algorithm, but system prompts, tool-calling strategy, and orchestration. Once public, competitors can copy product “feel” at low cost.

2. Security boundaries become transparent. The leaked source included a full permission-decision pipeline—from the order of more than ten checkpoints to field definitions on tool interfaces. Attackers can look for bypasses precisely instead of black-box trial and error.

3. Internal codenames and unreleased features leak. Source contained unpublished project codenames and experimental modules (for example voice interaction and conditional activation of a skills system). That is “leaked before launch” and can disrupt release plans.

4. Build-time dead code can be recovered. Feature-flag-gated code was evaluated at compile time and removed by dead-code elimination, so it did not exist in the external artifact—but it still leaked via sourcesContent. Source maps record a pre-compile view of source. Assuming “build-time stripping protects sensitive code” does not hold if maps ship.

4. Engineering practice: how to avoid repeating this

Any team that publishes npm packages, CLIs, or frontend artifacts should put these checks in CI/CD gates:

1. Split source-map policy by environment. For production builds, disable source maps or strip them down (for example keep only mappings, drop sourcesContent). Upload debug artifacts only to internal monitoring with access control.

2. Scan artifacts before publish. In the publish pipeline, scan for .map files, //# sourceMappingURL comments, and unusually large files. A minimal script:

# pre-publish scan example
if find ./dist -name "*.map" | grep -q .; then
  echo "ERROR: source map files found in dist"; exit 1
fi
grep -rn "sourceMappingURL" ./dist && exit 1

3. Govern .npmignore / files with a whitelist. Prefer the files field in package.json as a whitelist, not blacklist ignore rules, so debug artifacts cannot slip in.

4. Classify sensitive content. System prompts, internal codenames, and unreleased feature code should be injected at build time or kept in private packages, not left in a source tree that enters the release path.

5. Have an incident playbook. Unpublishing and cache clearing from this event are useful, but npm immutability means already-downloaded old versions cannot be truly recalled. Response should focus on assessing leaked content and hardening security boundaries, not on imagining the leak can be “deleted.”

5. Conclusion

The essence of this incident is a CI rule that should have existed and was ignored. Supply-chain security often is not about defeating advanced attacks, but about systematically reviewing what default configuration might leak. For any team that ships binaries or minified artifacts—regardless of product size—Source Map governance should be a hard rule in the release pipeline, not a one-off fix after each accident.