Where AIDR fits
Where AIDR fits among AI security controls
Different tools protect different layers. AIDR focuses on one: the tool calls an AI coding agent makes. It is meant to sit alongside the other layers, not replace them.
Layers and where AIDR applies
| Layer | Typical focus | AIDR |
|---|---|---|
| Prompt and response filtering | Screens text going to and from a model for injection, data leakage or policy violations. | Not its job. AIDR looks at the actions an agent tries to take, and the rule set includes prompt-injection patterns that can appear in tool arguments and tool output. |
| Model and ML pipeline scanning | Checks model files, notebooks and training pipelines for tampering and unsafe components. | Out of scope. AIDR does not scan models or training pipelines. |
| Output validation libraries | Enforces structure, schema and quality on what a model returns to an application. | Out of scope. This is a reliability concern rather than a threat-detection one. |
| Agent tool-call detection and response | Inspects commands, file operations, web requests and MCP calls an agent makes on a machine. | This is where AIDR sits. It evaluates a call before it runs, where the host provides a hook, and applies rules and policy. |
| Endpoint and network controls | Operating-system level monitoring, sandboxing and egress filtering that apply to every process. | Complementary. AIDR is not an endpoint agent, a sandbox or a network filter, and it cannot see actions that bypass the host hook. |
What this page does not claim
- It does not rank AIDR against named vendors, and it does not quote competitor pricing or funding.
- It does not claim that AIDR detects everything. Detection can miss attacks and can flag harmless actions, and efficacy has not been independently measured yet.
- It does not claim coverage for every host. See the per-connector limits.
Evaluating tools? Ask every vendor for their supported-host matrix, known bypasses and what has been independently tested. We will share ours in the trust center.