Contain endpoint threats with approval-aware response control.
XDRShield helps teams request, approve, execute, verify, and review supported response actions without losing the endpoint, tenant, case, reason, result, or audit context behind the decision.
Response actions need speed, control, and a verifiable record.
Containment decisions are high-impact. XDRShield keeps supported actions tied to evidence, permissions, approvals, reasons, execution state, retries, results, and action history so responders can act without turning urgent work into unmanaged risk.
Move from investigation confidence to controlled endpoint action.
XDRShield response workflows are designed for teams that need to act on confirmed endpoint risk while preserving accountability. Analysts can connect alert, hunt, case, endpoint, process, IOC, URL, AV, policy, and tenant context before choosing a supported action.
- Confirm the affected tenant, endpoint, user, process, IOC, or policy context before acting.
- Capture a reason and route the request through approval when required.
- Monitor agent execution, error state, retry behavior, result, and action history.
- Use case and timeline context to keep containment, remediation, and closure connected.
What XDRShield helps response teams control.
Supported actions are handled as governed operational workflows, not isolated button clicks. Each card below reflects the response and enforcement context that teams can use when endpoint risk is confirmed.
Host isolation
Request isolation of a supported endpoint while preserving the controlled management path needed to review status and continue follow-up.
Host release
Reverse a prior isolation action through an accountable release workflow after investigation, containment, or remediation conditions are met.
Process termination
Request termination by supported process name or PID where endpoint support, permissions, and risk controls allow that action.
User disablement
Use supported user disablement workflows when account activity or endpoint context indicates a contained access decision is required.
IOC blocking
Send approved indicator enforcement actions to capable agents and retain result context for observed, monitored, or blocked indicators.
Approval workflow
Separate action request, review, approval or rejection, execution, and result reporting so high-impact work has clear control points.
Action history
Review who requested an action, who approved it, what target was selected, why it was taken, and how execution completed or failed.
Retry and error review
Track execution state, retry conditions, error results, endpoint connectivity, and agent support before closing a response record.
From confirmed risk to accountable resolution.
The response workflow keeps high-impact actions anchored to evidence, approval, execution, and review so teams can move quickly without losing control.
Confirm scope
Select the correct customer, tenant, workspace, endpoint, user, process, IOC, or policy context before taking action.
Review evidence
Use alerts, hunts, cases, event timelines, endpoint state, and policy context to validate why the response is needed.
Choose action
Select a supported isolation, release, process, user, IOC, URL, AV, or related enforcement workflow based on the confirmed risk.
Capture reason
Record the business and security rationale so approvers and auditors can understand the action request later.
Approve and execute
Route the request through approval when required, then monitor agent execution, retry, error, and result state.
Review and close
Preserve action history, update the case or timeline, verify release or remediation where required, and close with evidence.
For incident responders
When investigation confirms endpoint risk, response teams need a clear path from evidence to action. XDRShield helps responders keep the affected endpoint, tenant, process, IOC, case, and reason together while they request a supported containment or enforcement action.
- Use endpoint and investigation evidence before deciding on action.
- Preserve reason, requester, target, and status context for review.
- Monitor execution result instead of assuming a submitted request succeeded.
For MSP and governance teams
Service-provider and governance teams must prove that response actions were scoped, authorized, and reviewed. XDRShield keeps customer, tenant, role, approval, and action-history context aligned so multi-customer response work remains controlled.
- Maintain tenant-aware boundaries during response operations.
- Use approval-aware controls for disruptive endpoint actions.
- Retain action history for customer reporting and internal review.
Where governed endpoint response helps most.
Use this capability when response decisions need a practical balance of speed, evidence, tenant scope, approval discipline, and execution verification.
Confirmed malicious indicators
Use IOC monitoring and supported blocking workflows when investigation confirms an indicator should be monitored or enforced on capable endpoints.
Suspicious process activity
Connect process evidence, alert context, and case findings before requesting termination where platform and permissions support it.
Endpoint containment
Request isolation for supported endpoints when lateral movement, active compromise, or uncontrolled activity requires immediate containment.
Compromised account concern
Use supported user disablement workflows when endpoint evidence indicates an account-focused response should be considered.
Audit-ready incident review
Retain actor, target, timestamp, state, reason, result, and error context so reviewers can reconstruct response decisions.
Tenant-scoped service delivery
Keep response actions scoped to the right customer, workspace, endpoint, role, and approval boundary across MSP environments.
Governed response feature directory.
Endpoint response is most effective when it is connected to detection, investigation, action history, policy, and tenant operations. Use these capability paths to understand the workflows that support governed containment.
Response Actions and Action History
Use response action records to keep supported containment and enforcement activity connected to the user, tenant, target, reason, approval status, execution result, retries, errors, and closure context.
- Requester, approver, reason, target, state, and result tracking.
- Action history for incident review and customer reporting.
- Clear distinction between submitted, approved, executed, failed, retried, and completed states.
Host Isolation and Release
Request isolation for a supported endpoint when investigation confirms risk, then use a governed release path after the affected host is understood, remediated, or ready to return to normal operation.
- Validate endpoint support, agent status, tenant scope, and expected impact.
- Preserve a reason for both containment and release decisions.
- Review result and error state before marking the action complete.
Process Termination Context
Process termination should be based on evidence, not guesswork. XDRShield keeps process monitoring, endpoint context, investigation notes, and response records connected so teams can decide whether a supported termination action is appropriate.
- Use process evidence and event timelines before requesting termination.
- Record the process target and operational reason.
- Check endpoint support, permissions, execution state, and result.
User Disablement Control
When endpoint activity points to account misuse or compromised access, supported user disablement workflows help teams act through a controlled request, approval, execution, and review path.
- Confirm the affected endpoint user and tenant boundary.
- Capture justification and approval before disruptive action when required.
- Preserve actor, target, status, and result history.
IOC Blocking and Monitoring
Use IOC monitoring and supported blocking to respond to confirmed indicators while preserving policy, endpoint, result, and action-history context for later review.
- Define indicators for monitoring or supported blocking.
- Distribute compatible enforcement through policy-aware workflows.
- Review findings, blocked state, execution result, and follow-up evidence.
URL and AV Enforcement Evidence
URL violation and antivirus finding context helps responders understand attempted access, applicable policy behavior, protection status, and the evidence that may justify further action.
- Review URL filtering violations with endpoint and policy context.
- Connect AV findings and protection results to investigation work.
- Validate platform, policy, provider, and agent support before relying on enforcement.
Investigation-to-Response Handoff
Response should follow investigation. XDRShield connects alerts, hunts, cases, and timelines to response decisions so teams can explain why containment or enforcement was requested.
- Use case context to justify action requests.
- Keep response status visible to investigators and case owners.
- Preserve timeline continuity from signal to resolution.
Policy and Approval Governance
Response governance depends on the policies, roles, rules, and approval expectations that define who can act, what can be changed, and how high-impact actions should be reviewed.
- Align response actions with role and tenant permissions.
- Use approval requirements for high-impact operations.
- Connect detection tuning and response readiness through policy management.
Tenant-scoped Response Operations
For MSPs, response work must remain scoped to the correct customer, workspace, endpoint, user, and approver. XDRShield keeps response activity aligned with tenant boundaries and delegated responsibilities.
- Maintain customer and workspace separation during action review.
- Preserve delegated role and approver context.
- Support repeatable response operations across managed environments.
Evidence, Result, and Error Review
A response request is not enough. Teams need to review execution outcome, error messages, retry state, endpoint freshness, and supporting events before they decide that a response action is complete.
- Check agent connectivity and evidence freshness before and after action.
- Use security events and endpoint monitoring to validate the result.
- Escalate unsupported, failed, or ambiguous execution outcomes.
Governed endpoint response FAQs.
Response availability depends on endpoint platform, agent version, policy configuration, role permissions, approval rules, and release maturity. These answers describe the operating model without assuming every action is available in every environment.
What is governed endpoint response in XDRShield?
Governed endpoint response is the workflow for requesting, approving, executing, verifying, and reviewing supported containment or enforcement actions while preserving endpoint, tenant, reason, actor, result, and history context.
Which response actions are covered?
XDRShield source guidance includes supported host isolation, host release, process termination, user disablement, IOC blocking, URL enforcement evidence, AV and IOC monitoring, approval workflow, response playbooks, and action history. Availability depends on platform and configuration.
Does a submitted response request mean the action completed?
No. Teams should confirm approval state, agent execution result, error or retry state, endpoint freshness, and action history. A submitted request should not be treated as proof that the endpoint action succeeded.
How does response connect to cases and investigations?
Response decisions should be grounded in evidence. XDRShield connects alerts, threat hunting, cases, investigation timelines, endpoint data, policies, and action history so responders can explain why an action was requested and how it completed.
Can MSP teams use governed response across customers?
Yes, the operating model is tenant-aware. MSP teams should confirm the correct customer, tenant, workspace, endpoint, role, and approval boundary before making changes or executing response actions.
Respond with control when endpoint risk is confirmed.
Use XDRShield to connect investigation evidence with supported containment, approval, execution verification, and action history for accountable endpoint response.
