Your Agent, Your Problem: Google Cloud Just Made You Liable for Your AI Agents

1. What Changed, and Whether It Applies to You

Google Cloud's notice to customers covers four documents that work together:

1. Google Cloud Terms of Service (ToS): Sections 3.3 (Restrictions) and 13.2 (Customer Indemnification Obligations) were updated on October 12, 2026 to cover AI Agents explicitly. Sections 2.4 (Delinquent Payments; Suspension) and 8.3 (Termination for Breach) were updated on September 2, 2026.
2. Google Cloud Platform Service Specific Terms (SST): Sections 14, 15, 19, and 20 of the AI/ML Services terms now define agent categories and "Agentic AI Actions," allocate intellectual property, disclaim liability, and assign production supervision duties.
3. Google SecOps Service Specific Terms: Section 7 (AI Features) and Section 11 (Additional Definitions) set parallel rules for security operations agents.
4. Google Cloud Agentic AI Responsible Use Guidelines: New on October 12, 2026, as a supplement to the Acceptable Use Policy and the Generative AI Prohibited Use Policy.

The term that runs through all four documents is broad. SST Section 14 defines AI Agents as "goal-oriented, AI systems or workflows that perform actions or tasks on behalf of Customer in a supervised or autonomous manner." A scripted workflow that calls a model and then takes an action can qualify. Many teams are already running AI Agents under this definition without calling them that.

Google's notice says the changes do not affect customers with offline agreements for Google Workspace. Google Cloud Platform (GCP) customers on negotiated agreements should still check how their contracts treat terms referenced by URL. Many offline GCP agreements incorporate the online Service Specific Terms and Acceptable Use Policy by URL, so updates can flow through automatically unless the contract fixes those documents as of a specific date.

If you are in-house counsel, this update reaches your desk twice: once as terms your organization has already accepted, and again the first time engineering asks to turn off a confirmation prompt.

2. The Good News: Google Will Not Claim Your Agent

Before getting to liability, one change works in the customer's favor. Engineering and legal teams have long asked who owns an agent built inside a provider's managed environment with the provider's tools and templates.

SST Section 14 now sorts agents into three categories:

• Google AI Agent: An AI Agent created by Google and made available to the customer through the Services.
• Third-Party AI Agent: An AI Agent created or owned by a third party.
• Customer AI Agent: Either (i) an AI Agent created by the customer, "including by customizing agent instructions in an Agentic AI Service," or (ii) an AI Agent owned or licensed by the customer that the customer deploys in a Service.

That phrase, "including by customizing agent instructions," is doing a lot of work. In plain terms, if your team customizes an agent's instructions in a Google Cloud service that Google lists as an Agentic AI Service, supplying your own system instructions, domain rules, and workflow logic, the result is a Customer AI Agent, and Google asserts no ownership in your work. That matters because under SST Section 15(a)(iii), as between the customer and Google, "Google does not assert any ownership rights in (i) Customer Models, (ii) Customer Adapter Models, (iii) Customer AI Agents, or (iv) Separate Offerings, each to the extent they do not contain any pre-existing Google intellectual property."

Two limits keep this from being a full ownership grant. First, Section 15(a) is a promise not to assert ownership, made "as between Customer and Google." It doesn't assign anything to you, and it doesn't settle claims from anyone else. Second, it applies only "to the extent" the agent contains no pre-existing Google intellectual property, and Section 15(b) confirms that Google owns its models and its Google AI Agents. If you customized an agent Google built, the layer that you added is yours, but the agent underneath is still Google's.

3. The Catch: The Same Definition Makes the Agent Your Liability

The classification that protects your work also moves risk to you. The October 12 updates shift indemnification in two directions at once: customers take on a new duty to indemnify Google for what their agents do, and Google carves agent behavior out of the indemnity it gives customers.

Your Duty to Indemnify Google (ToS Sections 3.3 and 13.2)

In the Google Cloud Terms of Service, Section 3.3(d) bars customers and their end users from accessing or using the Services "or any AI Agent" for High Risk Activities, in violation of the AUP, to avoid fees or circumvent usage limits, or for other restricted purposes. Section 13.2(b) then requires the customer to defend and indemnify Google in any third-party legal proceeding arising from:

"Customer's or an End User's use of the Services or AI Agents in breach of the AUP or Section 3.3 (Restrictions)."

The Agentic AI Responsible Use Guidelines describe themselves as a way to help customers align agents with the AUP and the Generative AI Prohibited Use Policy. Much of the conduct they prohibit, such as unauthorized access, fraud, and deceptive automation, is the kind of conduct the AUP already forbids. If an agent's action breaches the AUP and a third party sues Google over it, Section 13.2(b) puts the defense and the indemnity on the customer.

Where Google Steps Out of the Liability Chain (SST Sections 14, 19(b), and 20)

Under SST Section 20(i)(i), Google still indemnifies customers against claims that unmodified Generated Output infringes a third party's intellectual property. The protection applies only to output from a paid service on Google's list of Generative AI Indemnified Services, and only when that output comes from Google's own models (including versions a customer has tuned). Three provisions keep that protection away from agents:

1. Agentic AI Actions are not Generated Output. SST Section 14 defines an "Agentic AI Action" as "any action or inaction of, or attributable to, an Agentic AI Service or AI Agent (including execution of tasks, interactions or other functions, as well as omissions or failures to execute such tasks, interactions, or other functions)." The definition ends with an explicit carve-out: "Agentic AI Actions are not Generated Output."
2. A complete disclaimer for Customer AI Agents and connected services. Under SST Section 19(b), "Google disclaims all liability arising from, and Google's indemnification obligations do not apply to allegations arising from, Customer's use of Separate Offerings and Customer Models, Customer AI Agents, and Third-Party AI Agents." Section 19(b) also disclaims all liability and indemnity for "any Third-Party Service accessed by Customer via an AI/ML Service or accessed by an AI Agent."
3. The agentic expansion stops short of the indemnity. SST Section 20(a) provides that "for the purposes of subsections (b) through (h) below, 'Generative AI Services' includes Agentic AI Services." Subsections (b) through (h) hold the disclaimers, the Prohibited Use Policy, the age and healthcare restrictions, Google's suspension right, and its prompt-handling commitment. The IP indemnity sits in subsection (i), outside that range. Agentic services take on the restrictions that apply to generative AI, and the text does not extend the indemnity to them.

Because customizing an agent's instructions makes it a Customer AI Agent, most agents an organization configures for real work fall within Section 19(b)'s disclaimer. Two more consequences follow. First, an agent that calls a third-party model offered through Google Cloud under that provider's own terms is using a Separate Offering, which Section 19(b) also disclaims, and Section 20(i)(i) covers only output from Google's models in any case.

Second, the terms leave one question open. Text written by a customized agent running on a Google model is probably still Generated Output, but Section 19(b) disclaims indemnity for allegations "arising from" use of Customer AI Agents. The terms don't say which provision controls, but until Google clarifies, the cautious assumption is that the disclaimer wins.

Google SecOps Goes Further (SecOps SST Section 7(k)(iii))

In Google SecOps, the disclaimer is broader still. SecOps SST Section 7(k)(iii) states that "Google disclaims all liability arising from, and Google's indemnification obligations do not apply to allegations arising from, (i) AI Agents, [or] (ii) any Third-Party Service accessed by Customer via an AI Feature or accessed by an AI Agent..." The clause isn't limited to Customer AI Agents or Third-Party AI Agents, so on its face it also reaches agents Google builds. For security teams running SecOps agents against live infrastructure, that is a meaningful difference from the GCP terms.

4. Read the Verbs: What the Guidelines Prohibit and What They Only Recommend

The Agentic AI Responsible Use Guidelines use three kinds of language, and the differences matter. Sections 1 through 3 list "prohibited actions" that agents "must not" take. Section 4 names two things agentic technology "should not" be used for. Everything else in Section 4, including human approval before financial, legal, and irreversible actions, is something Google "strongly recommends." The Guidelines also describe themselves as "non-exhaustive guidelines designed to help you align" your agents with the Acceptable Use Policy; they don't present themselves as new AUP text. In practice, treat Sections 1 through 3 as conduct Google is likely to view as an AUP breach. Treat Section 4 as a reasonable benchmark for the "judgment and supervision" the contract already requires of you, discussed below.

Prohibited (Guidelines Sections 1 through 3)

• Unauthorized access (Section 1): Agents must not be used to exploit vulnerabilities, "circumvent paywalls," or use stolen or unauthorized credentials.
• Web crawling and scraping restrictions (Section 2): The Guidelines prohibit deceiving systems by "circumventing third-party restrictions (e.g., website restrictions on web crawling and scraping or on use of automated technology)" and by "obfuscating or misrepresenting agent identity." An agent with an unrestricted browsing tool that ignores a site's scraping restrictions can put the customer on the wrong side of this line.
• File changes and subagent spawning (Section 2): Agents must not be used, without explicit customer authorization, to alter files, bypass file permissions, or "create duplicate agents, subagents, or forked processes that would reasonably be expected to exceed Customer's intended scope of action."

Should Not (Guidelines Section 4)

• Agentic technology should not be used "as part of a multi-agent system to obfuscate agent-to-agent communications as a means to bypass human oversight," or to build multi-agent systems that carry out high-risk or fraudulent tasks.

Strongly Recommended (Guidelines Section 4)

Google notes that agents may act in ways that were not instructed or anticipated, and have "heightened susceptibility to external attacks (such as prompt injection)." It strongly recommends human oversight and explicit approval before agents act on consequential matters, including:

• Financial matters, such as trading, transactions, and insurance decisions.
• "Legal and contractual matters (e.g., legal negotiations and decisions, terms acceptance, agreeing to cookies/other tracking technologies, etc.)."
• Choices in regulated or high-risk domains, such as healthcare, housing, employment, insurance, and social welfare eligibility.
• Changes to production data that are not "readily and immediately reversible."
• Agent spending, "as you remain liable for any charges accrued by your agents."

Where the Guidelines Meet the Contract (SST Section 20(n) and SecOps SST Section 7(k))

Recommendations become harder to ignore once you read SST Section 20(n)(i) and SecOps SST Section 7(k)(i). Under both, the customer is solely responsible for:

• (A) any Agentic AI Action (which, by definition, includes both actions and failures to act);
• (B) determining whether an agentic service or AI Agent is fit for its intended use case;
• (C) authorizing the agent's access and connection to data, applications, and systems; and
• (D) exercising judgment and supervision when an agent is used in production environments to avoid potential harm.

SST Section 20(n)(ii) then addresses human confirmation prompts directly:

"Certain Agentic AI Services may be configured by default with safeguards that require human confirmation before executing certain operations. Without limiting subsection (i), Customer is solely responsible for any liability arising from disabling or bypassing any of these safeguards with respect to a particular Service."

SecOps SST Section 7(k)(ii) uses the same language for SecOps "Agentic AI Features."

5. Two Quieter Changes: Faster Termination and Payment-Risk Suspension

Two additions to the Google Cloud Terms of Service that took effect on September 2, 2026 matter more once agents run for long periods without supervision.

Termination Without a Cure Period (ToS Section 8.3(b)(ii))

Google could already terminate the Agreement if a customer failed to cure a material breach within 30 days of notice. Section 8.3(b) now adds a second path, allowing termination immediately on written notice where:

"(ii) in the case of a material breach by Customer, Google reasonably determines that the breach is incapable of being cured."

This right applies to the entire Agreement, not to a single project or service. Separately, at the service level, SST Sections 17(a), 17(c), and 20(f) let Google immediately suspend or terminate access to AI services based on any suspected violation of the competitive-use, reverse-engineering, model-restriction, or age rules, and SecOps SST Section 7(i) contains a parallel suspension right.

Payment-Risk Suspension (ToS Section 2.4)

Agents caught in a retry or reasoning loop can run up charges quickly, and Guidelines Section 4 reminds customers that they remain liable for those charges. Under the September 2 addition to ToS Section 2.4, if a customer uses a delayed-authorization form of payment (such as ACH) and Google "reasonably determines that Customer poses a risk of non-payment, Google may Suspend all or part of Customer's use of the Services." A sudden spike from a runaway agent is not itself non-payment, but it is the kind of event that can turn into one.

6. The Governance Crosswalk: Reusing Controls You Already Have

Google's notice tells customers to "align your current internal policies to these updated terms and deployment guardrails," and Guidelines Section 4 adds: "It is your responsibility to determine your governance obligations."

Google didn't write NIST or ISO into its contract. But read side by side, the duties Google now places on customers line up closely with controls that four widely used frameworks already ask for. The Guidelines name only the EU AI Act; the other mappings below are my own analysis. For a governance team, that overlap is the useful part. One set of controls, documented once, can satisfy both the contract and the framework.

Guidelines Section 4 recommends human approval for decisions in "healthcare, housing, employment, insurance, and government and other social welfare decisions," and for "any other use case designated as high-risk under applicable AI regulations, including but not limited to the EU AI Act." Several of those domains overlap with the EU AI Act's Annex III categories (employment, access to essential public services and benefits, and life and health insurance pricing), and the catch-all brings in the rest.

7. Six Steps to Make These Changes Work for You

No customer can negotiate away accountability for the tools it connects to production. These six steps keep the intellectual property benefit of the October 12 terms while limiting the exposure.

1. Confirm which version of the terms binds you, and list your agents. Check whether your master agreement brings in the Service Specific Terms by URL or fixes them as of a date. Then list every agent that now counts as a Customer AI Agent and name an internal owner for each one.
2. Keep confirmation gates on, and make turning one off a signed decision. SST Section 20(n)(ii) puts sole liability on the customer for disabling default safeguards. Use that clause as the internal rule: no safeguard comes off without written risk sign-off.
3. Where indemnity matters, keep content generation separate from agent actions. Route content you want covered through direct calls to an indemnified Google model, with filters and citations left on, because SST Section 20(i)(i)(2) removes the indemnity when a customer disables or circumvents them. SST Section 20(j) separately makes you solely responsible for any changes you make to safety filters.
4. Keep your agent instructions in your own repository. Maintain system prompts, agent definitions, and tool schemas in your own source control and deploy them through infrastructure-as-code. That gives you a dated record of the layer your team wrote, which is exactly the part SST Section 15(a) leaves to you.
5. Give every agent its own identity and limits. Replace shared service accounts with per-agent Agent IAM roles scoped to the minimum permissions required (Guidelines Section 5). Set recursion and turn limits so agents cannot spawn subagents beyond their intended scope, and send web traffic through a proxy that restricts destinations, honors crawling restrictions, and blocks automatic acceptance of clickwrap terms and tracking cookies.
6. Contain the blast radius and the bill. Run agents in dedicated projects so their permissions and quotas cannot reach core production data. Set API quota limits, because Cloud Billing budgets send alerts but don't stop spending on their own; for a true kill switch, connect budget notifications to an automated action. This won't protect your Agreement from termination under ToS Section 8.3(b)(ii), which applies to the whole contract, but it will reduce the chance that one runaway agent produces the kind of sudden charge that could prompt a payment-risk review under ToS Section 2.4.

8. Where This Leaves Google Cloud Customers

The direction of this update is not surprising. A provider that cannot see what a customer told its agent to do is unlikely to underwrite what the agent does. What is new is how plainly Google is saying it, and how much of the governance work it hands back to its customers.

That work is manageable, and much of it overlaps with controls that a well-run AI program already maintains. Three questions are worth answering this week:

1. Which of our agents now count as Customer AI Agents, and who owns each one internally?
2. Have we turned off any default confirmation prompts, and who approved that?
3. Does our master agreement fix the Service Specific Terms as of a date, or do they update by URL?

9. Selected Authorities

Google Cloud Contract Documents and Guidelines

• Google Cloud Terms of Service (Sections 2.4, 3.3, 8.3, and 13.2, as updated September 2, 2026 and October 12, 2026)
• Google Cloud Platform Service Specific Terms (Sections 14, 15, 17, 19, and 20, as updated October 12, 2026)
• Google SecOps Service Specific Terms (Sections 7 and 11, as updated October 12, 2026)
• Google Cloud Agentic AI Responsible Use Guidelines (Sections 1 through 5, October 12, 2026)
• Google Cloud Generative AI Indemnified Services
• Google Cloud Acceptable Use Policy
• Google Generative AI Prohibited Use Policy
• Google Cloud Billing, Create, edit, or delete budgets and budget alerts

AI Governance Frameworks and Regulatory Standards

• Regulation (EU) 2024/1689 (EU Artificial Intelligence Act) (Articles 6, 14, and 26, and Annex III)
• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0) (January 2023; GOVERN 1.1, 2.1, and 6.1; MAP 1.1 and 3.5; MANAGE 2.4)
• NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (July 2024)
• ISO/IEC 42001:2023, Information technology: Artificial intelligence: Management system (Annex A Controls A.6.2.6, A.6.2.8, A.8.2, A.9.4, A.10.2, and A.10.3)
• OWASP Top 10 for Large Language Model Applications (2025 edition: LLM01: Prompt Injection and LLM06: Excessive Agency)
• OWASP GenAI Security Project, Top 10 for Agentic Applications (ASI01, ASI03, and ASI08)