If a tool covers most but not all of your AI risks, record each gap in a register with an owner, a compensating control and a review date, then decide on the whole. Every tool has gaps. A written gap with an owner is manageable, and an unwritten one is not.
Gaps are normal
AI-heavy stacks change quickly, and security products follow. A tool that handles libraries and pipelines well may not yet read model files. Another may see agent tools but not your dependency graph. Waiting for a perfect fit means waiting indefinitely.
The decision is therefore not "does it cover everything?" but "are the gaps acceptable, owned and watched?"
Build a gap register
For each gap, write one row.
| Gap | Risk if ignored | Compensating control | Owner | Review date |
|---|---|---|---|---|
| Model files not detected | Unknown model loaded in production | Approved model list, review in pull requests | ML lead | 90 days |
| Runtime tool changes not alerted | Unreviewed capability on a server | Pin server versions, review updates | Platform | 60 days |
| No export for past dates | Weak audit evidence | Monthly manual export to storage | Compliance | 30 days |
Keep the language plain. The register should be readable by an executive and usable by an engineer.
Choose compensating controls
A compensating control is a manual or process step that reduces the risk until the tool catches up. Good ones are cheap and visible.
- A list. An approved list of models and servers, with a rule that nothing outside it ships.
- A review step. A pull request check that asks whether the change adds a model, a server or a new agent permission.
- A pin. Fix versions of servers and models so changes are deliberate.
- A schedule. A monthly export or manual check, recorded.
The MCP specification tells clients to keep a human in the loop for sensitive operations. That is itself a compensating control you can lean on while automated checks mature.
Ask for dates, not promises
If a vendor says a feature is coming, ask for the date and put it in the register. If the date passes, review. Treat roadmap items as unavailable for scoring, which keeps comparisons fair. See how to keep a vendor claims ledger in the same spirit.
When to walk away
Walk away when a gap touches a Must requirement with no workable compensating control, or when the vendor will not state its limits. Do not walk away because the list of gaps is long. A vendor that lists gaps honestly is often more reliable than one that lists none.
Try it yourself
The vulnerability management demo shows a risk register style view of findings. Notice how each item carries status and ownership, and mirror that in your gap register.
Click through it at your own pace, or open it full screen.
Safeguard covers SBOM and dependency scanning, reachability, policies and gates, MCP Guardrail, agent identity, asset discovery and compliance evidence. If a gap matters to you, say so early and we will tell you whether it is covered. A free scan is at gold.safeguard.sh/scan.
Quick check
Who should own the gap register?
The security lead usually owns the register, while each gap has its own owner in the team that can close it.
How often should we review it?
Review monthly at first and move to quarterly when gaps stabilize. Review early if a vendor release or an incident changes the picture.
Sources
Last reviewed: 19 October 2026.