When attackers move at machine speed, what changes for the business?

Most organizations have spent the last few years thinking about AI as something they need to adopt, govern, and learn how to use responsibly. There is another side of that conversation that deserves more attention.

What happens when the organization on the other side of the attack is using AI too?

Two security reports from Microsoft last week provide an interesting glimpse into that question. And what caught my attention wasn't simply that attackers are using AI. That seemed inevitable.

It was the speed.

In one case, Microsoft observed an AI agent go from discovering exposed credentials in a public GitHub repository to exfiltrating data from Azure Key Vault in five minutes.

A day later, Microsoft reported that a financially motivated threat actor was using an agentic offensive framework called ARTEX alongside more traditional cyber tools. Microsoft described compromised credentials and systems being used "at machine speed” to move through environments, escalate privileges, and steal data.

Neither report means every organization is suddenly facing autonomous cyberattacks. But I do think they expose an assumption built into many of our security and operating models:

We assume people will have enough time to respond.

That assumption is starting to look less comfortable.

Our processes were built for a different pace

Think about what normally happens when something suspicious occurs inside an organization.

A security system generates an alert. Someone investigates it. If the activity looks serious, the issue gets escalated. Someone determines what happened, assesses the risk, and decides what action to take. Accounts may be disabled, credentials rotated, systems isolated, and leadership notified. Maybe you're even running an AI-powered SIEM or SOAR solution to help.

That's a perfectly reasonable process when there is enough time for the process to work.

But five minutes changes the equation.

If an attacker can discover an exposed credential, authenticate into an environment, identify valuable assets, and begin extracting data before the first escalation is complete, the problem is no longer simply whether your security tools can detect the activity.

The problem becomes whether your organization can make and execute decisions quickly enough to matter.

That takes cybersecurity beyond the security team. It becomes an operating-model question.

Where are we comfortable allowing systems to act automatically? Which decisions still require human approval? What risks require immediate containment? Who has the authority to define those rules?

Those are leadership decisions that happen to be implemented through technology.

Some decisions have to happen before the incident

This is probably the biggest implication for executives.

For years, we've invested heavily in giving organizations greater visibility. More telemetry. Better monitoring. More sophisticated alerts. Better threat intelligence.

All of that still matters. But visibility and response aren't the same thing.

• If an attack can progress in minutes, simply telling a person that something bad is happening may not be enough. Some portion of the response needs to have been decided before the incident occurs.

• If a sign-in carries enough risk, should access automatically be challenged or blocked?

• If an application's credentials appear compromised, should its permissions immediately be restricted?

• If unusual behavior occurs around sensitive data, should the system wait for someone to investigate or take a predefined containment action first?

There isn't one universal answer. A hospital, manufacturer, financial institution, professional services company, and retailer are going to have different tolerances for disruption and different consequences if an automated response gets something wrong.

But leadership should be deciding where those boundaries sit.

Because at machine speed, "we'll evaluate it when it happens” is itself a risk decision.

We also need to rethink who, or what, has access

There's another dimension to this that I think is going to become increasingly important as organizations deploy more AI.

We traditionally think about identity in human terms.

Which employee can access the financial system? Who can see customer information? Who can administer our cloud environment? What happens when someone changes jobs or leaves the company?

But organizations already have thousands of identities that aren't people. Applications, services, automations, integrations, and increasingly AI agents all have identities and permissions of their own.

That creates a slightly different governance question.

Not simply:

Who has access to our information?

But:

What has access to our information, and does it still need that access?

An application or agent doesn't need to be malicious to create risk. It simply needs to have more access than its job requires and expose credentials that someone else can steal.

That's why concepts like least privilege become strategically important rather than merely technical housekeeping. Every unnecessary permission expands what a compromised identity can potentially reach.

As companies introduce more agents and automation, I think governing these non-human identities needs to become part of the broader AI governance conversation.

AI governance has to look outside the organization too

Most AI governance programs understandably focus inward.

What AI tools are employees allowed to use? What company information can those systems access? Which models are acceptable? Who approves AI use cases? Where do we require human oversight?

Those are all good questions.

But they're based on the AI we choose to deploy.

The Microsoft reports are a reminder that there is another category of AI we need to prepare for: the AI we don't control.

That doesn't mean AI governance suddenly becomes the security team's responsibility. I think it means the opposite. AI governance, cybersecurity, identity, risk management, and business continuity are becoming more connected.

The same organization that is asking where AI agents can operate internally should also be asking whether its security architecture can withstand autonomous systems operating externally.

That's a broader leadership conversation.

The answer can't be people trying to move faster

There is an instinctive reaction to cyber risk that says we need better monitoring, stronger processes, and faster response from our teams.

Yes, but there is a practical limit.

I don't think the long-term strategy can be asking people to manually outrun machines.

If attackers are increasingly using automation and AI to identify vulnerabilities, test paths, exploit credentials, and move through environments, organizations will need more automation and AI on the defensive side as well.

That doesn't mean removing human judgment.

It means being more deliberate about where human judgment creates value.

Machines are good at correlating large numbers of signals, identifying patterns, enforcing predefined policies, and taking immediate action. People are better equipped to interpret ambiguity, understand business context, weigh consequences, manage exceptions, and decide what level of risk the organization is willing to accept.

The goal isn't to automate every security decision.

It's to make sure a person isn't the bottleneck for decisions that needed to happen three minutes ago.

This is ultimately a readiness question

None of the underlying security principles here are revolutionary.

Protect credentials. Limit access. Monitor identity. Automate appropriate responses. Assume credentials may eventually be compromised. Build defenses that slow attackers down.

• What's changing is the consequence of not doing those things well.

• When attacks operate at human speed, a slow response process is inefficient.

• When attacks operate at machine speed, a slow response process may simply be ineffective.

And that's why I think executives should resist turning this into another conversation about a new cybersecurity tool or another category of AI risk.

The better conversation is about readiness.

What parts of our organization could an automated attacker reach today? Which applications, services, and agents have access to sensitive information? Where are we relying on a human response where the machine may already have a five-minute head start? And which decisions could we responsibly make in advance?

Those aren't questions executives need to answer technically.

But they are questions leadership needs to make sure someone can answer.

Because as the speed of attack changes, the operating model on the defensive side has to change with it.

The question I would bring to the next leadership or risk conversation is pretty simple:

If an attacker could move through part of our environment in five minutes, what would happen automatically before one of our people had time to respond?

The answer will tell you quite a bit about how ready the organization actually is.