AI agents and responsibility: who controls artificial intelligence? Who answers for its actions?

At a glance

In brief

• An AI agent does not only produce information: it can carry out operations with direct economic, technical, organisational or legal consequences.
• Since 12 October 2026 Google Cloud's Service Specific Terms (section 20(n)) state that the customer is "solely responsible" for every agentic action, while Google's guidelines acknowledge the operational risks of agents.
• A contractual clause alone does not settle the question: the complete contract, the applicable law, the facts and the available evidence all matter.
• The first precedents mostly concern chatbots, privacy and automated access. The only decision directly about agents, Amazon v. Perplexity, has a limited scope.
• In Europe the AI Act is not a general regime of civil liability, and the directive on defective products, which includes software, must be transposed by 9 December 2026.
• MC Project Lab's thesis is that responsibility should be assessed on effective control, conduct, foreseeability of risk and causal contribution to the harm. Practical measures for businesses are in section 19.

Summary

Executive summary

The artificial intelligence market is changing in a substantial way. AI systems no longer limit themselves to generating text, images, analysis and code: agents can use tools, access systems, modify data, run programs, start operations and coordinate other agents. The shift from generative AI to agentic AI changes the relationship between technology providers, businesses and users, because a chatbot error produces an inaccurate piece of information whose consequences depend on how it is used, while an agent error can directly cause an economic, technical, organisational or legal consequence.

A precise question follows.

When an AI agent takes a harmful, unexpected or unauthorised action, who is responsible?

It may be the model producer, the platform provider, the developer of the application, the business using the system or the user who gave the instructions, and in many cases the answer involves several parties together.

Google Cloud's update to its terms on 12 October 2026 makes the problem particularly visible. In its guidelines Google acknowledges the operational risks of agents, but in the specific contractual terms it attributes broad responsibility for their actions to the customer. The phenomenon concerns the whole market, from OpenAI to Anthropic, from Microsoft to Amazon Web Services, from Meta to Mistral AI and many other operators. In the meantime, authorities and courts are starting to deal with disputes over AI-generated information, data protection, automated access and the consequences of using autonomous systems.

MC Project Lab's thesis is that responsibility should be assessed by considering effective control, the conduct of the parties involved, the foreseeability of risks and the causal contribution to the harm. This is an editorial and governance position, not a universal legal rule that is already settled.

The dossier examines the Google Cloud case in detail, and the original contract text was read. For the other providers it describes the general framework and refers to the terms indicated in the sources, which should be read in full before making a decision.

1From generative AI to autonomous agents

1.1 The transformation

The first commercial phase of generative AI was characterised by the production of content. The current phase introduces systems capable of carrying out operations. A chatbot can explain how to edit a document, while an agent can edit it directly. A model can suggest how to update a database, while an agent can connect to the system and run the update. An assistant can propose a commercial strategy, and an agent can interact with business tools to carry out some of its activities.

AI can therefore produce operational consequences as well as information.

1.2 Levels of autonomy

Agents can be described according to their degree of autonomy.

• Assisted agents: propose operations that require human confirmation.
• Semi-autonomous agents: carry out activities within predefined authorisations and limits.
• Autonomous agents: plan and carry out sequences of operations without confirmation at every step.
• Multi-agent systems: coordinate several AI components with different roles, tools and operational responsibilities.

These categories are descriptive and are not uniform legal classifications.

1.3 Economic consequences

Autonomy creates opportunities for productivity and innovation, but it brings risks linked to unexpected costs, unwanted operations, dependence on providers and difficulty of supervision. Control over authorisations and resources therefore becomes an integral part of managing the economics of the service.

2The value and responsibility chain

The market includes parties operating at different levels, and the table shows the main ones.

An incident can involve several levels at the same time, and a technology chain this articulated makes it necessary to distinguish the contribution of each party. Attributing all responsibility in advance to the producer or to the user would not be correct, because the assessment depends on the facts, the applicable obligations and the available evidence.

3Why providers change their contracts

Agent autonomy increases the risk that AI services cause direct consequences. Contracts try to regulate the parties' obligations in advance and to distribute risk, and to read them it helps to distinguish four concepts.

• Contractual liability: the consequences of breaching assumed obligations.
• Non-contractual liability: the consequences of unlawful acts under the applicable law.
• Indemnity: an obligation, within the limits provided, to hold a party harmless from certain claims or consequences.
• Limitation of liability: a clause that delimits categories or amounts of recoverable damages, within the limits allowed by law.

These instruments are not equivalent. An indemnity relating to intellectual property is not automatically a coverage for damage caused by an agent, and a clause that assigns obligations to the customer does not show that any incident is attributable to the customer's conduct.

Central case

4Google Cloud: the central case

4.1 The update of 12 October 2026

Google Cloud has updated its terms and introduced guidelines dedicated to the responsible use of AI agents. To understand the scope of the changes, two documents must be kept apart, the guidelines and the contractual clause.

4.2 The guidelines

The Google Cloud Agentic AI Responsible Use Guidelines address risks relating to security, privacy, unauthorised access, use of tools and unexpected behaviour. Google acknowledges in them that agents may act differently from the instructions they receive and may be vulnerable to external attacks, including prompt injection. It strongly recommends human supervision and explicit approval mechanisms, in particular for critical or consequential decisions and actions. The guidelines present themselves as non-exhaustive indications meant to align the use of agents with the Acceptable Use Policy, the Generative AI Prohibited Use Policy and the Terms of Service. The clause that assigns responsibility to the customer is not in this document but in the Service Specific Terms.

Source: https://cloud.google.com/terms/agentic-ai-use-guidelines

4.3 The contractual clause

Section 20(n) of the Google Cloud Service Specific Terms, dedicated to Agentic AI Services, provides that the customer is "solely responsible" in four areas.

1. Every Agentic AI Action.
2. Assessing the suitability of the agent or service for the intended use.
3. Authorising access to data, applications and systems.
4. Exercising judgement and supervision in production environments to avoid potential harm.

The provision also governs the consequences of disabling or circumventing safeguards that require human confirmation. It is an express contractual allocation in the relationships governed by those terms, and on 23 October 2026 both this page and the guidelines show 12 October 2026 as the last modification. Its application and its limits must be assessed on the complete contract, in the applicable version and in light of the relevant law, and the clause alone does not show that Google is exempt from every liability provided by law.

Source: https://cloud.google.com/terms/service-terms

4.4 The critical question

Google acknowledges that agents can behave unexpectedly and, at the same time, assigns very broad contractual obligations to the customer. The problem emerges when harm depends on several factors, including possible defects of the service, model behaviour, application configurations and the authorisations granted. Responsibility cannot be reconstructed correctly by looking at a single clause isolated from its context.

4.5 MC Project Lab assessment

The explicit acknowledgement of operational risks is a positive aspect. The critical aspect is the breadth of the responsibility the contract assigns to the customer. Acknowledging a technological risk is different from transferring its consequences by contract.

5OpenAI: obligations, warranties and limits

OpenAI provides models and services through applications, APIs and commercial solutions. The OpenAI Services Agreement governs certain business and developer relationships.

5.1 Customer obligations

The contract assigns the customer responsibility for inputs and for the use of outputs, including assessing their adequacy.

5.2 Indemnities

Protections are provided for certain third-party claims, including some intellectual property disputes. These protections are subject to conditions and exclusions and are not a general guarantee against every harm caused by autonomous agents.

5.3 Limitations of liability

The contract provides financial limitations and exclusions, with specific exceptions. Their concrete application depends on the contract version and the circumstances.

5.4 Assessment

The central question is to distinguish the provider's obligations from those of the developer and of the business that integrates the model into an operational application.

Sources: https://openai.com/policies/services-agreement/
https://openai.com/policies/service-terms/

6Anthropic: Claude and operational autonomy

Anthropic distributes Claude through different products, APIs and tools, and the contractual framework varies according to the service and the applicable commercial relationship. The use of agents introduces risks linked to code execution, file management and access to external resources. It is therefore necessary to distinguish model behaviour, service features, the user's authorisations and integrations developed by third parties.

The existence of technical safety measures does not amount to an absolute contractual guarantee, and in the same way the user's configuration obligations do not necessarily exclude those of the provider. A conclusive comparison with Google or OpenAI requires examining the terms applicable to equivalent products and customers.

Source: https://www.anthropic.com/legal

7Microsoft: Copilot, Azure and GitHub

Microsoft operates as a provider of infrastructure, platforms, applications and AI development tools. The applicable terms vary by product, and there is no single contractual regime valid across all Copilot, Azure and GitHub services. Organisations must manage identities, access, authorisations and configurations, while Microsoft retains the obligations arising from the services it provides and the applicable contracts.

The shared responsibility model is a useful organisational tool, but it does not by itself determine who must compensate for harm.

Sources: https://www.microsoft.com/licensing/terms/
https://www.microsoft.com/servicesagreement
https://github.com/customer-terms

8Amazon Web Services: Bedrock and multi-provider agents

AWS provides infrastructure and services for developing AI applications. An application can use third-party models, cloud services and tools developed by the customer at the same time. The shared responsibility model has long distinguished infrastructure obligations from those relating to data, applications and configurations, and agentic AI makes this distribution more complex, because an incident can depend on components belonging to different providers.

Shared responsibility does not by itself determine the legal attribution of harm.

Sources: https://aws.amazon.com/agreement/
https://aws.amazon.com/service-terms/

9Meta: open-weight models and technological control

Meta distributes Llama models and develops AI services. Open-weight models allow different ways of running and customising them compared with services available only through APIs, and an organisation can gain more control over infrastructure and integrations. This can reduce some dependencies, but it also increases operational management obligations. Open-weight also does not mean the absence of contractual restrictions.

Greater technical control does not necessarily mean greater legal protection.

Sources: https://www.llama.com/
https://www.meta.ai/

10Mistral AI: the European provider

Mistral AI is one of the most significant European operators in the language model market. Its commercial terms may govern usage obligations, warranties, indemnities and limitations of liability, with a scope that depends on the product and the applicable contract. The provider's European headquarters does not automatically guarantee more favourable terms, and for this reason Mistral must be examined with the same criteria applied to US operators.

Source: https://legal.mistral.ai/terms/commercial-terms-of-service/

11The other global operators

The market includes many other operators. There are model producers such as xAI, DeepSeek and Cohere, cloud and model operators such as Alibaba Cloud (with Qwen), Tencent and Baidu, and infrastructure and software providers such as NVIDIA, IBM, Oracle and Salesforce, which offers Agentforce. There are also services that distribute or aggregate models, such as Hugging Face and OpenRouter, and agentic applications such as Perplexity and Cursor. Their presence in this list does not mean that the contractual terms of each have been verified: for these operators the dossier offers a market overview and not a contractual analysis.

12Comparison of contractual models

The table compares the central element of each provider and the caution with which it should be read.

The dossier assigns no contractual reliability score. A ranking would require a systematic comparison of equivalent clauses, in the versions actually applicable.

13The operational risks of agents

The main categories of risk are seven.

1. Unauthorised actions: operations that go beyond the user's intentions.
2. Prompt injection: attempts to alter the agent's behaviour through external content.
3. Excessive access: privileges greater than necessary.
4. Irreversible changes: deletions, transfers or alterations that are hard to recover.
5. Unexpected costs: consumption of resources and services.
6. Multi-provider dependencies: interactions between components belonging to different parties.
7. Difficulty of reconstruction: records that are insufficient to understand what happened.

These risks do not imply that every agent is unsafe, but they indicate that autonomy requires controls proportionate to the possible consequences.

14The European regulatory framework

14.1 AI Act

Regulation (EU) 2024/1689 introduces differentiated obligations according to the role of operators, the nature of systems and the associated risks. Not every AI agent is automatically a high-risk system, and the AI Act is not, by itself, a general regime of civil liability for harm caused by autonomous agents. The provisions and their application dates must be verified against the framework in force.

Source: https://eur-lex.europa.eu/eli/reg/2024/1689/oj

14.2 Liability for defective products

Directive (EU) 2024/2853 updates the European framework for liability for defective products and includes software. Member States must adopt the transposition measures by 9 December 2026, and at the date of the dossier that deadline has not yet expired. The new regime concerns products placed on the market or put into service after 9 December 2026, according to the transitional provisions. Liability requires verifying the applicable conditions, including defect, damage and causal link, and it does not arise automatically from the mere use of AI.

Source: https://eur-lex.europa.eu/eli/dir/2024/2853/oj

14.3 GDPR

Regulation (EU) 2016/679 governs the processing of personal data. The use of agents can involve obligations of lawfulness, transparency, security and accountability, and the system's autonomy does not remove the obligations of the parties identified by the law.

Source: https://eur-lex.europa.eu/eli/reg/2016/679/oj

14.4 Cyber Resilience Act

Regulation (EU) 2024/2847 introduces cybersecurity requirements for products with digital elements that fall within its scope. Its applicability to AI products depends on the characteristics of the product and on the conditions set out in the regulation.

Source: https://eur-lex.europa.eu/eli/reg/2024/2847/oj

14.5 Contracts and mandatory rules

Contractual clauses must be interpreted in the light of the applicable rules. A limitation of liability cannot be considered automatically valid or invalid without examining the specific legal relationship.

15Case law: Italy and the world

15.7 Comparison of precedents

15.8 What emerges

The precedents do not establish a universal rule on the responsibility of agents. They do show that AI-generated information, data processing and automated operations can be the subject of disputes and of intervention by authorities. Conclusions must remain limited to the rules and facts examined.

16The problem of evidence

Attributing responsibility requires being able to reconstruct events, and ten kinds of evidence are potentially relevant.

1. Instructions received.
2. Content consulted.
3. Tools used.
4. Authorisations available.
5. Approvals requested and received.
6. Operations actually carried out.
7. Responses from external systems.
8. Errors and anomalies.
9. Changes made.
10. Versions of the components involved.

Not all systems keep this information, and the lack of reliable records can make it difficult to distinguish a model error from improper configuration or an external attack. The verifiability of actions is an important condition for establishing responsibility.

17The asymmetries of the market

17.1 Technological

Providers may hold information about how models work that users cannot see.

17.2 Contractual

Many services are distributed under terms drafted unilaterally, and smaller businesses may have limited negotiating power.

17.3 Economic

The consequences of an incident can weigh very differently on the parties involved.

17.4 Evidential

The information needed to reconstruct an incident may be spread across several providers.

17.5 Operational

Changes to models, APIs, prices and terms can affect applications already integrated into business processes.

These asymmetries do not make contracts unlawful automatically, but they are relevant elements for assessing the balance of the market.

18Towards a more balanced responsibility

MC Project Lab proposes five principles.

18.1 Responsibility proportionate to control

Each party should assume responsibilities consistent with its role and with the control it actually exercises.

18.2 Transparency of limitations

Providers should communicate risks, limits and the conditions of warranties in an understandable way.

18.3 Traceability of actions

Agents' operations should be reconstructable through evidence proportionate to the risk and compatible with data protection law.

18.4 Proportionate supervision

Critical operations should provide for authorisations and controls appropriate to the seriousness of the possible consequences.

18.5 Contractual balance

Terms should allow customers to understand which risks they assume, which warranties they receive and which events remain excluded.

These principles are a governance proposal and not a list of universally binding legal obligations.

In practice

19What a business can do today

The indications that follow derive from what emerges in the previous sections and are not legal advice. They serve to reduce risk and to keep the ability to reconstruct the facts, whatever the eventual allocation of responsibility.

1. Read the clause before activating the agent. In the provider's contract, identify the parts that concern the agent's actions, indemnities and limitations of liability, noting the version and the date of consultation. In the Google Cloud case this is section 20(n) of the Service Specific Terms.
2. Grant only the permissions that are needed. Access to data, applications and systems should be limited to what the task requires, also because Google's contract assigns the customer the authorisation of that access.
3. Keep human confirmation on critical operations. Google's guidelines recommend explicit approval for critical actions, and the contract places on the customer the responsibility for disabling or bypassing safeguards. It is therefore advisable not to disable them without a conscious and documented decision.
4. Assess the agent's suitability before real use. The agent should be tested in an environment separate from production, because the contract assigns the customer the assessment of suitability and supervision in production environments.
5. Record what the agent does. Instructions received, tools used, authorisations, approvals, operations carried out, errors and versions of the components (section 16), in compliance with data protection law.
6. Limit costs and irreversible operations. Spending thresholds and mandatory confirmation for deletions, transfers and changes that are hard to recover (section 13).
7. Know who answers in the chain. Map providers, integrators and developers (section 2) and read what each one's contract says. For personal data the GDPR obligations should be checked, and for a specific case it is advisable to consult a lawyer.

None of these measures shifts responsibility by law. Each one does, however, strengthen the position of whoever will have to show that they controlled what was in their power to control.

Conclusion

20Conclusions

Agentic AI is changing the relationship between technological capability and responsibility. Providers develop systems capable of increasingly complex operations, businesses use them for progressively more important activities, contracts try to distribute risks in advance, and rules and courts deal with new problems.

Rather than identifying a single party to which every consequence is attributed, it is necessary to reconstruct who controlled the components involved, which obligations applied, which conduct contributed to the event and which evidence makes it possible to demonstrate it. The responsibility the contract assigns to the customer does not show that every incident is caused by the customer, and the autonomy of the system does not show that every harm is attributable to the producer.

MC Project Lab's position is that a balanced distribution of responsibilities should consider effective control, conduct, the foreseeability of risk and the causal contribution to the harm. This is an editorial and governance thesis, not a universally settled legal rule.

The maturity of the AI market will depend not only on agents' ability to carry out operations, but also on the possibility of understanding how they work, verifying their actions and correctly attributing responsibility.

The final question

If a company markets an artificial intelligence capable of acting autonomously, to what extent can it attribute to the customer responsibility for the actions that technology takes?

There is not yet a single, universally applicable answer, and the question now has practical consequences. Technological autonomy should not turn into legal irresponsibility.

Glossary

• AI agent: a goal-oriented system or workflow that performs actions or tasks on behalf of the user, in a supervised or autonomous manner.
• Agentic AI Action: in Google Cloud's terms, any action or omission of an AI service or agent, or attributable to them, including the execution of tasks and interactions and failures to execute.
• Prompt injection: instructions hidden in external content, such as web pages, documents or messages, that push the agent to behave in an unwanted way.
• Indemnity: a commitment to hold a party harmless from certain claims or consequences, within the limits set by the contract.
• Open-weight: a model whose parameters are published, which can be downloaded and run independently, under a licence that may still impose restrictions.
• Causal link: the connection between conduct and harm, necessary in order to attribute responsibility.
• Production environment: the real environment in which systems operate on real data and processes, as opposed to test environments.
• Activity log: a record of the actions carried out by a system, useful to reconstruct what happened.
• Preliminary injunction: a provisional decision by the judge, taken before the final judgment, to prevent or stop harm in the meantime.

Methodological note

The dossier distinguishes four kinds of content. Documented facts are information drawn from regulatory, contractual, institutional and judicial sources. Legal interpretations are analyses limited to the facts and rules available. The editorial thesis collects MC Project Lab's independent assessments of the balance of responsibilities. Contractual sources have 23 October 2026 as the reference date of the document review: terms published online may change, and the review date does not necessarily coincide with the date on which a contract takes effect.

For a specific dispute it is necessary to identify the applicable contract version, the service used and the competent jurisdiction. Some contracts of secondary providers and some international precedents were not examined in full: the dossier declares these limits and does not present as established conclusions that the available sources do not allow.

On 23 October 2026 the Service Specific Terms and guidelines of Google Cloud, the Ninth Circuit decision, the announcements of the Garante and the AGCM and the summary of the OLG Hamm case were re-read directly. For the other providers the dossier describes the general framework and refers to the terms indicated in the sources.

This document is an independent analysis and not legal advice.

MC PROJECT LAB

DOSSIER 001, consolidated edition of 23 October 2026