Source of truth: toolkit/gates/intake.md. Edit it there; this page is regenerated on build.
Gate: Dependency & AI-tool intake
Transition: proposed → allowed in the stack (radar entry + allowlist, one source of truth) Owner: Security + Engineering Runs: on demand — whenever anything new enters the stack: a library, an MCP server, an agent plugin, a model, a SaaS service
Purpose
One door into the stack. Agents pull dependencies confidently — including hallucinated packages, typosquats and MCP servers with unvetted data egress (supply-chain standard). This gate stops those at the door without becoming a queue: automated checks approve the easy ~90% in minutes; humans see only the flagged rest. The radar and the security allowlist are the same source of truth — approval here is the radar/allowlist entry.
Entry criteria
The gate may be run only once these are true:
- The candidate is named precisely — exact registry coordinates and version, model identifier, or vendor + product. No "something like X".
- A requesting squad and named owner exist, with a one-line intended use.
- It is genuinely new — not already on the radar in any ring (including hold: a hold item re-entering goes to the radar process, not this gate).
Exit criteria
The transition is approved only when all of these pass:
- Licence on the allowed-licence list; copyleft handled per policy.
- CVE scan — no unpatched critical/high vulnerabilities at the pinned version.
- Maintenance health — OpenSSF Scorecard at or above threshold; active releases and maintainers.
- Typosquat & provenance — name-distance check against popular packages passed; trusted registry; version pinned; signed artefacts / SLSA provenance verified where available.
- Data terms (models and SaaS only) — no-training terms, retention and residency acceptable; UK GDPR — insurance client data is in scope. Never automated; always a human check.
- Radar + allowlist updated in the approving PR — the entry lands in assess or trial; nothing enters adopt through this gate.
Evidence required
What must be attached / linked (and where it lives):
- Automated check report (licence, CVE, Scorecard, typosquat) — linked in the intake PR.
- For human-reviewed cases: the reviewer's note — what was checked, what was found, why approved or rejected.
- For AI tools with production reach: the tooling scorecard and golden-task harness results per the tooling-evaluation playbook.
Automated vs human
| Check | Automated in CI | Human sign-off |
|---|---|---|
| Licence vs allowed list | ✅ | — |
| CVE scan at pinned version | ✅ | Security, only if findings |
| Maintenance health (OpenSSF Scorecard) | ✅ | Engineering, only if below threshold |
| Typosquat / provenance / signing | ✅ | Security, only if flagged |
| Data terms (model / SaaS) | — | Security + Engineering |
| Production-reach AI tooling | harness run | Toolkit Guild (toolkit governance) |
All-green on the automated row set → auto-approved in minutes into assess/trial. Anything flagged, anything with data egress, and every model/SaaS goes to a human — target decision within one working day.
Sign-off & waiver
- Signs: automated approval on all-green; otherwise Security + Engineering. Data egress or production reach: the Toolkit Guild.
- May waive: Security may grant a time-boxed exception for a flagged item (logged in the security-exception register). No one may waive the typosquat/provenance checks — a package that fails identity checks does not enter the stack.
- Waiver record: time-boxed, named approver, expiry, logged in
toolkit/registers/.