# AI Attacks Use Familiar Techniques but Outpace Old Defenses

Security marketing has settled on a convenient story: AI-powered attacks are unprecedented and demand an entirely new category of defense. It is a good pitch. It is also mostly wrong.

Cyberattacks have relied on software for decades. Worms, botnets, exploit kits, credential stuffing tools, and automated scanners operated at machine speed long before anyone added the word “AI” to a threat report. Skilled operators could already observe what worked, adjust their approach, and try again. None of that is new.

What has changed is the combination of humanlike adaptation, machine speed, massive parallelism, persistent operation, and falling marginal costs. The mechanics of an attack remain familiar. Its economics and pace do not.

## Automation was never the interesting part

Traditional attack automation follows logic that is largely fixed in advance. A scanner checks a list of known vulnerabilities. A botnet executes a scripted sequence. A credential stuffing tool works through a list. The branches are predetermined. Change the environment enough, and the tool stops working until someone rewrites it.

An attacker using AI works differently. Give the system an objective, and it can inspect the environment, choose an action, interpret the result, and revise its approach. It can repeat that cycle continuously instead of adapting only at points a developer anticipated. AI is beginning to automate the attacker’s decision loop: observe, interpret, act, evaluate, and adapt.

Human attackerTraditional automationAttacker using AIAdaptabilityHighLow, with predetermined branchesHighScalabilityLow because of limited parallelismHighHigh, with parallel adaptationDecision speedHuman speedFast but scriptedContinuous at machine speedThat capability is still emerging. Current AI systems cannot run every stage of a sophisticated intrusion without supervision. Reconnaissance, phishing, exploitation, credential abuse, privilege escalation, lateral movement, and exfiltration have not changed. What is improving is the amount of reasoning between those stages that can happen without a person in the loop.

## Is this just speed?

Largely, yes. That is why it matters.

A sufficiently skilled person could already do most of what an attacker using AI can do. Speed, scale, and cost still determine which defenses hold up in practice.

If an intrusion that once took days now takes minutes, a defense built around [analyst triage](https://logmanager.com/learn/what-is-triage-in-cybersecurity/), escalation, and manual approval can fail even when it produces the correct alert. If one operator can supervise thousands of adaptive campaigns instead of running a single campaign by hand, organizations that once offered too little return can become worthwhile targets. Scale increases the number of attacks and expands the range of attractive targets.

AI may not create fundamentally new attacks, but it can shorten the attacker’s feedback loop enough to defeat defenses designed for an adversary moving at human speed.

## Your sensors still see the activity

One point often gets lost in claims that everything must change. EDR, NDR, IAM, and [SIEM systems](https://logmanager.com/learn/what-is-a-siem-tool/) do not care whether a decision came from a person, a script, or a model. They record the resulting action.

Process execution. Credential access. Authentication events. Privilege changes. Lateral movement. Unusual network connections. Access to sensitive data. Exfiltration. Regardless of what chose the action, it still appears in telemetry.

AI does not inherently blind existing sensors. Claims that it does deserve skepticism. Context, however, needs to improve. Defenders must understand sequences, identities, and relationships across endpoints, networks, cloud services, and applications instead of treating each alert in isolation. Signatures and standalone alerts become less useful when a fast, adaptive attacker produces a pattern across several systems. That pattern requires stateful, behavioral detection. It does not require a chatbot on top of the SIEM or wholesale replacement of existing sensors.

## Response, not detection, is the real bottleneck

Consider a plausible timeline:

- **Minute 4:** Suspicious activity occurs and appears in telemetry.
- **Minute 12:** An analyst sees the alert.
- **Minute 14:** The attacker completes the objective.
- **Minute 25:** The investigation finishes.
- **Minute 35:** Containment begins.

The detection was accurate, yet the defense still failed. By the time a person triaged the alert, investigated it, and acted, the outcome had already been decided. A perfect alert at minute four has little value if the response process moves more slowly than the attack.

Detection quality still matters, but response time now deserves equal weight. Mean time to respond, decision latency, and containment design must become central design concerns.

## Why full automation falls short

The obvious response is to automate containment so that it also runs at machine speed. That approach faces a serious constraint: containing a false positive can be expensive. An automated response that isolates the wrong endpoint, disables the wrong account, or throttles the wrong service can disrupt production as effectively as the attack it was meant to stop.

A workable model is bounded, based on confidence, and reversible:

- **Low confidence:** Gather more telemetry before acting.
- **Medium confidence:** Increase [logging](https://logmanager.com/learn/log-monitoring-guide/), limit activity, or require reauthentication.
- **High confidence:** Revoke a token, restrict a session, or isolate an endpoint.
- **Critical systems:** Require human approval before taking a destructive action.

The goal is to keep people involved where their judgment matters while allowing reversible, low-risk actions to happen immediately. Reduced privileges and reversible containment are safer than indiscriminate shutdowns. Any response model that ignores the cost of false positives will fail in a production environment.

## The deeper problem is the data plane

Many SIEM deployments still depend on specialists to discover relevant sources, configure collectors, interpret proprietary schemas, write and repair parsers, normalize fields, validate ingestion, and update detections as systems change. This work involves tickets, documentation, and engineering time. It is inherently slow and cannot keep pace with a rapidly changing environment.

The result is a structural imbalance that does not depend on the sophistication of the attacker’s reasoning. An adaptive attacker can discover and interact with a new asset as soon as it appears. In many organizations, the defense team needs a project just to make that asset visible. The attacker reasons faster, but the larger advantage is that defensive visibility may trail the environment by weeks.

Detection intelligence cannot compensate for missing visibility. Before a platform can reason about a threat, it must know that the asset exists, collect the relevant telemetry, and understand what the data means. Even an excellent detection engine is effectively blind when its data is missing or misunderstood. A future SIEM must know what it can see and where its blind spots are.

## What the underlying platform must do

The platform must adapt continuously as the environment changes, without waiting for periodic integration projects. That requires six connected capabilities:

1. **Continuous environmental discovery:** Identify endpoints, identities, cloud accounts, applications, workloads, and data sources as they appear instead of waiting for a quarterly audit.
2. **Autonomous ingestion:** Connect new sources and begin collecting data without a separate integration project for each one.
3. **Semantic parsing and normalization:** Infer the meaning of fields and events, map them to a common model, and verify the mapping.
4. **Stream processing:** Enrich, correlate, and evaluate events as they arrive instead of relying on retrospective searches minutes or hours later.
5. **Coverage intelligence:** Detect missing sources, broken collectors, schema drift, and unmonitored infrastructure instead of assuming coverage is complete.
6. **Controlled action:** Allow automated workflows to investigate, configure, and contain activity within explicit permissions and safeguards that match the confidence levels described above.

These capabilities need a strong platform core: scalable multitenant storage, fast search, streaming analytics, cross-domain detection logic, reliable transformation and routing, and interfaces with granular authorization. Some of those interfaces will increasingly be designed for agents. An intelligent layer cannot rescue a weak core. It only provides a fast, confident interface to bad data.

Autonomous configuration also carries a specific risk. AI can infer a schema or generate a parser, which is useful, but mistakes can spread quickly. A wrong field mapping may quietly corrupt every downstream detection that depends on it. These changes need confidence scores, clear provenance, testing, staged deployment, and a rollback path. Without those safeguards, an inferred schema is simply an unvalidated assumption presented with confidence.

## A separate problem: attacks on AI systems

This article focuses on AI accelerating attacks against conventional infrastructure. The stages from reconnaissance through exfiltration remain the same, but they can run faster and at greater scale.

Attacks on AI systems are different. Prompt injection, poisoned retrieval content, tool abuse, and compromised agents create genuinely new attack surfaces. That category is real and growing, but it calls for a separate discussion.

## The contest is not AI versus AI

It is tempting to frame the future as AI attackers facing AI defenders, with the better model determining the outcome. The advantage will more often belong to the side that has complete visibility, understands its changing environment, processes context in real time, and can act safely at machine speed.

[Security analytics](https://logmanager.com/solutions/security-analytics/) is only as good as the data plane beneath it. With incomplete, delayed, or incorrectly normalized telemetry, even a capable model operates confidently but blindly. Knowing where visibility ends may be safer.