Most people picture AI in the security operations center (SOC) as a chatbot. That picture is wrong, and it’s costing security teams real ground. At SRA, we built SCALR AI as a workflow orchestration platform, not a chatbot and not a product. It runs entirely inside a client’s own Azure tenant, using their Azure AI Foundry instance and whatever models they choose, and their data never leaves their cloud. Each agent’s custom tool execution runs in an isolated, sandboxed session through Azure Dynamic Sessions, which avoids a security flaw common to a lot of AI platforms: letting agent-generated code execute without isolation from other tools and the core system itself.

We call SCALR AI a capability because the platform itself is just infrastructure. The value comes from the engineering we apply on top of it: the workflows we design, the reusable tools we build once and use again on the next project, and the judgment about where AI belongs and where it doesn’t.

Here’s the test I give my own team. If you or your team is writing a prompt to get an agent to do something in cybersecurity, you’ve probably already lost. High-quality automation responds to incidents, events, and schedules. It doesn’t wait for a person to type the right instruction.

A Personal Assistant Is Not an Enterprise Solution

A personal assistant is tied to one person. It knows who you are, it can see your email, your chat history, your files, and it acts through an “on behalf of” (OBO) model, using your own permissions to execute whatever it does. Implemented correctly, that’s a reasonable security boundary. The assistant can’t do anything you couldn’t already do yourself.

A digital worker is different. It’s an autonomous unit that runs in response to an event or a schedule, not a person typing a prompt. It typically executes under a non-human identity (NHI), such as an Azure managed identity, and it keeps working independent of whoever set it up.

The distinction matters because any process that runs on a regular cadence and touches more than one person belongs to a digital worker, not a personal assistant. Take incident enrichment. If an analyst must prompt an agent every time an incident lands, that’s a wasted step, and the moment the next shift takes over, the result depends entirely on how that new analyst chooses to phrase the prompt. A personal assistant’s capability also leaves with the person who built it. A digital worker produces the same result no matter who’s on shift, and it stays behind when someone moves on.

Why Workflows Beat a Single Agent

Hand one general-purpose agent a large, multi-stage problem, and it will do a mediocre job at most of the individual steps, and it may behave differently each time it runs. SRA decomposes that same problem into a workflow of specialized agents, each acting like its own subject matter expert: a hash enrichment agent, a host enrichment agent, a process enrichment agent, each with its own tools, instructions, and model matched to that specific job.

A real example: an incident enrichment workflow triggered by an incident hitting Microsoft Sentinel. Each agent in that workflow handles one narrow task, pulling from tools like Microsoft Defender and VirusTotal, and considering inputs like similar prior incidents and user/device behavior, and hands its output to the next step. Breaking the problem down this way makes the input and output at every stage far more consistent than asking one agent to hold the whole problem in its head.

Decomposing the problem also changes the cost basis. Models are priced per token, and the spread between them is large. Some run for under five cents per million tokens. Frontier reasoning models run for multiple dollars per million tokens. Routing every subtask through a frontier model wastes money on work that doesn’t need that level of reasoning. A workflow lets each agent use the cheapest model that can do its specific job well, and reserves the expensive model for the one step that actually needs it.

There’s a second cost hidden in a single-agent approach: context growth. A single agent’s context window keeps expanding with every tool call and every step it takes, so a job that costs a workflow 500,000 tokens might cost a single agent five million tokens to do the same work, with lower quality and less predictability. SRA’s workflows contain each agent’s internal reasoning inside its own step. Only the output passes downstream, which keeps total token usage low and the result far more consistent.

Where Deterministic Automation Still Wins

Security Orchestration, Automation, and Response (SOAR) is deterministic. The same input produces the same output every time, the way a script or a lookup does. Some SOC tasks are exactly that: a straight retrieval with no reasoning required, and they should stay scripted. Other tasks require judgment and interpretation, and that’s where an agent adds value that a script can’t.

SRA’s workflows weave deterministic steps directly into the same pipeline as agent reasoning. We stay exact and scripted wherever a task allows it, and bring in an agent’s judgment only at the step that actually needs it.

Most organizations never got SOAR to a mature state. A team that didn’t master SOAR will hit the same failure mode with AI, unless it retrains and replans deliberately, or brings in outside expertise to make that transition.

The Two Mistakes We See Most Often

The first is overbuilding on personal assistants. Teams stitch together increasingly complex solutions using personal assistants and desktop-based MCP servers. These setups can genuinely help the one analyst who built them, but they don’t transfer to the next person on shift, and they disappear the day that analyst leaves the organization.

The second is missing oversight and monitoring. The industry underestimates how much visibility agent execution actually requires, both for quality assurance and for the ability to step in when something breaks. SRA built an internal platform called Watchtower for exactly this. It logs every agent execution inside a workflow, showing which tools an agent called, what data it retrieved, and why, at every phase of the run. The result is an army of AI agents backed by an army of humans watching them, ready to step in the moment something goes wrong. Expect the obligation to prove and trace why an agent made a given decision to only grow from here.

A Maturity Model for Automation, Not a Light Switch

We modeled our automation maturity framework loosely on the levels used for autonomous vehicles, adapted into six levels for the SOC, level zero through level five.

Level zero is manual, human-led investigation and response. Level one adds SOAR integration, deterministic if-this-then-that logic. Level two has AI perform analysis and offer response guidance, without rendering a verdict. Level three is a trusted AI verdict with human-led response: the agent enriches the incident, reaches a determination such as true positive, false positive, or benign positive, and can take supporting actions like assigning the incident or posting an alert to a team channel, while a human still executes the response. This is the first level with meaningful ROI, and the milestone most organizations should aim for first.

Level four is human-in-the-loop response, where the agent requests permission before acting, for example, “I will isolate this host if you approve,” and an agentic workflow executes the action once a human clicks to allow it. Level five is fully autonomous: the agent reaches a level three determination and takes the action itself, with no human step in between.

The goal isn’t 100 percent level five. Some incident types carry too little fidelity to automate with confidence and should stay at level three. Others, incidents touching VIP-associated machines, for example, may deliberately stay at level four so a human stays hands-on. CISOs should track the percentage of incidents falling into levels three, four, and five the same way they’d track any other operational metric.

Read more about this in AI Automation Levels in Security Operations.

Build the Capability. Stop Subscribing to Someone Else’s.

Focus on building your team’s capability to design these solutions. Outside a narrow set of organizations running a single vendor’s stack end to end, off-the-shelf AI tools don’t flex to fit an organization’s tools, processes, or risk tolerance, and every one-size-fits-all AI product I’ve evaluated runs into that same wall.

Building this capability doesn’t require a large engineering team. SRA’s platform (SCALR AI) lets an agent build and deploy its own tools, so low-code and no-code paths are part of the option, not just custom development. Bring this capability in from a partner, build it inside your own organization, or do both.