What an AI Assistant Changes in Security Work, and What It Does Not

The work that changes

Start with the thing that is actually different, because most writing on this subject never gets to it.

An analyst working an alert spends very little time thinking and a great deal of time translating. You know what you want to find out. You know, roughly, where the answer lives. What stands between you and it is a query language you use often enough to be competent and not often enough to be fluent, a schema with four hundred columns of which you remember thirty, and a set of vendor field names that are almost but not quite what you would have called them.

That gap is where the hours go. Not the reasoning, which is the part you are paid for and the part you are good at. The translation.

An assistant collapses the translation. You describe the situation in the words you would use to a colleague, and you get back something executable. The query might be wrong, and this course is largely about the ways it is wrong, but the cost of producing it has gone from fifteen minutes of documentation-checking to four seconds. That is a genuine change in what a shift can cover, and it is not a small one.

The same collapse happens anywhere the bottleneck is expression rather than judgment:

• Turning a finding into a written report that a non-technical reader can act on
• Turning a detection idea into rule syntax for a platform you use twice a year
• Reading an unfamiliar log format well enough to know which field matters
• Restating a long timeline as a paragraph somebody will actually read

Every one of those is a task where you already know the answer and the work is getting it into a different shape. That is what these systems are for, and used that way they are straightforwardly good.

The work that does not change

Now the other half, and it is the half that the marketing skips.

Deciding what question to ask. An assistant will answer the question you put to it with impressive fidelity. It has no view on whether that was the right question. In the example on the previous page, the analyst asked for sign-ins and got sign-ins; the useful question was about failures, and nothing in the exchange surfaced the difference. Question selection is the core analytical skill and it is entirely yours.

Knowing what the environment is. Your estate has a service account that legitimately authenticates at three in the morning, a legacy application that produces failures nobody has ever fixed, and a subnet that belongs to a partner. None of that is in any model's training data. Context is why two identical log lines mean different things in two organizations, and an assistant has none of yours unless you supply it.

Deciding what to do. Whether to isolate a host, whether to wake somebody, whether the evidence supports telling a regulator that data left the building. These are decisions with consequences that attach to a person, and they require someone who can be held to them.

Being accountable for the output. If a generated query missed the intrusion, the incident report does not say the assistant was wrong. It says you closed the alert.

The property that predicts it

Start with the conclusion, because it makes the four categories obvious rather than arbitrary.

These systems are strong wherever the answer is hard to produce and easy to check.

That is the whole boundary condition on the useful side. Producing a correct KQL query from a plain-English description is hard for a human and takes minutes. Checking whether the resulting query says what you meant takes seconds, because you already know what you meant. The asymmetry between production cost and verification cost is what creates the value.

Where that asymmetry reverses, the value evaporates and the risk arrives. Determining whether a service account's behavior is anomalous in your estate is easy for a model to produce an answer about and hard for you to check, because checking requires exactly the estate knowledge that would have let you answer it yourself.

The mirror property

The previous sub's rule inverts cleanly.

These systems are weak wherever the answer is easy to produce and hard to check.

An answer about whether a service account's activity is unusual takes four seconds to generate and requires estate knowledge to verify. An answer about how many files were accessed takes four seconds to generate and requires a query to verify. In both cases the production cost has collapsed and the verification cost has not, which means the tool has moved work rather than removed it, and moved it to a place where it is easy to skip.

The reason to understand the mechanism rather than memorize a list is that it tells you which limits are permanent. A weakness caused by a gap in training data closes as models improve. A weakness caused by the model not having access to a fact is permanent, because no amount of capability substitutes for information that was never there.

Every category here is the second kind.

Anything about your estate

The largest category, and the one that produces most of the failures in real use.

A model has never seen your environment. It does not know that 10.0.1.x is your Manchester office, that svc-legacyerp authenticates nightly by design, that your finance team routinely downloads twenty files at month end, or that a particular partner's VPN egress appears as a foreign address every Tuesday.

That means every question of the form "is this normal" is unanswerable, and it will be answered anyway. Ask whether a sign-in from an unfamiliar country is suspicious and you will get a well-reasoned account of why foreign sign-ins warrant investigation. The account is generically true and it is not about you, and the difference is invisible in the text.

Negative claims

The second category, and the most dangerous, because it produces the most confident-sounding output.

"There is no evidence of lateral movement." "The account was not used elsewhere." "No other host shows this behavior."

Every one of these is a claim about absence, and absence cannot be established from a sample. The model can only report what it was shown, so a negative claim from an assistant is a statement that the material provided did not contain the thing. That is a much weaker claim than the sentence appears to make, and the gap between them is where incidents get closed.

This is the conversational relative of failure mode 4. An empty query result and an assistant saying "no evidence of X" are the same error wearing different clothes: both mean not found in what was looked at, and both are routinely read as not present.

The check is to convert the negative into a positive. Instead of accepting "no lateral movement", ask what would have been visible had there been some, then look for that specifically. If the answer is "logons from this host to others in the same window", that is a query, and the query has an answer.

Arithmetic over evidence

Counting is not what these systems do, and the results are worse than random because they are plausible.

Ask how many distinct users a source address touched and you will get a number. The number was produced the way every other token was produced, by likelihood, and it will frequently be close to right, which is precisely what makes it dangerous. A wildly wrong number gets challenged. A number that is out by two does not.

The same applies to durations, percentages, rankings and any claim of the form "most of the". These read as measurements and are generated as prose.

Reporting its own confidence

The fourth category is subtle and it undermines the obvious workaround.

The intuitive fix for everything above is to ask the model how sure it is. This does not work, and the reason is worth understanding because the failure is so convincing.

Asking for a confidence level produces text about confidence, generated by the same process as everything else. The model is not consulting an internal measure and reporting it. It is producing the words that plausibly follow a request for a confidence assessment, and those words are shaped by the phrasing of your question and the tone of the exchange more than by anything about the underlying claim.

The practical consequence is that a stated "high confidence" carries no information you can act on, and, worse, it feels like information. It is the missing signal from Module 0, apparently restored, and it is a reconstruction rather than a measurement.

The five, tested against one question

Take a question an analyst genuinely asks and watch four of the five fire at once.

"Look at this account's activity around the alert and tell me whether it was compromised."

Estate knowledge. Whether this activity is unusual depends on what this account normally does, which is a fact about Northgate. The model will answer in terms of what accounts generally do when compromised, which is a different question that resembles the one asked.

Negative claims. If the answer contains "no signs of lateral movement", it means the material provided contained none. Whether any exists is a question about data that was never in the conversation.

Arithmetic. If the answer contains "seven failed attempts", that figure was generated rather than counted, and seven is exactly the kind of number nobody challenges.

Self-assessment. If you ask how confident it is and get "high confidence given the evidence", you have learned about the phrasing of your question.

Accountability. If you close the alert on that basis and it was wrong, the incident review has one person in it.

The useful move is not to abandon the question. It is to decompose it into the parts the tool is good at. "Write me a query showing every authentication for this account in the 48 hours around the alert, including non-interactive" is translation, checkable in seconds, and it produces the evidence you will judge yourself.

Why a better model does not move this line

It is worth being precise, because the improvement curve is real and the inference people draw from it is wrong.

Models are getting better at every task in the previous sub. Translation is more accurate, recall is broader, drafts need less editing. That trend is genuine and it will continue.

None of it touches the five categories here, because none of them is limited by capability:

• Estate knowledge is limited by access. The information is not in the model and no amount of reasoning conjures it.
• Negative claims are limited by logic. You cannot establish absence from a sample, and a more capable system reasoning over the same sample has the same problem.
• Arithmetic over evidence is limited by mechanism. Generating a number and counting are different operations, and tool use fixes it by handing the counting to something that counts, not by making the generation better.
• Self-assessment is limited by introspective access, which is not a capability the architecture provides.
• Accountability is limited by what accountability means, which is a fact about organizations rather than about software.

This is why the boundary is stable and worth learning once. A course teaching prompting techniques ages badly because the techniques stop mattering as models improve. A course teaching where the line falls does not, because the line is drawn by the mechanism.

The one it cannot do at all

Everything above is a weakness with a workaround. This one is different in kind.

It cannot be accountable.

When a decision turns out to have been wrong, someone has to explain why it was made, on what basis, and what will change. That person needs to have understood the reasoning at the time, not to have received it. An assistant can produce reasoning; it cannot hold it, defend it under questioning, or carry the consequence of it.

This sounds like a legal point and it is an operational one. Accountability is what makes a decision reviewable, and reviewability is what lets an organization learn from an incident rather than merely survive it. A decision nobody can explain is a decision nobody can improve.

The three honest uses

Everything in this course reduces to three patterns that hold up on a real shift.

Expression. You know what you want; the assistant produces it in the required form. A query, a rule, a report paragraph, a regex. Verification is cheap here because you can check the output against your own intent, which you have.

Orientation. You are looking at something unfamiliar, and you want a fast map of what you are seeing before you commit time. An unknown log format, a service you have not met, a binary's imports. The assistant gives you a starting hypothesis. You treat it as a hypothesis, and the whole value is in reducing the time before you know what to check rather than in the answer itself.

Recall. You half-remember something. Which event ID covers this, what the difference is between two similar fields, which of three commands takes the argument you want. The assistant is faster than searching documentation and wrong often enough that you confirm anything you are about to act on.

Notice what is not on that list: conclusion. No pattern above ends with the assistant deciding anything. Every one ends with you holding an artifact you now have to check, and the checking is the subject of the next nine modules.

The three uses, applied to one alert

Take a single alert and watch all three appear inside ten minutes, because in practice they interleave rather than arriving in turn.

An alert fires on k.foster@ne.com: a failed sign-in at 14:15 on 5 March from an address in Frankfurt, against an account whose entire history otherwise sits in Manchester.

Recall, at the start. You want to know which column records why a sign-in failed, and whether the numeric code distinguishes a wrong password from a locked account. You half-remember it. Asking is faster than opening documentation, and the answer costs nothing to confirm because the next query either finds the column or does not.

Expression, immediately after. You know exactly what you want: every sign-in for that account around that time, with the address, the application and the result code. You could write it. It would take four minutes and you would check the column names twice. You describe it instead and get it in four seconds, and you can check it against your own intent because you knew what you wanted before you asked.

Orientation, when it gets unfamiliar. The address is not one you recognize. You ask what is typically hosted there and get an answer that sounds authoritative. This is the one to hold at arm's length. It is a claim about the world with no grounding in your tenant, and the correct next step is not to believe it but to ask your own data whether that address has appeared before, and against which accounts. In this estate it has: the same address ran a spray across the tenant, and that fact is in your logs rather than in any model's training data.

The pattern is worth noticing: the assistant was most useful where you knew the most, and least trustworthy where you knew the least. That is the inverse of what you want from a tool, and it is precisely why verification cannot be optional.

The same alert, as an exchange

Here is the expression step from that afternoon, exactly as it happened.

SigninLogs
| where UserPrincipalName == "k.foster@ne.com"
| where TimeGenerated between (datetime("2026-03-05T00:00:00Z") .. datetime("2026-03-06T00:00:00Z"))
| project TimeGenerated, IPAddress, AppDisplayName, ResultType
| sort by TimeGenerated desc

Four seconds, and it is correct. Notice why you can tell it is correct: you specified the account, the day, the four fields and the ordering, so every clause maps to something you asked for. Verification here is reading your own request back.

That is the expression case at its cleanest, and it is the majority of what these tools are for.

Where the time actually goes

It is worth being concrete about the saving, because the honest number is smaller than the marketing and larger than the sceptics allow.

On the alert above, the assistant saved perhaps six minutes of query-writing and documentation-checking. It saved nothing at all on the parts that took longest: deciding that a single failed sign-in from an unfamiliar country was worth pursuing rather than closing, knowing that this estate has a partner VPN whose egress produces foreign addresses weekly, and recognizing that the address belonged to a spray that touched twenty accounts, which is a fact about your tenant and not about the address.

Six minutes on a forty-minute investigation is a real saving and it is not a transformation. Where it compounds is volume: six minutes across thirty alerts a shift is three hours, and three hours is the difference between clearing the queue and carrying it. That is the honest case for these tools, and it does not require anyone to claim the analyst has been replaced.

The case falls apart the moment the six minutes are bought by skipping the check, because a single missed intrusion costs more than a year of saved minutes.

The four verbs

Everything above is a description of a boundary. What a practitioner needs is a way of working, and the same four steps appear in every task in this course, whatever the discipline.

SCOPE is where most bad outcomes start. A question that cannot be answered well produces an answer that cannot be checked, and the previous section is the test: is this expression, or determination?

DELEGATE is the split. Rarely all or nothing. A task that looks undelegatable is usually a bundle whose parts mostly are.

PROVE is where the six failure modes live, and it is the reason most of this module exists. It is also the step people skip, because it is the only one with no immediate reward.

OWN is the one nobody teaches. Whatever produced the first draft, the finding is yours, and an incident review will ask what you checked rather than what you were told.