AI detection and response, AIDR, is the practice of watching AI systems for misuse, manipulation and abnormal behaviour, then acting on what you find. A sensible maturity path starts with an inventory, adds logging, then detection rules, and only later automated response with human approval.
Is AIDR a settled category?
No. The term is young, vendors define it differently, and no standards body has published a scale for it. What does exist is a set of risk catalogues that tell you what to watch for. MITRE ATLAS catalogues adversary tactics against AI systems, and OWASP publishes a Top 10 for LLM applications and a Top 10 for Agentic Applications. The model below is our own planning scale, not a standard, and you should adjust it to your systems.
Stage 0: Unknown
You cannot list the AI features, models, agents and plugins in use. Staff use public chat tools with company data. Nothing is logged.
Exit criterion: a written list of AI systems with an owner each. Without it nothing else in this article is possible.
Stage 1: Inventoried and logged
You know what exists. Prompts, tool calls and outputs from your own AI applications are logged somewhere you can search, with privacy rules applied. Access to model APIs is through managed credentials, not personal keys.
Measure: share of AI systems in the inventory that log tool calls, and share with a named owner.
A caution: logs of prompts can contain personal and confidential data. Decide retention and access before you switch logging on.
Stage 2: Detecting known patterns
You write or buy detections for patterns drawn from the catalogues above. Examples that apply to many applications: instructions hidden in content the model reads, outputs that include secrets, and an agent calling tools it never used before. OWASP names excessive functionality, excessive permissions and excessive autonomy as root causes of agent harm, so permissions and autonomy are natural things to monitor.
Measure: detections mapped to named risks, alerts per week per detection, and the share reviewed by a person within your target time.
Stage 3: Behavioural baselines
You know what normal looks like for each system: typical tools used, typical data volumes, typical hours. Deviations raise alerts. This is hard for non deterministic systems, so expect noise and tune in the open.
Measure: false positive rate per detection and how many were tuned or retired. Do not chase a zero false positive rate. A detection that never fires may not work.
Stage 4: Governed response
Response actions exist and are tested: revoke an agent's token, disable a tool, pause a workflow, route output to human review. Low risk actions can run automatically. Anything that changes customer outcomes needs an approver. Exercises are run on a schedule, using constructed scenarios.
Measure: time from detection to containment in exercises, and whether the rollback worked.
What stops teams moving up?
Ownership. AI features often sit between product, data and security teams, and detection needs someone who can say "pause this feature". Agree who has that authority before an incident, not during one.
Vendor claims also slow people down. If a product promises to detect "all AI attacks", ask which catalogued risks it covers, how it was tested and what it logs. The honest answer will be narrower than the claim.
How does this relate to software supply chain work?
Models, plugins and tool servers are software, and they arrive through the same channels as any dependency. A malicious or vulnerable plugin is a supply chain problem that shows up as AI behaviour. Keep the AI inventory linked to your software inventory so a flaw in a component tells you which AI systems carry it.
What to do
- Build the AI inventory and assign an owner for each entry.
- Decide what you log, for how long and who can read it.
- Pick five risks from the OWASP and ATLAS lists that match your systems, and write one detection each.
- Record the false positive rate for each detection and review it monthly.
- Write a one page response plan naming who can pause a feature.
- Run a constructed exercise once a quarter and fix what breaks.
Safeguard focuses on the application and software supply chain side, including MCP Guardrail for MCP servers, and does not replace a dedicated AI detection tool.
Quick check
Where should a team with no AI governance begin?
With the inventory. You cannot log, detect or respond to systems you cannot list, so name every AI system and its owner first.
Should AIDR responses be automatic?
Only for low risk, reversible actions. Keep a human approver for anything that changes customer outcomes, and test rollback in exercises.
Sources
- MITRE ATLAS
- OWASP LLM Top 10, Excessive Agency
- OWASP Top 10 for Agentic Applications for 2026
- NIST AI Risk Management Framework
Last reviewed: 18 October 2026.
