Vaikora › Blog › Detection & SOC

AI Threats in MDR: How Security Teams Respond

Detection & SOC · June 30, 2026 · 11 min read

Managed detection and response (MDR) teams are now handling AI security incidents alongside traditional breach scenarios. AI security threats differ from network-based attacks: they originate inside AI systems and require detection signals from model inference, prompt chains, and decision logs that MDR platforms haven't historically ingested. MDR teams must build AI-aware playbooks that cover prompt injection, unauthorized data access through AI agents, and model behavior anomalies. The core challenge is standardizing evidence collection and decision telemetry across client AI stacks so that detection logic scales across tenants without rewriting rules per deployment.

What Is AI Security in the MDR Context?

AI security in managed detection and response covers threats that occur within or through AI systems: an attacker crafts a prompt to extract training data, a compromised third-party integration sends instructions through a language model to exfiltrate sensitive records, or an AI agent escalates to an unauthorized action because authorization checks were bypassed. These are not network layer attacks. They live inside model execution and agent logic.

For MDR teams, this means expanding the telemetry surface from infrastructure, endpoints, and cloud APIs into AI runtime decisions. An MDR provider that only monitors network traffic and endpoint logs will miss the moment an AI agent tries to read a production database it shouldn't have access to, or when a prompt injection silently extracts PII that was fed into the model's context window.

The OWASP LLM Top 10 (v1.1) and the MITRE ATLAS adversary tactics framework now define AI attack patterns that MDR teams need to recognize. MITRE ATLAS Technique A0201 (Prompt Injection) and A0001 (Craft Adversarial Data) are particularly relevant to detection logic. A managed SOC without AI detection telemetry is operationally blind to a growing attack surface.

The Detection Gap: Why Traditional MDR Misses AI Threats

Traditional MDR platforms collect logs from firewalls, EDR agents, cloud infrastructure, and identity systems. They excel at detecting lateral movement, privilege escalation, and data exfiltration through conventional channels. But an AI agent making an API call to read a database, or a language model returning user data in a chatbot response, looks like normal application traffic unless the MDR has visibility into the AI system's decision-making layer.

Consider a scenario: a client runs an AI-powered customer support chatbot. An attacker crafts a prompt that bypasses guardrails and instructs the model to return customer account numbers. The chatbot returns the data to the attacker's email address via the notification system. A traditional MDR sees an outbound email with customer data and flags it as data exfiltration. But without evidence from the AI layer, the MDR cannot determine whether the model was fooled by prompt injection, whether the guardrails failed to trigger, or whether the decision to email was a legitimate system feature. This ambiguity slows triage and response.

MDR teams need three new data sources to close this gap:

1. Decision logs from AI runtime enforcement: which actions did the AI system propose, which were approved or blocked, and with what confidence or risk score?
2. Prompt and inference telemetry: what input fed the model, and did the response reflect expected behavior patterns?
3. Agent action traces: when an AI agent makes an API call or accesses a resource, what authorization policy was applied, and did the decision align with the client's intent?

Building AI-Aware Playbooks for MDR Teams

An MDR playbook for AI security incidents must answer four questions at triage:

1. What did the AI system try to do (the proposed action)?
2. Was the action authorized, and by which policy?
3. What input or prompt led to this action?
4. Did the system's behavior deviate from baseline patterns?

To operationalize this, MDRs should establish intake procedures for client AI stacks:

Phase 1: Onboard AI runtime telemetry. Ask clients whether they run AI agents, language model endpoints, or agentic systems in scope. If yes, request access to decision logs, inference audit trails, and policy enforcement records. Many modern AI runtime platforms emit signed decision logs that record which actions were allowed or blocked, with evidence. This telemetry is machine-readable and queryable, so MDRs can build alerting rules across tenants.

Phase 2: Define baseline behavior. For each client's AI system, establish a baseline of normal actions: typical API endpoints accessed, expected data scopes, common prompt patterns. Deviations from baseline (an AI agent suddenly querying an unfamiliar database, or a high-confidence prompt injection attempt blocked) become alert triggers.

Phase 3: Map threats to client controls. Work with the client to understand their AI guardrails: what guardrails block unauthorized actions, which roles can approve agent escalations, and what constitutes a policy violation. This context is essential to triage alerts correctly.

Phase 4: Establish evidence collection workflows. When an AI security alert fires, the MDR should collect: (a) the full prompt or input that triggered the action, (b) the AI system's decision and justification, (c) the action that was proposed, (d) the policy that was applied, and (e) the outcome (allowed, blocked, constrained). This evidence trail is often missing in traditional incident response.

Investigation Workflow for AI Security Incidents

When an MDR receives an alert that an AI agent attempted unauthorized access or a model returned unexpected data, the investigation should follow this sequence:

1. Verify the alert source. Confirm that the alert originated from AI runtime logs, not from a false positive in the detection rule. AI systems are prone to benign high-risk actions (a model asking to read configuration during normal operation), so context matters.

2. Retrieve the full inference chain. Pull the complete interaction history: the prompt or input, intermediate reasoning steps if available, and the final action proposed by the model or agent. This reveals whether the AI system was manipulated (prompt injection) or misbehaved due to a logic error.

3. Check the authorization decision. Look up the policy that was applied. Was the AI system attempting an action that the policy explicitly disallows, or did the policy permit the action and the alert is a false positive? Authorization context is critical.

4. Assess the business impact. Did the proposed action execute, or was it blocked before reaching the backend? If it executed, what data or systems were affected? If blocked, the incident is a failed attack and should be categorized differently from a successful breach.

5. Determine the root cause. Classify the incident: prompt injection (attacker-controlled input manipulated the model), policy bypass (a guardrail failed to trigger), logic error (the model was trained to perform an unauthorized action), or social engineering (an authorized user prompted the system to exceed its intended scope).

6. Generate a decision log summary. Compile a report for the client that includes the attack timeline, evidence of the proposed action, the policy applied, and the outcome. This creates an audit trail for compliance requirements (SOC 2, ISO 27001, ISO 42001, HIPAA).

Detection Example: Sentinel Query for AI Agent Activity Anomalies

Here is a Kusto Query Language (KQL) example for Microsoft Sentinel that detects anomalies in AI agent behavior. This query assumes an MDR has onboarded a client's AI decision logs into a custom table:

let baseline_period = 14d;
let alert_period = 1d;
AIDecisionLogs
| where TimeGenerated > ago(baseline_period)
| where SystemType == "AIAgent"
| summarize
    BaselineActionCount = count(),
    UniqueResources = dcount(ResourceAccessed),
    UniqueRoles = dcount(ExecutingRole),
    BlockedCount = countif(Decision == "BLOCK")
  by AgentId, bin(TimeGenerated, 1h)
| join kind=inner (
    AIDecisionLogs
    | where TimeGenerated > ago(alert_period)
    | where SystemType == "AIAgent"
    | summarize
        CurrentActionCount = count(),
        CurrentBlockedCount = countif(Decision == "BLOCK"),
        ProposedResources = make_set(ResourceAccessed)
      by AgentId, bin(TimeGenerated, 1h)
  ) on AgentId, TimeGenerated
| where CurrentActionCount > (BaselineActionCount * 1.5)
  or CurrentBlockedCount > (BlockedCount * 2)
| project
    TimeGenerated,
    AgentId,
    BaselineActions = BaselineActionCount,
    CurrentActions = CurrentActionCount,
    BlockedAttempts = CurrentBlockedCount,
    AnomalyType = case(
      CurrentActionCount > (BaselineActionCount * 1.5), "Volume Spike",
      CurrentBlockedCount > (BlockedCount * 2), "Policy Violations",
      "Unknown"
    )
| sort by TimeGenerated desc

This query identifies hours when an AI agent suddenly escalates its action volume or triggers more policy blocks than usual. MDRs can tune the multipliers (1.5x, 2x) per client. The query is tenant-agnostic: by replacing AIDecisionLogs with a centralized table that ingests telemetry from multiple clients' AI systems, an MDR can scale this detection across its entire book of business.

Reporting and Evidence for Compliance

When an MDR reports an AI security incident to a client, the report should include the decision evidence. Many regulatory frameworks now require audit trails for AI system decisions:

• SOC 2 Type II: auditors expect evidence that controls were applied to AI systems and that unauthorized actions were blocked.
• ISO 27001: the information security policy must extend to AI assets, and decisions should be logged.
• ISO 42001: AI systems must be governed through a documented management system that includes decision logging and authorization controls.
• HIPAA: any AI system processing protected health information must have decision logs that show which access requests were approved and which were denied.
• PCI DSS: AI systems accessing payment card data must log decisions and prove that policy was enforced.
• GDPR Article 22: automated decision-making systems (including AI models) must provide transparency and accountability. Decision logs are essential evidence of compliance with rights regarding automated processing.
• SR 11-7 (NIST Cybersecurity Framework): supply chain risk management extends to third-party AI systems. MDR evidence collection supports client compliance with third-party SRM obligations.

An MDR that delivers AI decision logs as part of its report strengthens the client's compliance posture. Instead of saying "we detected an attempted data exfiltration," the MDR can say "we detected a prompt injection that attempted to extract customer data, the AI guardrail blocked the action with 99% confidence, and the decision is signed in our audit log with timestamp and evidence."

This evidence also protects the MDR itself. If the MDR fails to detect an AI-related breach, a customer claim of negligence is stronger if the MDR never ingested AI runtime telemetry. Conversely, if the MDR has ingested and monitored AI decision logs, it can demonstrate that it fulfilled its duty of care.

Scaling AI Detection Across Tenants

A key challenge for MDR providers is building detection rules that work across clients without per-client customization. AI systems vary: one client runs a customer-facing chatbot, another runs internal research agents, and a third uses AI for code generation. Each has different risk profiles and expected behavior.

The solution is to abstract the detection logic to common AI threat patterns rather than specific system behaviors. Instead of alerting on "AI agent reads Database X," alert on "AI agent reads a database outside its configured scope" or "AI system makes an authorization decision that contradicts its policy." This pattern-based approach scales across different AI architectures and client deployments.

Platform tooling that emits standardized decision telemetry supports this scaling. When an AI gateway and MCP server record decisions in a standardized format (the action proposed, the policy applied, the confidence or risk score, and the outcome), an MDR can build a single set of detection rules that apply across all clients using compatible AI runtime platforms, reducing operational overhead.

AI-Specific Triage and Escalation

Traditional MDR escalation is often based on severity and asset criticality: a critical host compromise escalates immediately, while a suspicious log entry on a non-critical server waits for batch review. AI incidents require different triage logic.

An AI system that proposed an unauthorized action but was blocked should still escalate, because it signals an attempted attack (prompt injection, policy bypass, or logic error) even though the breach was prevented. The MDR should triage based on:

1. Action severity: Did the AI system propose to access financial records, delete data, or send communications? Higher severity actions escalate faster.
2. Block confidence: Did the guardrail confidently block the action, or was it marginal? A blocked action with low confidence warrants investigation.
3. Attack pattern: Does the attempt match known prompt injection or jailbreak techniques (MITRE ATLAS Technique A0201 or similar)? If yes, escalate as a confirmed attack.
4. Frequency: Is this a one-off anomaly or a pattern? Repeated attempts to access the same unauthorized resource suggest a persistent attacker.

How Standardized Decision Telemetry Helps MDR Teams

Platforms that provide standardized decision telemetry allow MDR teams to ingest AI runtime signals directly. When an AI gateway and MCP server emit signed, auditable decision logs that record which actions were proposed, which policies were applied, and what the outcome was, this telemetry is machine-readable and queryable. MDRs can build detection rules that work across multiple clients without custom instrumentation per AI stack. Commercial platforms may add pre-built compliance presets (SOC 2, HIPAA, ISO 27001) and an approvals workflow for critical decisions, so MDRs can report AI incident evidence to customers with confidence.

Frequently asked questions

How do MDR teams handle AI threats?

MDR teams handle AI threats by ingesting telemetry from AI runtime systems, establishing baseline behavior patterns, and building detection rules that alert on unauthorized model actions, policy violations, and prompt injection attempts. Investigation workflows retrieve the full inference chain and authorization evidence to determine root cause and business impact. Evidence is collected into decision logs for compliance reporting.

What are the biggest AI threats for MDR providers?

The biggest AI threats are prompt injection (MITRE ATLAS A0201, attackers manipulating model behavior through crafted inputs), unauthorized data access via AI agents (models or agents extracting sensitive data), policy bypass (guardrails failing to trigger), and model logic errors (systems trained to perform unintended actions). MDRs struggle to detect these because they require visibility into AI runtime decisions, not just network and endpoint logs.

How do you investigate an AI security incident in MDR?

Investigation starts with retrieving the full inference chain (prompt, reasoning, action proposed), checking the authorization policy applied, and verifying whether the action executed or was blocked. Root cause is classified as prompt injection, policy bypass, logic error, or social engineering. Decision logs are collected as evidence for compliance and customer reporting.

Can managed security services protect against AI attacks?

Yes, but only if the MSP ingests AI runtime telemetry and builds AI-aware playbooks. Traditional network and endpoint monitoring is insufficient. MSPs must integrate AI decision logs, baseline agent behavior, and policy enforcement records to detect unauthorized model actions and prompt injection attempts before they breach the backend.

What data should MDRs collect from client AI systems?

MDRs should collect: decision logs recording which actions were proposed and whether they were allowed or blocked, inference audit trails showing the input and model output, policy enforcement records indicating which authorization rules were applied, and anomaly scores or confidence metrics. This telemetry enables triage, investigation, and compliance reporting.

How should an MDR report AI security incidents to customers?

MDR incident reports for AI threats should include the attack timeline, the full inference chain (prompt, model response), the authorization decision and policy applied, the outcome (blocked or executed), and the risk assessment. Signed decision logs provide auditability for compliance frameworks like SOC 2, ISO 27001, ISO 42001, and HIPAA.

More from the Vaikora blog