AI for You: A More Capable Defense

If the attacker’s advantage may come from making familiar work cheaper and more repeatable, the defender’s opportunity begins with a different bottleneck: useful information is often already present, but scattered across systems, written for specialists, or buried beneath more urgent-looking noise.

At Northstar Health, the security operations center receives an alert about an employee account signing in from an unusual location. The alert is real, but its meaning is unclear. The account belongs to a finance manager. There was a failed login, then a successful one; a cloud application shows an unfamiliar session; and an endpoint tool reports a script launched shortly afterward. Each system offers a fragment. None, alone, answers the question the CISO cares about: Is this a compromised account, and what should we do now?

An AI assistant can help by gathering those fragments, summarizing relevant threat intelligence, and translating technical findings into a concise assessment. That can be valuable. It can also produce a confident paragraph that quietly turns three uncertain clues into one false certainty. The difference between those outcomes is not fluency. It is whether the answer is grounded, traceable, and useful for a decision.

From documents to decisions

Security teams consume information in several forms: advisories, vulnerability reports, threat-intelligence feeds, incident tickets, detection alerts, and analyst notes. Much of it arrives faster than anyone can read it. AI systems are well suited to some of the work involved: extracting entities, comparing reports, summarizing long documents, and answering questions in ordinary language.

Suppose an intelligence report describes a campaign targeting cloud identities and names several indicators of compromise. An analyst could ask an assistant to identify which indicators appear in Northstar’s telemetry, summarize the campaign’s observed behavior, and list the evidence that supports or weakens a possible connection. Instead of manually searching separate consoles and copying excerpts into a note, the analyst gets a first-pass map of what may matter.

The useful mental model is not “the model knows the threat.” It is “the model can help route attention through a large body of material.” It may find a relevant passage, connect terminology used differently across sources, or turn a dense report into questions an analyst can pursue. But a match is not attribution, and an indicator’s presence does not by itself prove compromise. Context determines whether the finding changes risk.

This is why provenance matters. A decision-ready summary should let an analyst inspect the underlying alert, report, or log entry behind each important claim. If the system says a campaign uses stolen session tokens, the analyst should be able to see which source says so, when it was published, and whether it describes observed activity or a researcher’s assessment. Without that trail, a polished summary can become a new layer of unverified intelligence.

One finding, different audiences

The same technical evidence must often support several different conversations. An analyst needs to know what to investigate next. An incident commander needs to understand operational impact and immediate choices. An executive needs a clear account of business exposure, uncertainty, and the decision being requested.

AI can help translate between these levels without requiring every audience to read raw logs. For the analyst, it might present a timeline: unusual sign-in, new session, then script execution. For the incident commander, it might state that the account could be compromised and recommend checking for unauthorized access to finance systems. For the executive, it might say that the team is validating a suspicious account, has not yet confirmed data access, and will temporarily restrict the account while checks continue.

Translation must not become distortion. “A script ran after an unusual login” is evidence. “The attacker stole financial data” is a conclusion that requires more evidence. A useful assistant can make the distinction visible—separating observed facts, interpretations, confidence, and open questions—rather than smoothing them into a single narrative.

At Northstar, the assistant’s first draft says the account was “likely compromised by a known campaign.” It sounds plausible. But when the analyst opens the cited material, the campaign report concerns similar sign-in patterns, not this account; the supposed match is based only on geography and timing. The assistant has combined a real report with a real alert and invented a stronger relationship than either supports.

The analyst corrects the assessment: the sign-in is suspicious, the campaign connection is unconfirmed, and there is not yet evidence that the account accessed sensitive files. The team restricts the session, reviews authentication and cloud audit logs, and checks whether the script’s behavior is known and authorized. The revised summary is less dramatic and more useful because it says what is known, what remains uncertain, and what action is proportionate.

The test is decision quality

NIST’s AI Risk Management Framework 1.0 emphasizes that AI risks depend on context and should be managed across a system’s lifecycle ^[4]. For security teams, that principle has a practical consequence: evaluate an assistant in the workflow where its output will be used. A summary that saves reading time may be helpful; a summary that causes an analyst to close the wrong alert is not.

Ask what information the system can access, whether it can show the sources behind its claims, how it handles conflicting evidence, and what happens when it does not know. Test it against cases where the correct answer is “insufficient evidence.” Then see whether analysts treat its output as a lead to verify or as an answer to accept. The chapter’s outcome measures later provide a fuller method for determining whether such assistance improves the operation.

AI does not remove the work of judgment. It can move that work: away from finding and reformatting every fragment, toward checking how fragments fit together and deciding what follows. That shift is valuable when the assistant makes evidence easier to reach—not when it makes uncertainty harder to see.

Once evidence is easier to reach, the next question is harder: which evidence deserves attention first?

A security team does not lack signals. It has endpoint alerts, identity logs, cloud events, email reports, vulnerability findings, and threat intelligence arriving at different speeds and in different formats. The scarce resource is usually not data but focused human attention. AI can help by connecting fragments that would otherwise sit in separate queues—and by explaining why a case may matter. But a tidy explanation is not the same thing as a true one.

Imagine Northstar’s security team receives an alert that an employee’s account signed in from an unfamiliar location. On its own, that might be routine: travel, a corporate VPN, or a location-detection error. An AI-assisted system could compare the event with recent password resets, unusual mailbox access, a newly registered device, and a sensitive file download. Instead of presenting five unrelated alerts, it might group them into one developing case and move that case above dozens of lower-risk events.

That is a meaningful improvement in triage: not simply ranking alerts, but assembling enough context to make a ranking more defensible. The best systems help analysts see which signals are connected, what evidence supports the connection, and what remains unknown. A risk score without those details is just a number wearing a serious expression. A published Wazuh implementation demonstrated the technical and operational feasibility of LLM-assisted initial alert triage and summarization, but did not evaluate the accuracy of its conclusions against human-labeled ground truth ^[5]. This does not establish improved detection or risk reduction.

Correlation is not confirmation

Pattern recognition can reveal relationships that are difficult to spot manually. A model may notice that several low-severity events share an account, device, time window, or unusual sequence. It can summarize a long trail of activity and suggest likely explanations: benign administrative work, a compromised credential, or a misconfigured service. This can shorten the distance between an alert and a useful investigative question.

Yet correlation can also manufacture a story from coincidence. If a model sees a suspicious sign-in, an uncommon process, and a large download, it may connect them even when the events involve different users or unrelated systems. The system may therefore surface a lead, but its proposed connection needs confirmation against the underlying events.

Noisy or incomplete data makes the problem worse. Logs may arrive late, omit fields, use inconsistent identities, or cover only part of the environment. A system that cannot see an identity provider’s relevant events may misread a familiar account as an attacker. A missing endpoint record can make a sequence look like an unexplained leap. When the evidence is thin, confidence should fall; too often, missing context is simply invisible in the polished output.

For leaders, this means asking not only whether a system detects more, but what it can see. Which data sources are included? How are identities and assets reconciled? Can an analyst inspect the underlying events and see when a source is absent? A useful prioritization system makes its field of view legible.

A queue is a decision system

Prioritization changes what people investigate—and what they leave waiting. A false positive costs time. A false negative may allow an intrusion to continue. Those costs are not equal, and they vary by case. An alert involving a low-impact test account should not necessarily outrank an ambiguous event tied to a privileged identity or critical service.

AI can enrich a ranking with business context: asset importance, account privileges, exposure, known vulnerabilities, and recent activity. But that context must be accurate and current. If the asset inventory is wrong, the ranking inherits the error. If a model learns from past analyst decisions, it may also reproduce their blind spots, including the tendency to investigate familiar alert types while overlooking less common ones.

Treat rankings as a way to allocate attention, not as a verdict about risk. Analysts need a route to challenge them, and teams should examine what repeatedly rises to the top—and what consistently sinks. Track not just alert volume or average handling time, but confirmed incidents, missed cases, escalation quality, and the effort spent correcting bad recommendations. Faster closure is not a benefit if it comes from confident dismissal.

Investigation still needs a mind at work

During an investigation, AI can summarize a timeline, identify related accounts, translate technical events into plain language, and propose next questions. It may help an analyst search across more evidence than would be practical by hand. The human task shifts from collecting every fragment toward testing the explanation: Does the timeline hold? Are the events linked by reliable identifiers? What alternative account fits the evidence? What would change our judgment?

A good investigative aid should make it easier to seek disconfirming evidence, not merely gather support for its first theory. If it proposes credential theft, the analyst might check whether the sign-in came through an approved proxy, whether the user was traveling, and whether the session performed actions inconsistent with normal work. The model can suggest these checks; the team still has to assess the records and the competing explanations.

The practical standard is therefore not “the AI found the answer.” It is “the AI helped the team reach and verify a better answer sooner.” The appropriate oversight depends on the proposed action: automatically grouping events is different from automatically revoking access.

AI can make the security queue more intelligent by turning isolated signals into testable leads. The gain is not that machines never miss a pattern, or that analysts can stop thinking. It is that analysts may spend less time searching for the pieces and more time asking whether the pieces truly belong together.

From a lead to a controlled response

Once an analyst has a testable lead, the next question is not simply what the system can do. It is what it should be allowed to do without asking first.

AI can shorten the distance between investigation and action. Given an alert and the relevant logs, an assistant might assemble a timeline, identify the systems and accounts involved, draft the next investigative queries, and prepare a concise incident update. It can suggest that an analyst check whether a suspicious login was followed by mailbox-rule changes, or compare the affected endpoint with other devices contacting the same domain. These are useful contributions: they make the next step easier to see and cheaper to take. They do not, by themselves, establish that the activity is malicious.

Name the work before judging the AI. In this example, the delegated work might be assembling a timeline, proposing investigative queries, or preparing a suspension request—not “responding to incidents” in the abstract. Those tasks differ in what they change and how much review they require. Assistance is not autonomy: preparing an action for approval is not the same as independently deciding and carrying it out.

The distinction matters when a workflow moves from recommending to changing. Searching logs, grouping alerts, and drafting a ticket generally leave the environment as they found it. Disabling an account, blocking a domain, isolating a laptop, or revoking a service credential changes access or operations. A mistaken recommendation can be corrected in the analyst’s notes. A mistaken action may interrupt payroll, halt a production line, or lock a responder out of the system they need to investigate.

Consider a suspicious account at Northstar Health, the company whose security team has been using AI to connect scattered signals. An assistant correlates an unusual sign-in with a new forwarding rule and access to sensitive files. It can draft a timeline, list the events behind the proposed connection, and prepare an account-suspension request. The on-call analyst checks whether the employee is traveling, confirms the activity with identity logs, and approves suspension. If the account belongs to a clinician covering an urgent shift, the response also needs a safe way to restore access or provide an alternative.

The degree of control should fit the consequences. A team may allow routine, readily reversible actions to proceed automatically, while requiring approval for disruptive changes or those affecting many users. Whatever the boundary, the workflow needs a responsible owner and a record of its evidence, authorization, and action. The broader design question is how to limit the consequences of failure and recover; that containment problem is treated in the chapter on securing AI agents.

The goal is not to put a human between every alert and every action. That would preserve the bottleneck while adding a rubber stamp. It is to let bounded, observable tasks move quickly while reserving meaningful judgment for actions whose effects are broad, uncertain, or difficult to reverse. Measure whether the delegated work improves the decision or response, not just how quickly the system produces a timeline or recommendation. In an incident, that means knowing exactly what was sped up.

Knowing what was sped up is the starting point. The next question is whether speeding it up made the organization safer.

AI can produce more summaries, recommendations, alerts, and automated actions than a team could manage before. Those numbers may look impressive in a quarterly review. They are not, by themselves, evidence of a stronger defense. A system that closes twice as many alerts while missing the one that matters has increased activity, not security. A copilot that drafts an incident report in seconds may save time—or simply move the work to the analyst who must correct it.

Start by naming the work being delegated. Is the system extracting evidence from logs, grouping related alerts, drafting an incident update, recommending a priority, or taking a containment action? “AI-assisted security” is too broad to evaluate: each task has a different baseline, human role, and possible failure. Then ask what would count as a meaningful change compared with the existing method. Faster completion, lower cost, broader coverage, or better quality may matter, but none automatically proves a better security outcome.

A useful measure begins with the outcome the workflow is supposed to improve. For an investigation assistant, that might be the time required to understand an incident well enough to choose a sound next step. For a prioritization model, it might be whether the team identifies and remediates the genuinely urgent exposures sooner. For automated containment, it might be how quickly a compromised account or device is safely isolated, without disrupting unrelated business activity.

Think of the defense dividend as a change in four clocks: time to understand, time to prioritize, time to contain, and time to recover. The clocks are connected, but not interchangeable. A tool may shorten time to understand while leaving containment unchanged because approval or access remains the constraint. That is still useful, but it is not a reduction in response time from end to end.

For each clock, establish a baseline using the organization’s existing process. How long does a representative investigation take from the moment useful evidence is available to a defensible conclusion? How often does a high-risk finding reach the top of the queue promptly? How long from a confirmed incident to effective containment? How long until affected services and users return to a trusted state? Definitions matter. “Time to contain” should not mean “time until someone clicked isolate” if the device was still communicating through another route.

Then compare like with like. Run AI-assisted and existing workflows against realistic cases: familiar incidents, messy ones, ambiguous signals, and cases where the right answer is to wait for more evidence. Use historical incidents where the records are adequate, and carefully designed exercises where they are not. Keep the task, available information, and success criteria consistent. A demonstration using a tidy example chosen by the tool’s supplier is a product demonstration, not an evaluation of your operation.

Speed must be paired with quality. Track whether summaries omit important evidence, whether recommendations are supported by the underlying data, and how often analysts accept, correct, or reject them. For automated actions, record both useful interventions and harmful ones: false positives that disrupt work, missed opportunities to contain, unnecessary account suspensions, and actions taken with insufficient confidence. “Human approved” does not make an error disappear. It may show that the human interface failed to make the uncertainty visible.

Measure the workload shifted as well as the workload removed. Did analysts spend less time assembling evidence and more time making decisions? Did a faster initial answer create extra verification or rework later? Did the system reduce the queue, or merely produce a larger queue with better-written descriptions? A small sample of reviewed cases can expose these costs before they become a permanent feature of operations.

Finally, test for the conditions that make deployment difficult: incomplete telemetry, conflicting evidence, unusual but legitimate behavior, and changes in the environment. Performance should be checked again after models, data sources, workflows, or permissions change. Results from a controlled trial are a starting point, not a lifetime warranty.

Consider a hypothetical Northstar pilot, using invented numbers to illustrate the decision. Across 100 matched historical cases, median evidence-assembly time falls from 20 minutes to 8, including review. But the assistant also recommends closing two confirmed incidents. Maya can approve the evidence-assembly feature while withholding automatic closure. The result supports a narrower deployment, not a declaration that the whole product is safe. Rare severe failures also require targeted testing; a small pilot cannot establish their absence.

That is the defense dividend worth pursuing: a measured gain in a defined task, with quality and consequences checked separately. Faster work earns deployment only within the boundary the evidence supports.