When your own company’s AI agent is hacked, who is liable?

When your own company’s AI agent is hacked, who is liable for what happens next? This is a question I expect to hear much more often as companies give AI agents access to internal systems, business applications, customer data and, increasingly, the ability to take actions without a human approving every step.

ENISA’s new Threat Landscape 2026 gives us a good reason to start thinking about this now. The report analyses cyber incidents and events observed across the EU during 2025 and identifies a dual role for AI. Threat actors are increasingly using AI to facilitate their activities, while AI systems themselves are becoming targets for exploitation. ENISA also points to the integration of AI into business environments as an expansion of the attack surface.

The wider numbers are also relevant. ENISA recorded more than 48,000 newly identified vulnerabilities in 2025, a 22% increase from the previous year. Ransomware remained the most impactful cyber threat in the short term, while 73% of the targeted organisations analysed by ENISA were entities falling within the NIS2 definition of essential or important entities.

We are also beginning to see incidents driven by AI agents that make the discussion much less theoretical. On 14 September, the Spanish data protection authority, the AEPD, reported what it described as the first notification of a personal data breach caused by an attack executed through an AI agent. According to the authority, the agent autonomously searched for vulnerabilities, modified personal data and accessed invoices. The AEPD was careful to point out that one notification does not establish a broader trend, but the case is interesting for a different reason: the AI agent itself became part of the incident.

We are also seeing the other side of the problem. Security researchers have reported cyber operations in which AI agents were used to conduct reconnaissance, exploit vulnerabilities and move through compromised environments with considerably less human intervention than a conventional attack. The significance for companies is not simply that attackers can use AI. It is that the speed and autonomy of an attack can change the amount of information available to the victim when the regulatory assessment has to be made.

This creates a scenario that I think companies need to consider now:

• A company deploys an AI agent for its own organization that can search internal documents, access business applications, interact with suppliers, retrieve information from databases or execute tasks on behalf of employees;
• An attacker hacks that agent. The AI agent remains inside the company’s environment, but somebody else is now influencing its instructions, credentials or behaviour.
• What shall the company that is the target of the cyber attack do? The company needs to understand what the agent was authorised to do, which systems it could access, what instructions it received, what it actually did after the compromise and whether it accessed or altered personal or commercially sensitive information.

That can produce several regulatory questions at the same time. Below I tried to address the most relevant, we will see more scenarios emerging over the coming months with the likely spreading of this type of cyber attacks.

1. The EU AI Act

The AI Act does not have specific provisions addressing AI agents. The legal analysis depends on the AI system, its intended purpose and the role of the company involved.

For high risk AI systems, however, the Regulation contains a specific serious incident regime. Article 73 requires providers to report serious incidents to the relevant market surveillance authority once the causal link with the AI system has been established, or there is a reasonable likelihood of such a link. The ordinary deadline is no later than 15 days after the provider or, where applicable, the deployer becomes aware of the serious incident, with shorter periods for certain serious incidents.

That creates an interesting problem when an AI agent has been compromised. The company may know that the agent has been hacked before it knows what the agent actually did. It may still be investigating which systems were accessed, whether personal data was involved and whether the agent’s behaviour was altered. The technical investigation and the regulatory assessment therefore need to develop together. This also raises questions around the cybersecurity measures applied to the AI system, its monitoring, its access rights and the evidence available to demonstrate what happened.

2. GDPR and NIS2

If the compromised agent can access personal data, the GDPR data breach assessment can start very quickly. The AEPD case illustrates the point. An AI agent allegedly accessed and modified personal data during the attack, making the incident a personal data breach rather than simply a cybersecurity event. The difficult question may then to determine when the company became aware of the personal data breach. A company can know that its AI agent has been compromised while still having no idea how many records it accessed or whether information was extracted.

For organisations within the scope of NIS2, there may be a separate incident reporting assessment. This can create another regulatory clock while the forensic investigation is still developing. I recently looked at this problem in First AI Agent Data Breach Notification: What Does It Mean for Incident Response?, where I considered why the legal assessment cannot simply wait for the final forensic report.

3. DORA

For financial, banking and insurance entities, DORA can add another layer. A compromised AI agent could be part of an ICT service or support a business function, and the relevant question may therefore be whether the incident qualifies as a major ICT-related incident under DORA. The issue becomes particularly interesting where the AI agent has access to systems supporting critical or important functions. The financial entity will need to understand what happened to the ICT environment, whether the relevant thresholds have been reached and what information can be provided to the competent authority while the investigation continues.

This is one of those situations where the technical description of the incident and the legal classification of the incident can evolve at different speeds.

4. The Cyber Resilience Act

The CRA creates another potential layer where the AI functionality forms part of a product with digital elements within its scope. The CRA reporting obligations became applicable on 11 September 2026. For relevant actively exploited vulnerabilities and severe incidents affecting products with digital elements, manufacturers have to use ENISA’s Single Reporting Platform and comply with the applicable reporting deadlines. That means that where an AI agent is embedded in a product, the company may have to consider whether the compromise is also a CRA incident. The answer will depend on the product, the vulnerability, the role of the company and the circumstances of the incident.

I discussed this from the perspective of the gambling industry in The Cyber Resilience Act for gambling operators and suppliers, because suppliers are likely to become particularly important when AI functionality is integrated into products and platforms.

5. The Data Act

The Data Act is different. It does not create a general reporting obligation for a hacked AI agent. It can nevertheless become relevant where the agent operates in or around a connected product or related service. The Data Act regulates access to data generated by connected products and related services and imposes requirements that can affect the way products are designed and how data is made available. This can become relevant to the security architecture of an AI enabled product, particularly where an agent can access or process product data.

I covered the practical implications in Data Act Access by Design: What Changes for Connected Products.

The interaction between the Data Act, CRA and AI Act is something I expect to see much more often in technology investigations because the same product architecture can potentially engage all three regimes.

Liability for damages in Italy

The question becomes even more interesting when we move from regulatory exposure to liability for damages.

Italy has recently introduced specific procedural rules for civil claims concerning damage caused by AI systems. The new regime provides mechanisms for obtaining evidence concerning the functioning of an AI system, including documentation relating to the AI Act, risk management and human oversight. This matters because an incident involving a compromised AI agent may eventually be examined by a court that wants to understand not only what the attacker did, but also how the company designed, monitored and controlled the AI system.

The Italian rules also introduce a presumption concerning causation in certain cases involving violations of AI Act obligations, subject to contrary proof, while compliance with the AI Act does not automatically exclude liability. This makes the evidence generated during incident response particularly important. The logs, permissions, instructions, monitoring records and human oversight arrangements may become relevant well after the cybersecurity team has contained the attack.

I discussed the broader Italian liability implications in AI Criminal Liability in Italy: What Boards Must Know Now.

What to do in case of a cyber attack caused by an AI agent?

In my experience, the best incident response work starts before the forensic cyber investigation is complete. With AI agents, this becomes even more important. If an agent is compromised, the company needs to understand its permissions, preserve its logs and instructions, identify the systems it could reach and establish what it actually did. Legal needs to be involved while those questions are still being investigated because the regulatory assessment may already have started.

There is also a governance question:

1. Who owns the AI agent?
2. Who can stop it?
3. Who can revoke its credentials?
4. Who decides whether its behaviour constitutes a serious incident?
5. Who assesses GDPR, NIS2, DORA, CRA and AI Act exposure?
6. And who preserves the evidence that may later be needed to demonstrate that the company acted appropriately?

I do not think these questions should be answered for the first time during a cyber attack. On the contrary, the company’s AI governance framework shall provide that the AI Committee fills in this checklist once it approves the adoption by the company of the AI agent. Besides, the incident response procedures adopted by the company under the GDPR, NIS 2, DORA and CRA shall cross reference to the AI governance framework and have a dedicated section to address this type of incidents. These procedures shall also be tested, validated by the company and part of a dedicated training so that the company is ready to react in case of cyber attack.

What companies should do now

I would therefore recommend a specific set of practical steps:

1. Identify the AI agents actually operating inside the organisation. This needs to include agents embedded in third party software, not only systems developed internally. The company should know what each agent can access, what actions it can perform and who owns the relationship with the provider. These types of agents might originate also by means of AI systems previously adopted by the company such general purpose AI systems. The company shall 1) adopt a procedure requiring the approval by the AI Committee of any newly adopt AI agent; 2) map any AI agent used by the company and 3) monitor their exploitation and their evolution;
2. Define the boundary between autonomy and authorisation. If an agent can execute an action without human approval, the company should know exactly which actions those are and who has the power to stop the agent. Human oversight is needed for high risks AI systems, the level of oversight is proportional to the risk of the potential AI system, in any case the company needs to bel able to justify the conduct of the agent which requires to run stringent test before the release of the AI agent within the production environment. 
3. Review access rights and credentials. An AI agent should not have broader access simply because broader access makes automation easier. The recent Spanish AEPD case makes this particularly relevant because the agent allegedly obtained access to personal data during the attack. This point is crucial, the approach adopted so far in relation to access rights where they were granted with a sort of “relaxed approach” just because some data “might” be useful for a working activity can no longer be applied in an environment where AI agents are exploited.
4. Make the incident response plan AI aware. The plan should identify who investigates the agent, how its logs and instructions are preserved, how credentials are revoked and who makes the regulatory assessment. This process shall not only explicitly provided by the procedures adopted by the company under the regulations referred above, but also be tested so that inefficiencies are identified and the company is ready to react.
5. Map the regulatory clocks before the incident occurs. GDPR, NIS2, DORA, the AI Act and CRA have different scopes, triggering events and deadlines. The legal team should know how the different assessments will be coordinated and be able to involve the different stakeholders. Besides, the IT and cybersecurity departments shall also be trained and aware of their reporting obligations. With these new pieces of legislation in place, it is no longer just a question of whether personal data were impacted, the scope of reporting obligations is much broader.
6. Review the product architecture against the Data Act and CRA. Where AI is integrated into a connected product, the security, data access and product compliance questions should be considered together. These legislations are product specific which makes accountability obligations more burdensome to handle, and the reporting obligations are already in place for both old and new products.
7. Preserve the governance evidence. Documentation concerning risk management, human oversight, monitoring and the operation of the AI system may become relevant in regulatory investigations and damages proceedings. The risk is higher in countries like Italy which have a more stringent liability regime for criminal and civil claims, but it applies in any jurisdiction. 

I would also test these arrangements through a tabletop exercise involving a compromised AI agent. A simulation is always crucial to identify gaps and required improvements. The exercise should start with an alert that an AI agent has been hacked and force the company to make decisions while the technical facts are still incomplete. The checklist shall include the following:

1. Who takes control?
2. What evidence is preserved?
3. When does Legal become involved?
4. Which regulatory regimes need to be assessed?
5. Who decides whether a notification is required?

Those questions will tell you much more about the quality of your AI governance than another policy document sitting in a folder.

ENISA’s message is becoming difficult to ignore. AI is being incorporated into the cyber threat environment, while the integration of AI into companies is creating new attack surfaces. For companies using AI agents, I think the next step is therefore quite practical.

If your own company’s AI agent were hacked tonight, would your incident response plan tell you who takes control, what evidence needs to be preserved and which regulatory regimes need to be assessed?