The most useful way to assess an AI-assisted attack may be to ask how much work one person could otherwise have completed. Spectacular demonstrations attract attention, but capacity changes can matter just as much.
Anthropic’s September threat report describes misuse it says it identified and disrupted across cyber operations, surveillance, fraud, and other categories. It emphasizes changes in speed, scale, and depth across an operation. This is the vendor’s account of activity visible to it, not an independent measurement of all AI-enabled crime.
The implication worth examining is straightforward: making routine work cheaper can expand the number of people and organizations an attacker can pursue.
The defender still has a day job
A small organization may have one person handling accounts, updates, purchasing, and support. That person cannot multiply their attention simply because an adversary can automate more preparation. A security product that adds another queue of vague warnings can make this imbalance worse.
Useful automation should reduce the work required to reach a defensible decision. Identify the affected account. Explain the evidence. Preserve a record. Make containment reversible where possible. Escalate the action that actually needs human judgment.
There is room for AI in that process. The test should be whether it reduces unresolved risk and wasted effort, not whether its summary sounds like a competent analyst.
Separate capability from prevalence
A vendor can show that someone used its system during an operation. Establishing how much the system changed the result is a harder question. An attacker might have completed the same work more slowly, used a different tool, or abandoned the effort without assistance. Those alternatives are difficult to observe directly.
That makes the counterfactual important. A claim of uplift should explain the comparison behind it. Is the evidence faster coding, more targets examined, fewer people required, or a result the operator previously could not achieve? Each would matter, but they describe different changes and imply different defensive priorities.
The same caution applies to prevalence. Notable cases selected by a vendor are not a representative sample of all attacks. They can identify mechanisms worth addressing without proving that every attacker has adopted them. Good coverage should resist turning a collection of case studies into a measurement it was never designed to provide.
Cheap preparation can change the economics
An operation includes work that is less dramatic than discovering a new vulnerability: organizing information, adapting scripts, reading documentation, and interpreting results. Reducing the cost of those steps can make attempts against smaller targets more practical. That is a plausible consequence of automation even when the underlying weakness is familiar.
For defenders, the implication is to reduce the number of routine weaknesses that require individual attention. Clear ownership of exposed services, timely supported updates, and narrow account permissions can limit what an attacker finds useful. Those practices do not depend on guessing whether a particular request came from a person or an AI-assisted workflow.
The temptation is to answer a faster adversary with a louder monitoring system. But an alert that nobody can investigate creates a record, not a response. The better investment may be eliminating an unnecessary exposed service or making a risky permission temporary. Preventing a class of opportunities can be more useful than describing each attempt after it arrives.
A security assistant should be tested for restraint
An AI tool on the defensive side also receives information and authority. If it can isolate a machine, revoke access, or change a firewall, a mistaken interpretation can interrupt legitimate work. A convincing demonstration needs to include cases where the evidence is incomplete and the correct action is to stop, ask, or escalate.
This is where NIST’s work on agent identity and authorization becomes relevant. The project examines how software agents can be identified and given appropriate authority. Its existence is not proof that a product has implemented those controls, but it identifies a practical area buyers should scrutinize.
A small organization should be able to limit a security assistant to gathering evidence before enabling more consequential actions. The product should expose its proposed change, preserve the previous state, and report whether the action succeeded. Otherwise the company is buying another system whose work must be independently reconstructed.
Put people back in the incident model
A useful response plan includes the person answering customers while technical work continues. It includes the employee whose account was suspended and needs a safe path back. It includes a decision about who can approve an interruption when the usual administrator is unavailable.
Those details rarely appear in a capability benchmark, but they determine whether an organization can absorb an incident. AI may change the speed and cost of hostile work. The quality of a defense will still depend on whether the people responsible can understand the situation and act within it.
Measure the whole response
A product demonstration should include a tired operator, incomplete information, and an ordinary service that cannot simply be taken offline indefinitely. Those are design conditions, not unfortunate edge cases.
The people affected by a compromised school, clinic, or small business rarely care how novel the attack was. They care whether records were exposed and whether the service will work tomorrow. Coverage should keep that consequence in view while evaluating claims about AI’s capabilities.