AIDR, AI detection and response, watches AI systems while they run: prompts, outputs and agent actions. Vulnerability and supply chain management covers what the AI system is built from and what it depends on. They meet at inventory, permissions, incident response and the pipeline. Plan them as one program.
What does each side own?
AIDR, a vendor term without a standard definition, usually means runtime monitoring and response for AI features: spotting manipulation, watching tool calls, blocking a session.
Vulnerability and supply chain management owns the build side: libraries, base images, model files, plugins, tool servers, pipelines and the flaws in each. The OWASP Top 10 for LLM applications contains both kinds of risk. Prompt injection and excessive agency are runtime risks. Supply chain and data and model poisoning are build time risks. A program that covers only one half leaves half of that list open.
Where do they meet?
Four joins.
Inventory. You need one list of AI components: models, agents, tool servers, datasets, prompts under version control, and the libraries around them. Runtime detection only protects what it knows about, and supply chain scanning only scans what it is pointed at.
Permissions. Runtime monitoring cannot undo a wide credential. Agent permissions are set at build and deploy time, so they belong in the same review as dependency policy.
Incidents. When detection flags an agent, the first questions are what it could reach and what it was running. That needs an agent identity record and a bill of materials for the service.
Pipeline. A change to a system prompt, a tool server or a model version is a release. It should pass the same gates as code.
A constructed example
This is a constructed example. A support assistant reads customer emails and can look up orders and issue refunds up to a limit. Runtime monitoring flags an email containing instructions aimed at the assistant. Because the assistant's credential allows refunds only up to the limit and larger ones need approval, the attempt does not cause loss. In review, the team finds the assistant's tool server uses an old library with a known flaw. The scanner had it listed but ranked low. After reachability analysis shows the vulnerable function handles the email parser, it moves to the top and is fixed that day.
Neither side alone would have given the full picture.
How should you organize ownership?
Give each side an owner but one shared backlog for AI systems. Hold a monthly review of three things: new AI components found, grants that were never used, and findings on AI related dependencies. Agree on shared severity terms so a runtime alert and a library finding about the same service land in the same ticket.
What should you not expect?
Do not expect runtime detection to catch every manipulated prompt. Do not expect a dependency scan to know what a model might say. Do not expect either to replace human review of high impact actions. NIST SP 800-61 Rev. 3 frames incident response as part of cybersecurity risk management, which supports treating these as one program.
Where Safeguard fits
Safeguard covers the build side and part of the control side: reachability analysis, policies and gates at build, CI and release, agent identity, and MCP Guardrail, a proxy for MCP servers. An AI Gateway or LLM firewall is early access only, and Safeguard does not claim to be a full AIDR platform.
What should you ask your existing vendors?
Ask your scanning and pipeline vendors whether they inventory AI components such as model files, prompt templates and tool servers, and whether their gates can apply to those artifacts. Ask your runtime and monitoring vendors whether their events can carry a service identifier that maps to a bill of materials. Often the gap is a naming and tagging problem, not a missing product. Agreeing on one service name across tools, tickets and logs makes the joins described above possible with the tools you already own.
What to do
- Build one inventory of AI components and the libraries around them.
- Review agent permissions at the same time as dependency policy.
- Treat prompt, tool and model changes as releases with gates.
- Share one backlog and severity scale for AI systems.
- Link runtime alerts to the service's bill of materials.
- Hold a monthly review of new components and unused grants.
Quick check
Does AIDR replace vulnerability scanning?
No. AIDR watches behavior at run time. Scanning finds weaknesses in the components and code before and after release. You need both.
Is a prompt change a release?
Treat it as one. It changes behavior, so it should be versioned, reviewed and gated like code.
Sources
Last reviewed: 18 October 2026.
