1. Scope and definitions
1.1These terms supplement the Terms of Service for AI features, digital workers, agents, automations, tools and orchestration. An Agent is software configured to generate content or initiate actions. A Module is a functional component; a Model is an underlying AI model. Neither an Agent, Module nor Model is a legal person or can itself assume contractual liability.
1.2An Action includes reading, copying, transmitting, editing or deleting records; sending messages; making calls; booking appointments; triggering workflows; submitting instructions; and incurring charges. The actual available Actions depend on the purchased configuration and connected services. These terms do not represent that every listed Action or control is available.
1.3Capitalized terms not defined here have the meanings given in the Terms of Service. These terms form part of the Agreement and are subject to its order of precedence. The DPA governs personal-data processing, and nothing in these terms expands processing permissions or overrides a mandatory data-protection obligation.
1.4Digital workers combine third-party AI models, including models supplied by OpenAI, Anthropic and Google, with functions, instructions and connected tools configured for Customer. Availability through an API does not mean a model is open source or that its weights or internal reasoning are available to Customer.
2. Customer authority and operating boundaries
2.1Customer retains authority over its business use of Agents. Customer must designate responsible administrators and decide which Agents to deploy, their purposes, permitted data, recipients, tools, credentials, approval requirements and limits. Customer is responsible for ensuring that its representatives have authority to grant those permissions and to act for any affected business or end customer.
2.2Before live use, Customer must test its workflows, review prompts and connected permissions, check the service documentation and choose supervision proportionate to risk. Customer must not enable an Action if the controls it requires are unavailable; it must use a restricted or manual workflow instead. Access to a provider account should be limited to the minimum necessary scope.
2.3Templates, default settings, onboarding assistance and suggested workflows are starting points. Unless a signed managed-service scope expressly allocates a task to us, they do not transfer Customer’s operational approval or compliance duties to the Company.
2.4Customer may appoint an employee, agency, consultant or other account operator to configure and supervise its digital workers. Customer must define that operator’s authority, ensure compliance with the Agreement and revoke permissions when appropriate. Delegating administration does not release Customer from its obligations to Company. An operator acting for Customer must stay within the authority granted and remains responsible under its own agreement with Customer and applicable law; appointment alone does not make that operator a party to this Agreement.
3. Approval and autonomous execution
3.1Customer may authorize individual Actions or, where supported, a defined class of Actions under standing instructions. Enabling automatic operation authorizes execution within those actual permissions without a separate approval for every Action. It does not authorize actions outside the granted scope, and does not waive responsibility for a Company failure to enforce expressly agreed controls.
3.2Customer is responsible for its choice to enable, broaden or disable approval requirements, its approved messages and instructions, and consequences attributable to those choices. It must assign qualified people to review sensitive or significant Actions and independently verify material information before approving it.
3.3Agents may process incomplete or incorrect information and make unsuitable selections. A successful technical execution does not establish that an Action is commercially appropriate, legally compliant or factually correct. Human approval must be meaningful where required, rather than a formality.
3.4An Agent’s authorized scope is determined by Customer’s instructions and approvals together with the applicable configured restrictions. Possession of a credential, access to a tool, or technical ability to perform an Action does not by itself authorize every Action the credential or tool permits. Retrieved content or a model-generated plan cannot expand that scope. Customer must align the access it grants with the business authority it intends to confer and use a restricted or manual process where the required boundary cannot be enforced.
4. Monitoring, changes and stopping activity
4.1Customer and its authorized account operator can inspect and edit the worker’s configurable instructions and functions, inspect its recorded Actions, and manage execution permissions and approval requirements in the workspace. Customer is responsible for using those controls and reviewing activity. These controls concern workspace configuration and recorded execution; they do not expose proprietary model reasoning or guarantee visibility into every event inside an independent external service. Record retention follows the DPA and service specification.
4.2Customer must review material changes to prompts, knowledge, recipient lists, tools and access rights, monitor activity proportionate to risk, respond to warnings and revoke access that is no longer appropriate. A warning, log or dashboard does not replace business oversight.
4.3Pausing an Agent or revoking access generally affects future execution when the change takes effect. It may not cancel queued requests already accepted externally or reverse completed messages, transactions, deletions or charges. Customer must check the external service and take any required corrective action. We do not guarantee reversibility.
4.4Restarting a paused workflow may resume pending work where the service supports that behavior. Customer must review outstanding tasks and the applicable authorization before restarting. Revoking a user’s account access does not necessarily revoke a separately connected service credential, standing workflow or external session; Customer must disable each relevant form of continuing access using the available controls. Company remains responsible for any termination or revocation obligations it has expressly undertaken.
5. Responsibility for Customer-directed Actions
5.1To the maximum extent permitted by law, Customer assumes sole responsibility for Actions and consequences to the extent resulting from its instructions, supplied data, approved content, selected recipients, granted permissions, configured rules, approvals or decision to allow autonomous operation. These include business commitments, external communications, data changes, transactions and usage charges undertaken within Customer’s authorization.
5.2To that same extent, the Company has no liability for such Actions, their business suitability or their consequences and has no duty to pre-approve, manually review or continuously supervise Customer’s operations unless a signed service scope expressly provides otherwise. Optional support, safety monitoring or intervention does not create a general duty to supervise every Action.
5.3This allocation is subject to the mandatory-law exceptions and liability provisions in the Terms of Service. It does not excuse our failure to perform express contractual obligations, attribute an unauthorized action caused by our defect to Customer, or eliminate our responsibilities for Company subprocessors under the DPA.
5.4Where a loss results from both Customer-controlled matters and a breach attributable to Company, responsibility is determined according to the extent each contributed to the loss, subject to the Agreement and applicable law. Customer approval does not release Company from an independently applicable obligation, and a Company contribution does not make Company responsible for the separate consequences of Customer’s own instructions or unlawful conduct.
6. External models, modules and credentials
6.1For a Customer-Connected Service, Customer contracts directly with its provider and is responsible for subscription status, access rights, usage rules, spending and provider settings, including retention and training settings. The provider is responsible only as stated in its own agreement and applicable law. The Company cannot transfer a claim to a provider by declaring that a software module is liable.
6.2Where we procure a model or service to deliver our own Services, we are responsible for our agreement with that provider and applicable subprocessor obligations. Customer must comply with use restrictions disclosed for the enabled functionality, but need not be deemed to have a direct provider contract where none exists.
6.3Provider rate limits, outages, changing models, moderation, geographic restrictions and discontinued APIs may affect capabilities. Subject to the Terms of Service and any applicable SLA, we do not guarantee an external provider’s independent performance. Connecting a service permits the data access required by the scope Customer grants; Customer must review that scope before connection.
6.4The Subprocessors & External Services page provides links to the use policies of the model providers. Customer and its operators must review the policies applicable to the enabled model and comply with the restrictions communicated for that functionality. A model policy does not transfer ownership of Customer Outputs to Company or expand an Agent’s authority.
7. Content quality, rights and professional judgment
7.1Outputs may be incorrect, incomplete, biased, misleading, outdated or similar to those generated for others. They may reproduce information from Inputs or connected sources, including information Customer should not disclose. Customer must evaluate factual accuracy, rights, confidentiality, recipient and intended use before relying on Outputs in a context requiring verification.
7.2Ownership as between the parties is governed by the Terms of Service. It does not guarantee copyright protection, exclusivity or freedom from third-party rights. AI output is not professional advice or a promise of an outcome. Customer must obtain appropriate professional judgment for regulated or consequential decisions.
7.3Do not rely on factual assertions, recommendations or task-completion claims solely because an Agent generated them. Customer or its authorized operator must independently verify material information and the actual status of consequential Actions before relying on, publishing or acting on them. AI can hallucinate, misunderstand instructions and produce incorrect or unsuitable content. Company does not warrant accuracy, completeness, suitability or any business result, subject to the express Agreement and mandatory law.
8. Personal data, communications and representations
8.1Customer must obtain lawful authority for the data it supplies and the people it contacts, provide required privacy and AI disclosures, respect marketing opt-outs and applicable calling hours, and obtain recording or transcription permissions where required. A connection to a communications account does not itself establish consent from message recipients.
8.2Customer must not impersonate a person or deceptively represent an Agent as a human. Any approved voice, image or likeness requires appropriate rights. Customer must supervise uses involving employment, credit, insurance, health or other significant effects on people, and must not use prohibited or unsupported regulated workflows.
8.3Customer must not put credentials, payment card security data or other restricted information into prompts or knowledge sources. Where available, use designated credential storage rather than free-text instructions. Third-party documents and messages may contain malicious instructions; Customer must not configure them to override authorization boundaries.
8.4Customer must inform its Authorized Users that their use occurs within an administered business workspace and describe the administrator access and control that actually apply. Customer must communicate applicable output limitations, provider restrictions and supervision requirements to those deploying or relying on Agents. For external interactive Agents, Customer must provide the AI disclosure required by the Acceptable Use Policy and any applicable provider policy at the required point in each interaction.
9. Training, retention and improvement
9.1The Company will not use Customer Inputs or Outputs to train general-purpose AI models. For model providers engaged by the Company, Company will obtain contractual restrictions consistent with this undertaking before sending Customer content for processing. Any separate request to contribute identifiable content for training requires a distinct express agreement and lawful basis; it is not inferred from ordinary use.
9.2Operational processing may include routing, caching, security checks, error investigation and support as needed to provide the Services and as permitted by the DPA. Such processing can involve Company subprocessors; no promise of non-sharing with all third parties or zero retention is made. Retention periods and processing locations must be set out in the applicable processing schedule.
9.3For Customer-Connected Services, the external provider’s processing is governed by Customer’s contract and account settings. Our own no-training undertaking does not change those settings or warrant that provider’s conduct. Customer must not enable a connection whose processing terms are incompatible with its obligations.
10. Charges, retries and incident response
10.1An Agent can consume prepaid tokens or usage credits through multiple billable events in one task, including model calls, tool executions and retries. The rate schedule identifies covered events, conversions and any failed-attempt charges. Customer and its authorized operator must set and supervise the available budget controls, including for scheduled and autonomous work. The prepaid balance, optional auto-reload and budget-enforcement rules in Section 8 of the Terms of Service apply; an alert is not itself a hard cap.
10.2If Customer identifies unexpected Actions, it should pause affected activity, restrict credentials where needed, preserve relevant records and notify support promptly. Company will address incidents within its responsibility under the Agreement and DPA. These terms do not promise recovery of external transactions or reimbursement by an external provider.
10.3Unless an express written indemnity applies, Company does not indemnify Customer against third-party intellectual property claims concerning AI Outputs. The Terms of Service govern all liability limits, indemnity procedures, suspension, termination and surviving obligations.
10.4A timeout, error message or missing confirmation does not necessarily mean that an external Action failed. An external service may complete an Action before its response is received. Before manually repeating or resuming an Action with material consequences, Customer must check its status in the relevant external system and use available duplicate-prevention controls. Automated retries are permitted only within the scope Customer has authorized and the documented retry behavior for the affected workflow; neither a retry nor a recovery step authorizes a new business commitment outside that scope.
11. Connected tools, remote servers and computer access
11.1Tools may expose read, write, send, purchase or administrative functions through APIs, browser sessions, remote servers or other interfaces. Customer must examine the permissions granted to the actual connection, not rely solely on a friendly tool name or an Agent’s written instructions. Access to an authenticated browser session can expose information and capabilities available in that session.
11.2Customer must ensure that remote tool servers and extensions it supplies are trusted and authorized. Installing or connecting a tool may transmit Inputs, Outputs, account identifiers or credentials to its operator. Customer must not connect a server that requires permissions broader than its authorized purpose, or use an extension to circumvent the protections of an underlying service. Company-supplied processing remains governed by the DPA.
11.3An external service can change its interface, permissions or execution behavior. Customer must reassess a material permission change before continuing affected operations. Where an action requires separate acceptance in the external service, that requirement remains applicable; an Agent’s ability to submit a request does not establish authority to accept unrelated third-party terms.
12. Untrusted content and prompt injection
12.1Emails, webpages, retrieved documents and tool responses can include inaccurate material or instructions designed to redirect an Agent. Such content is data to be evaluated; it does not itself authorize access to another system, disclosure of confidential information, a payment, or an expansion of the approved task. Customer must separate trusted operating instructions from untrusted content in the configuration it controls.
12.2Customer must use available scope restrictions and human approvals for consequential actions, including bulk communications, permission changes, deletion and commitments of funds. A natural-language instruction such as “be careful” is not a substitute for an enforced permission boundary. Company remains responsible for the operation of safeguards it expressly undertakes to provide; no instruction guarantees that all adversarial content will be detected.
13. Review records, evidence and authorization changes
13.1Available execution records can help Customer inspect inputs, outputs, tool calls, approvals, status and errors to the extent captured by the purchased service. Records may be delayed, incomplete for external steps or subject to a retention limit. They are not a promise to disclose hidden model reasoning or another provider’s confidential systems. Customer must export records it needs before the applicable retention period ends.
13.2Customer must review material changes to an Agent’s task, model, knowledge sources, tool scope, spending rules and audience. A prior approval is limited to the action or standing authorization actually approved; it does not automatically cover materially different recipients, amounts or purposes. Customer must restrict or stop the affected workflow while reassessing a change that creates a material risk.
13.3Customer must designate a person able to respond to unexpected actions. Company’s technical assistance in investigating an event is not an admission of liability, and Customer’s report does not itself establish that the event was authorized. The parties will assess available records, the agreed configuration and the cause of the event under the Agreement.
13.4A delegation to another Agent or tool, a scheduled run, a retry or a continuation of a task remains subject to the same applicable authorization boundaries. It does not create fresh permission for a materially different recipient, amount, data disclosure or purpose. Customer must authorize any expansion through the approval process applicable to the affected Services.
14. Provider processing exceptions and model changes
14.1A no-training commitment concerns use of content to develop general-purpose models; it is distinct from storing data for safety review, enforcing provider usage rules, caching, support, legal compliance or incident investigation. Provider-specific retention exceptions can apply to particular models and channels even where another channel offers reduced retention. Company must honor its own agreed data-processing commitments and disclose relevant service limitations before incompatible processing begins.
14.2A change of model may affect output style, reasoning quality, supported tools, geographic processing and cost. Customer must assess suitability before using changed functionality in a consequential workflow. A model with a similar name or an upgraded version is not a promise of identical results. Material changes to Company-procured subprocessors follow the DPA; changes to Customer-procured providers remain subject to Customer’s separate agreement.
14.3Fine-tuning or a separate development program requires a specific scope describing the training materials, purpose, rights, retention and recipients. Permission for a Customer-specific tuning operation is not permission to train a general-purpose model or use that Customer’s data for unrelated customers.
14.4Routing, failover or substitution by Company must remain within the agreed processing purposes, approved data categories, applicable transfer safeguards and Company’s confidentiality and no-training commitments. Company will not treat Customer’s general authorization to complete a task as consent to incompatible provider processing. If a proposed change cannot comply with the existing Agreement, Company must obtain any required contractual change or restrict the affected functionality before sending Customer Content through that route. Subprocessor changes remain subject to the DPA’s notice and objection procedure.