AIDR, often searched as "soar for AI incidents," gives security operations centres endpoint-level discovery, runtime detection and containment purpose-built for AI agents and copilots. Analysts get visibility into prompt injection, agent exfiltration and autonomous agent takeovers before data leaves the device. Tools like Alectura package this as SOC-ready runbooks that plug into existing SIEM and SOAR workflows, so containment doesn't wait on a bespoke build.
TL;DR:
- AI incidents often involve prompt injection, one-click exfiltration, persistent autonomous agents, and malicious code execution that evade traditional detection methods.
- Detection should focus on the user's prompt, pre-execution tool requests, and tool responses, with initial audit mode recommended before switching to blocking.
- Incident response requires immediate containment, evidence collection, and credential revocation, followed by remediation steps like rotating tokens and patching vulnerabilities.
- Managing AI agents as non-human identities involves issuing short-lived tokens, maintaining a central registry, and enforcing strict access policies based on technical controls.
- Piloting detection systems with high-risk workflows using SIEM and SOAR integration is crucial to keep pace with agent proliferation and prevent major security incidents.
Table of Contents
- AI incident types and attack patterns every SOC must recognise
- Where to detect AI incidents: inspection points and telemetry
- SOC runbook: responding to an AI incident step by step
- Governing AI agents as non-human identities
- How to pilot AIDR and connect it to SIEM and SOAR
- Why security leaders can't wait on this
- Run an AIDR pilot with Alectura's SOC runbooks
- Sources
AI incident types and attack patterns every SOC must recognise
AI incidents don't look like traditional malware alerts, which is exactly why they slip past existing detection logic. Four patterns dominate what analysts are seeing now.
Prompt injection hides malicious instructions inside content an agent reads, a webpage, an email, a shared document, and hijacks the agent's next action. A demonstrated Copilot exploit used an undocumented autorun parameter to execute injected prompts the moment a victim clicked a crafted link, exfiltrating sensitive data with no malware download and no obvious file event.
One-click exfiltration follows the same logic: a single click grants an agent broad access, and it acts on that access instantly.
Persistent autonomous agents are the pattern security leaders underrate most. AgentForger research showed a phishing-style trigger can spawn an agent with standing access to Outlook, Slack and Drive, doing reconnaissance and exfiltration on a schedule, long after the initial click.
Malicious code execution happens when an agent with coding permissions is tricked into inserting a harmful snippet into a build pipeline or script.
Red flags worth training analysts on:
- Tool calls requesting scopes wider than the agent's stated task
- Outbound connections to domains never seen in that agent's history
- Agent activity triggered by a scheduled job with no corresponding user session
- Sudden spikes in file reads across sensitive folders shortly after a link click or document open
Model-level guardrails alone won't stop this. Adaptive prompt-injection research has shown these attacks can succeed against leading LLMs even after mitigations are applied, which is why runtime detection has to sit outside the model itself.
Where to detect AI incidents: inspection points and telemetry
Detection works when you inspect the right layer, and there are exactly three that matter for agent runtime.
- The user's prompt. Catches attempts to jailbreak the agent or smuggle in malicious instructions before the agent even acts.
- The pre-execution tool request. This is the moment an agent asks to call a tool, an API, a file write, a send command, and it's the best point to block a dangerous action before it happens.
- The tool's response. Injected content often arrives here, hidden inside a returned document, webpage or email that the agent then treats as trusted instruction.
Microsoft's Defender guidance recommends starting all three inspection points in audit mode, then moving to block once false positives are tuned out. Jumping straight to block mode on day one is the fastest way to break a legitimate workflow and lose SOC buy-in.
Coverage gets harder once agents run outside a single vendor's telemetry. Local agents, MCP servers and cloud-platform agents each need their own discovery approach, and where an agent doesn't expose a native event interface, network inspection fills the gap by watching the traffic instead of the process.
Pro Tip: Don't treat MCP server traffic as "just another API call." MCP flows carry the tool calls and responses agents act on directly, so losing visibility there means losing the exact layer where injected instructions actually land.
Telemetry to capture and correlate:
- Full prompt and response text, not just metadata
- Tool call parameters and destination endpoints
- MCP session flows, including which server serviced which request
- Process-level events tied to the agent's host
- Ephemeral token issuance and revocation events
SOC runbook: responding to an AI incident step by step
Once an AI-related alert is confirmed as an incident, speed matters more than precision. Here's the order that limits blast radius fastest.
Contain immediately:
- Isolate the affected device from the network.
- Block the agent's outbound tool calls at the network or middleware layer.
- Revoke any credentials or tokens the agent was holding.
- Flip the agent from block mode back to audit only if you need it live for evidence capture, otherwise kill it outright.
Capture evidence before anything gets cleaned up:
- Preserve the full prompt and response chain, not a summary of it
- Log the complete tool call sequence, including MCP and cloud-platform requests
- Pull identity provider logs showing what the agent's token was scoped to do
- Screenshot or export any injected content (the webpage, email, or document) that triggered the behaviour
Escalate to a full incident when the agent accessed data outside its documented scope, when credentials were used from an unfamiliar location, or when the injected payload matches a known campaign pattern.
Remediate and recover:
- Rotate every secret and token the agent could have touched, not just the one flagged.
- Remove or patch the vulnerable agent integration before restoring access.
- Update the policy that let the incident through, whether that's a scope restriction, a new block rule, or a tighter trigger condition.
- Rebuild the endpoint from a known-good image if there's any sign of persistence beyond the agent itself.
After the dust settles: Run a proper root cause review, feed the indicators into your threat-hunting queue, and update the runbook itself with what this incident taught you. A SOC-ready runbook template built specifically for AI incidents saves the rebuild-from-scratch problem most teams hit on their first real case.
Governing AI agents as non-human identities
Agents that hold standing credentials are the single biggest reason incidents escalate past a single endpoint. The fix is treating every agent as a non-human identity (NHI), not a trusted user.
Issue short-lived, narrowly scoped tokens through just-in-time provisioning, and revoke them the moment a task completes rather than letting them sit active between runs. NHI Management Group's guidance treats this the same way privileged automation has always been governed: per-task credentials and tamper-evident audit chains, not standing access.
- Keep a central registry of every agent, its owner, its permissions, its triggers and its current approval status
- Run access reviews on that registry on a fixed schedule, not only when something breaks
- Enforce policy as code with fail-closed gates, so an agent requesting an unapproved action gets blocked by default, not waved through
- Build in a circuit breaker that can disable an agent's triggers instantly without touching the rest of the environment
This lines up with both OWASP's agentic AI guidance and the NIST AI Risk Management Framework, both of which push toward registries and evaluation gates over policy documents alone.
Pro Tip: Define an agent's scope of authority as a technical control, not an HR policy. A Thoughtworks framework argues security teams need an attack-path lens here, asking what an agent could reach, not just what it's permitted to do on paper.

How to pilot AIDR and connect it to SIEM and SOAR
A pilot succeeds or fails on scope. Pick one high-risk workflow, an agent with broad file access or email integration works well, and run it for a fixed window against clear criteria.
Set success criteria before you start. Set success criteria before you start, such as achieving high coverage of AI tools discovered compared to manual inventories. Measure the detection rate against known injection and exfiltration patterns to evaluate effectiveness. Track the time taken from alert to device isolation to assess containment speed. Determine an acceptable false-positive rate to guide the transition from audit to block mode.
Integration checklist:
- SIEM ingestion for prompt, tool call and MCP telemetry
- SOAR playbooks that trigger isolation and token revocation automatically on confirmed detections
- Identity provider hooks so revocation happens at the source, not just at the endpoint
- DLP rules covering prompt and response content, not just file transfers
Operational readiness matters as much as the tooling. Map every alert type to a ticket category before go-live, train the SOC on the three inspection points, and report pilot KPIs weekly rather than waiting for a quarterly review. Teams that skip the inventory-first step consistently underestimate how many agents are already running unmanaged.
Why security leaders can't wait on this
Agent proliferation is outpacing every inventory security teams currently run, and the incidents already documented, Copilot's exfiltration flaw, AgentForger's persistent agents, aren't edge cases. If you do nothing else this quarter, build the inventory, move standing credentials to short-lived tokens, and pilot detection on your single highest-risk agent workflow. The teams that wait for a bigger incident to justify the work will be doing this under worse conditions.
— Nathan
Run an AIDR pilot with Alectura's SOC runbooks
Alectura gives your SOC the exact detection layer this guide describes, built in rather than bolted on. It discovers every AI tool running across your fleet, inventories what each one can access, watches MCP and integration traffic for the exfiltration patterns covered above, and enforces policy at the same three inspection points: prompt, tool request, tool response. Containment and credential revocation plug straight into your existing SIEM and SOAR stack, so the runbook you just read isn't a manual process bolted onto separate tools.

If you're weighing up where to start, the AI security glossary covers the terms this guide leaned on, shadow AI, MCP, prompt injection, AIDR itself, and links through to a pilot checklist you can run against your first high-risk agent workflow this month.
Sources
- Governing agentic scope and authority - Thoughtworks
- AI agent runtime protection overview - Microsoft Learn
- Microsoft Copilot reveals secret input that allowed it to be hacked | Ars Technica
- AgentForger proves AI agents can become persistent insider threats | CSO Online
