Skip to main content

Overview

Agent On-Queue for Defender XDR allows ContraForce Security Delivery Agents to automatically detect and respond to incidents originating directly from Microsoft Defender XDR with no Microsoft Sentinel forwarding required. Previously, agents could only auto-trigger on incidents ingested through Sentinel. Customers using Defender XDR directly had to manually trigger agent actions. With this update, ContraForce polls Defender XDR for new incidents approximately every 2 minutes, automatically triggering your agent to triage and respond in order to deliver the autonomous SOC experience with minimal time-to-respond.
If your environment already forwards Defender XDR incidents to Microsoft Sentinel (FetchToSentinel = true), your existing agent workflow is unaffected. This feature is designed for environments where Sentinel forwarding is not configured.

How It Works

ContraForce continuously polls the Microsoft Defender XDR security API for new incidents across all eligible customer accounts. When a new incident is detected:
  1. The platform identifies the incident and checks it against previously processed incidents to prevent duplicates.
  2. A notification is queued for processing.
  3. ContraForce validates that the account has a deployed agent with the appropriate severity capability for the incident.
  4. The agent is automatically triggered on-queue to investigate and respond — just as it would for Sentinel-ingested incidents.
The entire pipeline runs automatically. No manual intervention is required once configured.

Prerequisites

Before Agent On-Queue for Defender XDR can activate for a workspace, all of the following must be true:
1

Active Subscription

The account must have an Active or Trial ContraForce subscription.
2

Defender XDR Module Enabled

The Defender XDR security provider must be enabled for the workspace. See Defender XDR Module Deployment for setup instructions.
3

Partner Consent Granted

Microsoft Defender partner consent must be granted during onboarding. This is the same consent flow completed when deploying the XDR module.
4

Sentinel Forwarding Disabled

The workspace must not be configured to forward Defender XDR incidents to Sentinel. If FetchToSentinel is enabled, incidents are ingested through the existing Sentinel pipeline instead.
5

Agent Deployed with ProcessIncident Capability

A Security Delivery Agent must be deployed via Agent Center with the ProcessIncident capability enabled for the target incident severity levels (High, Medium, Low, Informational).
Not sure if your workspace meets these requirements? Navigate to Agent Center in the ContraForce portal and verify your agent’s status shows On Queue. If the agent is deployed but not processing Defender XDR incidents, review the prerequisites above.

What Changes for You

If you use Defender XDR without Sentinel

This is the feature for you. Once the prerequisites are met, your agent will begin automatically processing Defender XDR incidents within approximately 2 minutes of their creation. No configuration changes are needed on your end — the platform handles everything.

If you already forward to Sentinel

Nothing changes. Your incidents continue to flow through the Sentinel ingestion pipeline as before. The Defender XDR polling pipeline automatically excludes accounts with Sentinel forwarding enabled.

If you use both

Accounts are evaluated individually. Workspaces with Sentinel forwarding enabled use the Sentinel pipeline. Workspaces without Sentinel forwarding use the new Defender XDR polling pipeline. There is no overlap or duplicate processing.

Configuring Your Agent for Defender XDR Incidents

If you already have a Security Delivery Agent deployed and configured, no additional setup is required. The platform automatically detects eligible workspaces and begins polling. To deploy or configure an agent:
  1. Navigate to Agent Center from the left navigation menu.
  2. Deploy your agent following the Agent Center Deployment guide.
  3. Configure the agent’s ProcessIncident capability and select which severity levels the agent should handle automatically.
  4. Set the agent mode to On Queue.
Once the agent is on-queue with ProcessIncident enabled, ContraForce will begin polling Defender XDR and triggering the agent for matching incidents.
For a phased rollout, start with the agent in Manual mode where the agent suggests actions and you approve. Once you’re confident in the response quality, move to Automatic or Full Autonomous mode. See Configuring Security Delivery Agents for details on agent modes.

Verifying It’s Working

After setup, confirm that the pipeline is active:
  1. Check Agent Center — Verify your agent status shows On Queue and the mode is set to your preferred level (Manual, Automatic, or Autonomous).
  2. Monitor the Command Dashboard — New Defender XDR incidents should appear on the Command Dashboard within approximately 2 minutes of creation in Defender.
  3. Review Gamebook Activity — When the agent processes an incident, you’ll see corresponding Gamebook activity in the Gamebook Activity widgets and the incident’s Workbench.
  4. Check Agent Execution History — Navigate to Agent Center to review the agent’s execution history and confirm incidents are being processed.

Incident Detection Timing

ContraForce polls Defender XDR approximately every 2 minutes. This means:
  • New incidents are typically detected within 2 minutes of appearing in Defender XDR.
  • The agent is triggered immediately after detection and validation.
  • End-to-end time from incident creation to agent response initiation is typically under 5 minutes.

Troubleshooting

IssueLikely CauseResolution
Agent not processing Defender XDR incidentsAgent not set to “On Queue” modeNavigate to Agent Center and set the agent mode to On Queue
Incidents not appearing from Defender XDRPartner consent not grantedRe-run the consent flow from Workspace Settings → Module Configuration with Global Admin credentials
Duplicate incidents appearingSentinel forwarding is also enabledVerify the workspace is not forwarding Defender XDR incidents to Sentinel. Only one ingestion path should be active
Agent triggers for wrong severity levelsProcessIncident capability misconfiguredReview the agent’s severity capability settings in Agent Center and adjust which severity levels are handled
No incidents detected despite active Defender XDR incidentsAccount eligibility not metVerify all prerequisites are satisfied — subscription status, module enablement, partner consent, and agent deployment
Agent was working but stopped processingSubscription lapsed or consent revokedConfirm subscription is still Active/Trial and re-authorize partner consent if needed
If the issue persists after reviewing the above, contact support@contraforce.com with:
  • Workspace name
  • Agent status screenshot from Agent Center
  • Approximate timestamp of the incident that was not processed
  • Any error messages visible in the portal

Frequently Asked Questions

Do I need to change anything if I’m already using Sentinel? No. If your workspace forwards Defender XDR incidents to Sentinel, your existing pipeline continues to work. The Defender XDR polling pipeline automatically skips your account. Can I use both Sentinel and direct Defender XDR ingestion for the same workspace? No. Each workspace uses one ingestion path. If Sentinel forwarding is enabled, incidents come through Sentinel. If it’s disabled, incidents come through the Defender XDR polling pipeline. This prevents duplicate processing. What response actions are available for Defender XDR incidents? The same Gamebook response actions available for any incident — device isolation, account disabling, password resets, IP/URL blocking, file quarantine, email deletion, and more. See the Microsoft Defender Capability Matrix for the full list based on your license. Is there any additional cost for this feature? No. Agent On-Queue for Defender XDR is included with your existing ContraForce subscription and agent deployment. No additional modules or licenses are required beyond the standard XDR module and Agent Center. What happens if the polling service restarts? Polling state is persisted per account. If the service restarts, it resumes from the last known position with a configurable overlap window to ensure no incidents are missed.