Zero-Dependency AI Safety Tools: Why Minimizing Dependencies Matters

When we built Aegis (content safety scanner) and Sentinel (behavioral monitor), we made them zero-dependency packages. No npm packages. No runtime libraries. Just TypeScript compiled to JavaScript. Here is why.

The Supply Chain Argument

Every dependency you add is code you trust but did not write. In a typical Node.js project, installing one package pulls in dozens of transitive dependencies. Each is maintained by someone you have never met, hosted on infrastructure you do not control, and subject to compromise through stolen credentials, social engineering, or abandoned maintenance.

For most application code, this tradeoff is acceptable. For security tooling, it is not. Your safety scanner is the tool that is supposed to catch attacks. If the scanner itself is compromised through a supply chain attack, the entire security model collapses.

Real Supply Chain Incidents

This is not theoretical:

• event-stream (2018): A popular npm package was transferred to a new maintainer who injected malicious code that stole cryptocurrency.
• ua-parser-js (2021): A widely-used package was compromised through a stolen npm token, delivering cryptomining malware.
• colors.js (2022): The maintainer deliberately corrupted their own package, breaking thousands of downstream projects.

These incidents affected general-purpose libraries. Now imagine this happening to a library in your security scanner's dependency tree.

What Zero-Dependency Means in Practice

Aegis implements pattern matching, statistical analysis, and scoring without importing any packages. String operations, regex, hash computations, and statistical functions are implemented directly. The total code footprint is small enough to audit manually.

Sentinel implements EWMA, CUSUM, and behavioral profiling algorithms from scratch. These are straightforward statistical computations that do not need external libraries.

The engine (policy evaluation) is also zero-dependency. Policy rules are evaluated with pure logic. No template engines, no query parsers, no external evaluators.

Tradeoffs

Zero-dependency does not mean zero effort. You write and maintain code that a library would provide. This is more engineering work upfront.

It also means you do not get community-maintained improvements. When a library fixes a bug or adds a feature, you do not benefit automatically.

The tradeoff is worth it for security-critical code. For everything else (HTTP servers, database drivers, framework adapters), dependencies are fine. The boundary is: code that makes trust decisions should have minimal external trust dependencies.

The Audit Benefit

A zero-dependency package can be audited. A human can read the entire codebase, understand every line, and verify that it does what it claims. This is practically impossible for packages with deep dependency trees.

For compliance-sensitive deployments (EU AI Act, SOC 2), the ability to demonstrate that your safety tooling has been audited and contains no unexpected code is valuable.

Build your security tools with the minimum dependencies that make engineering sense. For pattern matching and statistical algorithms, that minimum is zero.