An answer to the question the board is already asking
"What AI are we using and what have we sent it" is now a question with a real answer, derived from traffic rather than from a survey that is wrong the day it is collected.
SOC 2 Readiness
24/7 Security Monitoring
Canadian-Based SOC
GuardsArm Platform · Detect
AIDR — AI Detection & Response
Secure your organization's use of GenAI and LLMs.
Staff are using AI tools whether or not they are sanctioned, and the data they paste into them leaves your control. AIDR makes that usage visible and governable.
- Shadow-AI egress
- Process attribution
- Model integrity
What is at stake
Staff adopted generative AI faster than anyone governed it, and the organisation currently cannot say what has been sent where.
AI policy becomes enforceable instead of aspirational
You cannot enforce a policy you have no way of observing. Attribution to the originating process and user is what turns a document into a control.
Shadow AI surfaces before it becomes a disclosure
Source code, customer records and contract drafts leaving for a service with its own retention terms is a data-protection event. Seeing it early is the difference between a conversation and a notification obligation.
Who carries this
Usually initiated by legal or risk rather than the SOC, and frequently the module that gets the platform its executive sponsor.
The problem
Your organisation adopted AI faster than it governed it
Generative AI entered most organisations through individual initiative rather than procurement. People pasted work into assistants because it helped, teams wired APIs into internal services because it was quick, and model files arrived on build hosts as dependencies. Very little of this went past a security review, because very little of it looked like a project.
The exposure is straightforward and mostly not malicious: source code, customer records, incident detail and draft contracts leaving the perimeter to a service with its own retention and training terms. The access-control questions your organisation answers carefully for a SaaS vendor were, in this case, never asked.
Blocking is a weak answer, both because it is trivially routed around and because the usage is often legitimate. What is missing first is visibility with attribution — not that AI traffic exists, but which process on which host, run by whom, produced it.
You cannot write an AI policy you have no way of observing. Enforcement without visibility is a document, not a control.
Capabilities
What AIDR covers
Shadow-AI egress detection
Unsanctioned AI traffic is detected and attributed to the initiating process, so you can see which application on which host is sending data to an AI service.
AI supply-chain risk
Surfaces risk introduced through the AI components and dependencies your own systems pull in.
LLM API-call monitoring
Calls to language model APIs are monitored and surfaced as events in the console alongside the rest of your telemetry.
Model-file integrity
Integrity monitoring for model files, so an altered or substituted model does not go unnoticed.
How it fits the platform
AIDR findings are ordinary alerts and events in the same console, which means shadow-AI usage correlates with identity and endpoint activity rather than sitting in a separate tool nobody opens.
How it works
Four steps, and nothing new to deploy
AIDR reads telemetry the endpoint agent is already collecting. There is no separate sensor, proxy or inline appliance.
The agent sees the connection and the process
Endpoint telemetry already records network activity with the originating process attached. AIDR reads that stream rather than needing its own sensor, which is why there is nothing additional to deploy.
AI destinations and artefacts are identified
Egress to AI services is recognised, and model files and AI dependencies are tracked where they land on disk. File integrity monitoring supplies the change signal for the artefacts.
Findings are raised as ordinary alerts
AIDR output enters the same pipeline as every other detection — same severity scale, same console, same queue. There is no separate AI-security inbox to remember to check.
Correlation does the rest
Because the findings are ordinary findings, they correlate with identity and endpoint activity. Which user, on which host, under what privilege, is a join rather than a research project.
Coverage
The four surfaces AIDR watches
GenAI risk is not one problem. These are the four distinct ones the module addresses.
Shadow-AI egress
Unsanctioned AI traffic leaving the estate, attributed to the process that initiated it. Attribution is the hard part and the useful part: knowing that traffic went to an AI endpoint is a netflow observation, while knowing which binary on which host sent it is an investigation.
AI supply-chain risk
The model files, packages and dependencies pulled into your environment to run AI workloads. This is a software supply chain like any other, with the difference that the artefacts are large, opaque and frequently fetched from community hubs.
LLM API-call monitoring
Visibility into the calls your sanctioned AI integrations are making. Approved usage still needs a record — of volume, of which service, and of which internal system is driving it.
Model-file integrity
Monitoring the model artefacts themselves for change. A silently swapped model file is a supply-chain compromise whose output looks entirely normal until someone checks.
In practice
What a finding looks like
Each of these is an ordinary alert in the ordinary queue, carrying the ordinary severity band.
- An unsanctioned AI service reached from a finance workstationA shadow-AI finding naming the process and the user — the starting point for a data-handling conversation rather than a blocked domain nobody can explain.
- A model file changed outside a deploymentAn integrity finding through FIM. The artefact that produces your output changed, and nobody raised a change request.
- A build host pulling AI dependencies from an unexpected sourceA supply-chain finding, correlated with the process ancestry that initiated the fetch.
- A sudden rise in LLM API calls from one internal serviceA monitoring signal with attribution attached — which matters as much for cost and data exposure as it does for security.
Posture
The questions an AI governance review asks
Most organisations can answer these about their SaaS estate and not about their AI usage.
| The question | Without AIDR | With AIDR |
|---|---|---|
| Which AI services are in use here? | Answered by survey, and the survey is wrong. | Answered from egress telemetry, with the initiating process named. |
| Who is sending what to them? | Not answerable without a proxy that sees inside TLS. | The host, the process and the user are on the finding. |
| Have our model artefacts changed? | Only if someone checks a hash by hand. | File integrity monitoring raises it when it happens. |
| Does AI usage show up in an investigation? | Only if the investigator thinks to look in a separate tool. | It is in the same alert queue and correlates automatically. |
Background
Understand the concept first
Plain explainers on the underlying ideas, written for someone evaluating rather than buying.
Questions
Common questions
Can it tell which application sent data to an AI service?
Yes. Shadow-AI egress is attributed to the initiating process, so you can see which application on which host is sending data out rather than only that traffic occurred.
Is this a separate console our team has to watch?
No. AIDR findings are ordinary alerts and events in the same console, so shadow-AI usage correlates with identity and endpoint activity rather than sitting in a tool nobody opens.
Does blocking AI tools work?
Rarely. A ban usually moves the usage to personal accounts and personal devices, where there is no visibility at all. Making the usage visible and governable is the more controllable position.
Works with
The modules next to this one
Every module runs in the same self-hosted stack and shares the same telemetry, severity model and response engine.
ITDR — Identity Threat Detection & Response
Detect identity-based attacks across your directories and cloud identities.
ExploreXDR — Detection & Correlation
Turn raw events into severity-graded, ATT&CK-mapped alerts — then connect them into real attacks.
ExploreCompliance
Map every event to the frameworks your auditors care about.
ExploreSee AIDR running on your own infrastructure
We will walk through the console, the deployment model and what it takes to stand it up in your environment.
24/7 SOC Monitoring Available