Open source In progress

Chain Templar

A software acquisition policy engine for AI software factories.

  • Go
  • Policy engine

The problem

An AI software factory runs agents unattended, and those agents acquire software all the time: a package install, a script from npx, a tool dependency pulled in mid-task. With a human at the keyboard there is at least a chance someone asks “should this actually run?”. In a factory there is nobody. The check, if it happens at all, happens after the code has already executed, and the factory’s supply chain is whatever its agents happened to fetch.

What it does

Chain Templar decides, at the moment an agent tries to install or run third-party code, whether that agent may have it. It answers with one of four decisions, ALLOW · WARN · ASK · DENY, and every decision comes with the findings that produced it.

Three ideas carry it:

  • Advisories, kept locally. Known-bad intelligence from OSV, the OpenSSF Malicious Packages feed and GitHub’s malware advisories lives in one local advisory database, refreshed in the background. A decision never waits on the network.
  • Findings, not a score. Each check states one plain finding: a known-malware record, a vulnerability and its severity, a brand-new package, an install script, an unpinned source. There is no opaque trust score to argue with.
  • Policy as data. A declarative profile maps each finding to a decision. Switch to a stricter posture and the same findings produce stricter answers. Known malware is the one exception: always denied, whatever the profile.

How it works

How a policy decision is enforced

  1. 01InterceptAn agent's install or run request is caught before any third-party code executes.
  2. 02IdentifyThe request is resolved to an exact package identity. Anything unidentifiable is refused.
  3. 03CheckLocal advisories and acquisition-risk checks produce findings. Known malware stops here: deny.
  4. 04DecideThe active profile maps each finding to ALLOW, WARN, ASK or DENY, with the reasons attached.
Fail closed: a check that did not run is reported, never read as a pass, and ASK fails safe when nobody is there to answer.

The hard part

Known-malicious packages often carry no CVEs, so a decision engine that only scores vulnerability severity misses them. The design treats known malware as a hard deny regardless of CVSS score, and keeps vulnerability severity as a separate, profile-tunable signal. They are two different questions, answered independently, not one score standing in for both. In an unattended factory the ASK branch matters too: it has to fail safe when nobody is there to answer.

Where it stands

Work in progress, pre-v1.