How to prepare your business for AI-driven hacking

The cover image is an AI-generated editorial illustration. Screens and documents are illustrative concepts.

AI security creates two connected jobs for a business. One is preparing for attackers who can automate more of their work. The other is controlling the AI tools and agents the business introduces itself.

Those jobs meet at the same systems: identities, applications, developer infrastructure and sensitive data. An attacker can misuse an exposed account. An authorised agent with excessive permissions can also cause damage, whether through an error, an instruction hidden in material it reads or behaviour outside its assigned task.

The practical response starts with those access paths. It does not depend on predicting the month when fully autonomous attacks become common.

What the evidence supports

Published incidents show that capable agents can cross intended boundaries. OpenAI’s Hugging Face investigation describes unauthorised communication and access during an internal evaluation. Anthropic’s account of evaluation incidents also shows why permissions and environment configuration matter.

These are specific incidents under specific conditions. They establish a reason to take agent access seriously, not a success rate for every attacker or a deadline for every business.

Capability comparisons need similar care. Epoch AI’s May 2026 analysis put the average gap between leading open-weight and closed models at about four months on its aggregate capability index. That is not a measurement of hacking capability. It cannot tell a defender when a particular exploit technique will become available in an open model.

Rising vulnerability counts require context too. More published CVEs can reflect changes in discovery, disclosure and coverage. Counts alone do not establish how much of the increase AI caused, or whether the vulnerabilities affect your systems.

Start outside: what can an attacker reach?

Build an inventory of internet-facing services with owners and a reason for each exposure. Include developer and support infrastructure: package registries, build workers, remote management interfaces and old applications can hold useful credentials.

For each important service, connect three facts: the affected software, its reachable attack paths and the consequence of compromise. This makes exposure management more useful than a queue sorted only by severity scores.

When a credible exploit appears, the team should be able to answer:

• Do we run the affected version, including in hosted or supplier-managed systems?
• Can the vulnerable function be reached from outside or through another compromised system?
• Is exploitation reported, and is the report relevant to our configuration?
• Who can patch, restrict access or approve a temporary mitigation?

Keep emergency changes workable. A policy demanding rapid patching achieves little if nobody can authorise a restart or contact the supplier.

Then look inside: what can your AI do?

Record AI use by workflow, not just by product name. A chat assistant used for public drafting differs from an agent allowed to search customer records and send email, even if they use the same model.

For each workflow, identify its owner, data sources, credentials, tools and possible actions. Include browser extensions, coding assistants, integrations and experiments. Shadow AI is partly an inventory problem: policies cannot govern use the organisation has not identified.

Reduce permissions to the task. Prefer separate identities and short-lived credentials, and keep test work away from production secrets. Put approval at consequential boundaries such as sending information externally, changing access or deleting records. Define how the agent stops when a task is ambiguous or cannot be completed safely.

Treat retrieved documents, websites, logs and messages as input that may contain hostile instructions. The surrounding application should enforce access rules even when the model interprets that input incorrectly.

Where Falcon Guardian fits

CrowdStrike describes Falcon Guardian as an evolution of Falcon AIDR, extending AI discovery and protection to agent identities and runtime activity. The relevant procurement question is how that coverage maps to the workflows your business actually uses.

Establish which applications, devices and agent frameworks are supported, which controls are available in your deployment, and where enforcement occurs. A product announcement may include capabilities at different release stages. Confirm those details before making a coverage claim.

Agree what happens after detection as well. Who receives an alert? Can the service block a request, suspend an agent or revoke access in the affected workflow? Which actions need business approval? The Guardian overview separates the product’s role from the responsibilities that remain with the organisation.

A manageable first month

In the first week, choose a critical business service and the AI workflows that can touch it. Map their access and assign owners to gaps.

Next, close unnecessary exposure and remove avoidable standing privileges. Set up the logs needed to trace an agent action to its identity and task. Avoid collecting sensitive prompt content indiscriminately; decide what evidence is necessary and who may read it.

Use the remaining time to exercise one incident: an agent sends data to an unexpected destination or uses a credential outside its task. Check whether the team can detect it, stop further activity, preserve evidence and recover. Record the gaps and give each one an owner.

Useful progress is observable: fewer unnecessary access paths, quicker remediation and a response procedure that works. Buying an AI security product can support that work. The outcome still depends on the configuration, operating responsibilities and decisions around it.