What an AI Security Analyst Should (and Shouldn't) Do

The first shift, not the whole job

There are two unhelpful ways to think about AI in security operations. One says it will replace the analyst. The other says it's a chatbot bolted onto a dashboard. The useful version sits in between: an assistant that does the first shift of an investigation quickly and consistently, then hands a human a clear, evidenced picture to decide on.

The first shift is the part of the job that eats hours. It means figuring out which data to query, writing the query, pivoting from one result to the next, checking whether a host or account shows up elsewhere, and writing it all up. None of that is where an experienced analyst's judgement is best spent.

Where AI earns its keep

• Plain-language questions. “Show me anything that talked to a new external address in the last hour” should not require memorising a query language. Translating intent into the right query across the right sources is a strong fit for AI.
• Pulling the thread. When a first result points to a host, the next obvious steps are to check its other connections, the accounts that used it, and the processes it ran. An AI assistant can take those pivots without waiting to be asked each time.
• Summaries for different readers. The same incident needs a technical timeline for responders and a two-paragraph summary for leadership. Drafting both from one set of evidence saves real time.
• Drafting the response. Proposing containment steps, such as which hosts to isolate, which sessions to revoke, and what to hunt for next, gives the human something concrete to approve, edit, or reject.

Where it must not act alone

Speed is only an advantage when the action is safe to take quickly. Some actions need a person in the loop every time:

• Irreversible changes: deleting data, wiping machines, or anything that can't be undone.
• High-impact identity actions: disabling executive, break-glass, or service accounts that production systems depend on.
• Broad network changes: firewall or routing rules that could take down more than the affected systems.
• Anything outside its evidence: if the assistant can't point to the events that justify an action, it shouldn't be taking it.

Five guardrails before you switch it on

1. Evidence, always. Every finding and every recommendation should link back to the raw events behind it, so an analyst can check the work in seconds.
2. Approval tiers by blast radius. Low-risk, reversible steps such as isolating a single workstation can be pre-approved. Higher-impact steps require a human decision.
3. Least privilege. Give the assistant only the permissions its approved actions need, and nothing that would let a manipulated prompt reach further.
4. A complete audit trail. Log every question, query, finding, recommendation, approval, and action, in a form you can export.
5. Honest uncertainty. An assistant that says “I couldn't confirm this” is far more useful than one that sounds confident about everything.

Questions to ask any vendor

• Can every conclusion be traced to specific raw events?
• What, exactly, can it do without human approval, and can we change that?
• What permissions does it run with, and how is it protected against prompt injection from the data it reads?
• How are our prompts and security data stored, and are they used to train shared models?
• Can we export the full audit trail of its activity?
• How does it behave when the evidence is incomplete or contradictory?

How Specter AI is designed

Specter AI, the analyst built into the Cursor Platform, follows the same principles. You ask in plain language, it investigates across endpoint, cloud, and identity data, and every finding links back to its evidence. Responses are presented as recommendations for a person to approve, with reversible steps such as isolation and rollback favoured first. You can watch that flow end to end in the Specter AI guided tour.