Every AI security vendor is selling the same promise right now: autonomous response, minimal human intervention, incidents handled before anyone wakes up. For teams short on people, it is an appealing pitch. It is also aimed at the wrong target.
Incident response has never been limited by how fast someone can read a log. It is limited by how well someone decides what a set of signals means and what to do about it, usually with incomplete information and a clock running. Valid credentials used from an unusual location. An admin tool running at 2 a.m. A cloud API pulling more data than it normally does. Each one looks normal in isolation. Whether it is an attack, a misconfiguration, or a contractor working late is a judgment call.
Antares treats incident response as a decision system. AI makes that system faster. It sorts the noise, assembles the context, drafts the summary, and surfaces the runbook. It should not own the call. Organizations that let it are trading a risk they can see for one they can't.
Where AI Earns Its Place
AI is most valuable in the work that comes before a decision: collecting, correlating, and condensing. Each use below follows the same pattern. The machine prepares. A person decides.
- Detection. Models learn what normal looks like for a user, system, or service and flag deviations that static thresholds miss. Start with one critical system and a handful of metrics, and tune before expanding.
- Alert correlation. During a real incident, responders can receive hundreds of alerts describing the same event. AI groups them by timing, component, and pattern into a single case. That alone gives analysts back hours and restores trust in the queue. Review merged cases for a few weeks to confirm nothing important is being folded away.
- Triage drafts. AI can propose severity, affected service, and the owning team. Treat that as a prefilled form a person signs, not a decision already made. Start with low impact categories and widen as accuracy proves out.
- Context and timelines. Mid incident, the expensive question is "what do we actually know right now?" AI can pull related alerts, tickets, change records, and identity activity into a timeline and a draft status update. A person reviews it before it reaches leadership, customers, or regulators.
- Pattern analysis after the fact. Across many incidents, AI can find recurring causes that humans miss one ticket at a time: the same misconfiguration, the same aging dependency, the same access pattern. Those findings feed detection rules, playbooks, and the risk register.
Notice what is missing from that list. None of it requires the AI to be accountable for an outcome.
Where the Decision Stays Human
The decisions that matter in an incident are made with incomplete information, and they carry business consequences no model is positioned to weigh. Four questions shape almost every one of them:
- Confidence. How sure are we that this is malicious?
- Impact. What happens to the business if it is real, and what happens if we act and it isn't?
- Speed. How fast does this spread or escalate if we wait?
- Reversibility. If we are wrong, how hard is it to undo?
AI can inform the first and third. It can score risk, correlate signals, and model how an attack might progress. It is poorly positioned for the second and fourth, because those answers rarely live in telemetry. The flagged account belongs to the CFO closing a deal tonight. The server queued for isolation runs payroll. A regulator expects notification inside a fixed window. A person in the room knows these things. The model doesn't.
There are other limits worth naming plainly:
- Novel incidents have no precedent. Similar incident matching has nothing to match against on a first of its kind event. That is where AI helps least and experienced responders help most.
- AI can be confidently wrong. A root cause or summary can read as authoritative and still be incorrect. Every output is a draft to verify, not a fact to act on.
- Attackers study the models too. An adversary who understands what detection treats as normal will work to look normal.
- It doesn't run the room. Coordinating a major incident, managing stakeholders, making tradeoffs under pressure, and keeping a bridge call steady is human work.
None of these are reasons to avoid AI. They are reasons to be precise about what it is for.
Decision Thresholds: Draw the Line Before the Incident
The real question is not whether to automate response. It is which actions can run without a person, and that line gets drawn in advance, not at 2 a.m. with an attacker moving laterally.
A workable rule: automate actions that are high confidence, low impact, and easy to reverse. Require human approval for anything with real business impact or that is hard to undo. Escalate anything ambiguous.
Write these thresholds into each playbook as named decision points. A playbook should state what triggers it, what automation does on its own, where it stops and waits, and who has authority to go further. Then test them in tabletop exercises. A threshold nobody has practiced gets overridden the first time it is inconvenient.
Governing the AI Itself
Once AI is part of the response, it becomes part of what has to be governed. Most organizations add the tool and skip this step. At minimum, five things need to be in place:
- Ownership. Every AI driven action and recommendation has a named human owner, by role. "The platform did it" is not an answer a board, auditor, or regulator will accept.
- Validation. Define what checking an output means for each use. Who reviews a triage suggestion. Who signs off on a summary before it leaves the team.
- Logging. Record what the AI recommended, what was done, who approved it, and whether anyone overrode it. That record is your evidence after the incident and your tuning data going forward.
- Override. Analysts need a fast, blame free way to stop or reverse an automated action. If overriding the tool is harder than accepting it, people will accept it.
- Review. Track where the AI was right, wrong, or ignored. Tune thresholds against that record, not against vendor claims.
This is the same accountability question that ISO/IEC 42001 and the NIST AI Risk Management Framework ask of any AI system. We covered the authorization side in When AI Agents Can Act, Authorization Is No Longer Enough. Incident response is where those questions get tested under pressure.
Why This Matters Most in the Mid-Market
Organizations with 50 to 500 employees are the most tempted to let the tool decide. The security team is small, sometimes one person and an MDR partner, and autonomous response sounds like headcount. It is also where a wrong automated call costs the most: fewer redundant systems, less tolerance for downtime, and less capacity to clean up after an action that should never have run.
The answer is not less AI. It is AI pointed at the right work, with the decision points written down before the incident. Let the machines provide speed and scale. Keep context, judgment, and accountability with people.
Security failures are usually decision failures. AI doesn't change that. It makes the decisions arrive faster, which is exactly why someone needs to own them.
