SOAR is brittle because it assumes the world stays close to the script, but unbounded agents are risky because they can improvise past boundaries. The risk comes from combining real-time decision-making with unrestricted execution, which can turn a useful investigation into an unauthorised operational change.
Why unbounded agents are a different operational class from SOAR
SOAR playbooks are operationally narrow by design: they execute predefined steps, usually with bounded inputs, bounded outputs and clear handoffs. Unbounded agents are different because they can choose actions in response to live context, which means the risk is not just incorrect execution, but unexpected execution outside the intended workflow.
That matters because operational risk rises when a control plane can both observe and act. A playbook can fail, but it usually fails inside a known boundary. An agent can still be useful while quietly crossing boundaries, and that is what makes the failure mode harder to predict, contain and audit.
Where SOAR is a scripted responder, an unbounded agent is closer to a delegated operator. The practical difference is how authorization should constrain AI agents: if the agent can infer new steps, call tools and continue without fresh approval, then its behaviour is no longer limited to the original investigative intent.
What changes operationally when an agent can improvise
The biggest change is that the agent does not merely complete a task, it can reinterpret the task. In a SOAR flow, each branch is pre-approved and the blast radius is constrained by the playbook. In an unbounded agent, the same investigation can expand into remediation, data collection, account actions, ticket updates or system changes without a person explicitly deciding each step.
That expansion creates three operational differences. First, the agent can chain actions in ways the author did not anticipate. Second, it can act on stale, partial or ambiguous context and still appear productive. Third, it can blend analysis and execution, which makes it harder to tell whether the system is still investigating or has already changed the environment.
This is why a risk review should focus less on whether the agent is “accurate” and more on whether its authority is bounded. Zero trust for AI agents is useful here because it treats the request as something to verify continuously, not something to trust just because the session started legitimately.
Where the risk becomes material in practice
The risk becomes material when the agent can take action that changes state outside a sandbox, especially if it can reach production systems, tickets, identities, cloud resources or downstream automations. At that point, a bad inference is no longer just a bad recommendation. It can become an unauthorised operational change with persistence, side effects and rollback cost.
That is why the most common failure pattern is not dramatic sabotage. It is quiet scope creep: the agent does “one more helpful thing”, then another, until an investigation turns into a change request, a clean-up action or a privilege-bearing workflow. The issue is not only malice, it is delegated authority without a hard stop.
AI agent observability and incident response becomes essential once actions can outlive the original prompt, because attribution and a tested kill switch are what separate recoverable automation from uncontrolled execution.
Risk and Threat Considerations
Unbounded agents increase operational risk because they can turn trusted context into trusted action. When the agent can browse, decide and execute in the same loop, an attacker does not need to break the system first, they only need to steer the agent into taking an unsafe next step.
Failure mechanism: The agent uses live context to choose actions beyond the intended playbook, then applies real privileges to production systems, records or identities before a human reviews the outcome.
Impact: The organisation can suffer unauthorised changes, data exposure, destructive actions, privilege misuse or hard-to-reconstruct incidents that look like normal automation until the side effects appear.
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 ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Unbounded agents fail when authority expands beyond intent. |
| ASI02 — Tool Misuse | The risk centers on agents invoking tools beyond the intended workflow. | |
| ASI08 — Cascading Failures | One unsafe agent action can propagate into multiple operational changes. | |
| Recommendation — Constrain agent permissions and require policy checks before any privileged action. Restrict tool access to approved actions and block unapproved tool chaining. Add containment and rollback controls for agent-driven workflows that can cascade. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Operational risk drops when agent authority is tightly minimized. |
| AU-2 — Event Logging | Agent autonomy needs an audit trail to reconstruct actions and decisions. | |
| Recommendation — Limit agent access to the minimum privileges needed for each task. Log agent actions and decisions at each material step for later review. | ||
| NIST Zero Trust (SP 800-207) | None — Zero Trust Architecture | Continuous verification fits systems where action must not be trusted by default. |
| Recommendation — Enforce continuous verification and per-request policy before agent execution. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Unbounded agents often act through legitimate credentials and approved sessions. |
| Recommendation — Monitor legitimate accounts used for unexpected action sequences and escalation. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Operational risk depends on who and what can take action in production. |
| Recommendation — Review and restrict production access paths that an agent can use. | ||
Practitioner Guidance
What to prioritise: Treat bounded authority as the primary control, not prompt quality. If an agent can touch production, identities or irreversible workflows, require explicit action-scoped permissions, not open-ended task ownership.
What to verify: Verify that the agent’s allowed actions are narrower than its conversational capability. A good control set makes it impossible for the agent to silently turn investigation into remediation without a policy decision and an audit trail.
Common mistake: Teams often overestimate the safety of “read-only” or “helper” agents. Read-only access can still create operational risk if the agent can trigger other systems, recommend unsafe actions or hand off to a toolchain that is not equally constrained.
Practitioner takeaway: The safest comparison is not SOAR versus AI, but bounded execution versus delegated autonomy. If the system can improvise, the question is whether every meaningful action still requires policy, attribution and a reversible control point.