AI Is Accelerating Attacks. Can Our Defense Keep Up?

A few days ago I took part in a discussion with a company's cybersecurity team. At a certain point, the conversation stopped being about tools, SOC, vulnerabilities, or incidents and moved to a question I consider far more interesting.

AI is not just expanding certain offensive capabilities. It can compress the time of important parts of the attack cycle.

And that point changed the direction of the conversation considerably. Environment reconnaissance, code analysis, vulnerability research, script generation and adaptation, and exploitation of misconfigurations are activities that can be accelerated and, under certain conditions, partially automated with AI.

It's important not to overstate this conclusion. It doesn't mean we're facing autonomous, all-powerful attackers. Attacks still depend on access, infrastructure, knowledge of the environment, exploitation opportunities, and countless other conditions. Nor does it mean that cybersecurity fundamentals have become obsolete.

In fact, my perception is almost the opposite. AI makes some old fundamentals even more important. Cybersecurity has used automation for many years. EDR, XDR, SOAR, behavioral detection, and automated responses didn't start with generative AI. So it would be incorrect to say that defense has always operated exclusively at human speed.

The problem lies in processes that still heavily depend on people. Triage, investigation, contextualization, prioritization, approval, and remediation frequently have human steps. If the offensive side can accelerate reconnaissance, correlation, and experimentation, the pressure on those intervals increases.

That's when someone on the team summed up the problem very well. The attacker needs to find one path. The company needs to know and control many possible paths. Applications, APIs, identities, cloud, databases, SaaS, devices, vendors, legacy systems, and now copilots and agents form a dynamic surface. What we don't know, we can hardly protect adequately.

That's why periodic inventories are still necessary, but they're no longer enough for environments that change continuously. A quarterly snapshot can be partially outdated shortly after it's produced. We need to move toward a more continuous view of assets, identities, dependencies, configurations, and exposure.

But a second issue came up. For a long time, vulnerabilities were prioritized mainly by characteristics like technical severity. That's still useful, but it doesn't tell the whole story.

A seemingly moderate vulnerability can take on a different dimension when combined with an overprivileged identity, an exposed API, a misconfiguration, lack of segmentation, and access to a critical asset.

AI can help both attackers and defenders analyze these combinations more quickly. The unit of analysis, therefore, shouldn't be just the isolated vulnerability.

We also need to understand possible attack paths. Which assets are connected. Which identities can reach them. What privileges they have. What controls exist along the way. What the real exploitability is. And what the business impact would be if that sequence could be traversed.

But the part I consider most interesting in the discussion came up when we stopped talking only about the AI used by the attacker and started looking at the AI we ourselves are putting inside companies.

While we use AI to strengthen cybersecurity, we're simultaneously introducing new surfaces and new trust relationships through AI itself.

A corporate chatbot that just queries documents already requires controls. An agent connected to email, databases, APIs, ERP, CRM, development tools, or cloud infrastructure belongs to a different risk category.

In this scenario, prompt injection is still prompt injection. What changes is the possible consequence. A manipulation that in a chatbot would produce an inadequate response can, in a system with tools and excessive privileges, contribute to improper data access or unauthorized actions.

OWASP already explicitly treats content coming from pages, documents, emails, and tool responses as potentially untrusted, and recommends that authorization and validation of actions be carried out by components external to the model.

I consider this point fundamental. Information is not instruction, and instruction is not authorization.

An email can contain a malicious instruction. The model may interpret it as an instruction. But the architecture shouldn't allow that interpretation to automatically turn into authority to execute a privileged action.

Authorization needs to exist outside the LLM. This is where cybersecurity and agent architecture start to converge.

Agent identity, the identity of the user on whose behalf it acts, least privilege, short-lived credentials, segregation of duties, allowlists of tools and destinations, deterministic validations, sandboxing, observability, approval for higher-consequence actions, reversibility, and kill-switch mechanisms stop being implementation details. They become part of the agentic system's security architecture.

And there's an important subtlety. Even putting a human in the loop doesn't automatically solve the problem. If the person receives dozens of approval requests, doesn't fully understand the proposed action, or simply starts trusting the agent after hundreds of correct decisions, we may just be shifting automation bias to the authorization screen. The security of the approval mechanism itself needs to be designed. OWASP already documents attacks aimed precisely at manipulating this last stage of human authorization.

The conversation then reached another inevitable point. If certain offensive steps can be accelerated by machines, a defense that relies exclusively on human queues at every step will struggle to keep up.

That doesn't mean handing cybersecurity over to autonomous agents. It means architecting different levels of autonomy. Temporarily blocking a credential in the face of sufficiently strong evidence, isolating an endpoint, limiting privileges, or blocking a connection known to be malicious can allow for automated responses, as long as there are adequate criteria, limits, telemetry, and the possibility of reversal.

Other actions have high enough impact, ambiguity, or irreversibility to require human intervention. Automation doesn't mean the absence of control. Well designed, it means executing controls at a speed compatible with the risk.

By the end of the conversation, I was left with a very different perception of the relationship between AI and cybersecurity. For a while, we simplified the discussion by imagining a race between “attacking AI” and “defending AI”.

Reality seems more complex to me. AI can increase the speed and scale of certain activities on both sides. At the same time, companies themselves are creating environments that are more dynamic, interconnected, and harder to understand. And agents add an especially important variable. Authority.

Incomplete inventory, overprivileged identities, forgotten APIs, delayed patches, permanent credentials, misconfigurations, vulnerable dependencies, and poorly monitored vendors have always been problems. And they still are.

AI hasn't made these fundamentals obsolete. It can increase the speed at which their weaknesses are discovered, combined, or exploited.

That's why I left that discussion thinking that the next phase of cybersecurity won't simply be a contest between machines attacking and machines defending.

It will be a contest between the speed at which exposure arises and the speed at which we manage to discover it, contextualize it, prioritize it, and reduce it.

And, with agents, I'd add one more dimension. It's not enough to know what the machine can do. We need to rigorously control what it's authorized to do when no one is watching.