Security teams should first identify which workflows are genuinely deterministic and which depend on analyst judgment. They should also confirm that the necessary telemetry is available, normalized, and accessible across identity, endpoint, and cloud sources. Without that foundation, agentic AI will inherit the same blind spots that limited SOAR.
Why This Matters for Security Teams
Replacing SOAR with agentic ai changes more than orchestration speed. It changes the control model. SOAR generally executes predefined playbooks, while agentic systems can choose actions, call tools, and adapt to changing context. That makes governance, approval boundaries, and telemetry quality central to the decision. Guidance from the NIST AI Risk Management Framework is useful here because it emphasizes mapping risks, measuring behaviour, and documenting accountability before deployment.
The practical mistake is treating agentic AI as a drop-in replacement for workflow automation. If the existing SOAR estate already depends on fragile integrations, incomplete identity data, or inconsistent alert enrichment, an autonomous system will not fix those gaps. It may simply execute them faster. Security teams should first decide where human judgment is still required, especially for containment, privileged access changes, and incident escalation. In practice, many security teams encounter unsafe automation only after a false positive has already triggered account lockouts, ticket storms, or unnecessary service disruption.
How It Works in Practice
The right starting point is workflow classification. Teams should separate deterministic tasks from judgment-heavy tasks before any migration. Deterministic tasks include repetitive enrichment, correlation, routing, and evidence collection. Judgment-heavy tasks include decisions about whether to isolate a host, disable an identity, revoke a token, or notify legal and privacy functions. Agentic AI can assist with both, but it should not own the higher-risk decisions until controls are proven.
That evaluation should be tied to control design, not just model capability. Current best practice is to define:
- Which tools the agent can access, and under what approval model.
- Which identity and credential boundaries prevent lateral movement or tool abuse.
- What telemetry is required for safe action selection, including identity, endpoint, cloud, and SIEM signals.
- How outputs are validated before they trigger containment, remediation, or notification.
Security teams should also test for agent-specific threat paths. The OWASP Top 10 for Agentic Applications 2026 and the MITRE ATLAS adversarial AI threat matrix both highlight risks such as prompt injection, tool misuse, poisoned context, and manipulated outputs. Those risks matter in security operations because the agent often has legitimate access to sensitive systems. The better operating model is staged autonomy: observe, recommend, require approval, then gradually allow bounded execution with rollback and audit logging. These controls tend to break down when incident response is highly time-sensitive but the environment has poor identity hygiene, because the agent cannot distinguish trusted administrative intent from compromised credentials.
Common Variations and Edge Cases
Tighter autonomy controls often increase analyst overhead, requiring organisations to balance faster response against stronger review and exception handling. That tradeoff becomes sharper in environments with high alert volumes, regulated data, or mixed cloud and on-prem tooling. There is no universal standard for how much autonomy an agentic system should have on day one, so current guidance suggests starting with low-risk workflows and expanding only after measurable validation.
Edge cases often appear where SOAR and agentic AI are expected to solve different problems. SOAR is still better for strictly repeatable playbooks, especially where approvals, evidence capture, and compliance routing need to be predictable. Agentic AI becomes more valuable when an incident is ambiguous and the system must correlate partial signals across many tools. That said, the handoff between recommendation and execution must be explicit. Organisations should document which actions require human approval, which can run under policy guardrails, and which are prohibited altogether.
For broader governance, the NIST AI Risk Management Framework remains the baseline for accountability, while the Anthropic first AI-orchestrated cyber espionage campaign report is a reminder that agentic systems can be operationalised by adversaries as well as defenders. The lesson is simple: do not replace control discipline with model confidence, especially where identity, privilege, and tool access converge.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST-SP-800-53 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GOVERN | Agentic AI replacement decisions need risk ownership, oversight, and accountability. |
| OWASP Agentic AI Top 10 | A2 | Prompt injection and tool abuse are core risks when agents can execute actions. |
| MITRE ATLAS | AML.TA0002 | Adversarial manipulation of model inputs can distort agentic security decisions. |
| NIST CSF 2.0 | DE.CM-1 | Reliable telemetry is required before an agent can safely automate response. |
| NIST-SP-800-53 | AC-6 | Least privilege limits what an agent can do if its credentials or prompts are abused. |
Assign AI governance, approval boundaries, and review cadences before granting autonomous action.
