# What Contract Clauses Should Companies Use for AI Agents in 2026?

Paige Thornton · October 1, 2026

> The Direct Answer to AI Agent Contract Clauses The most defensible AI agent contract clauses allocate authority, define permitted actions, cap...

## The Direct Answer to AI Agent Contract Clauses

The most defensible AI agent contract clauses allocate authority, define permitted actions, cap exposure, and create an auditable approval process. A useful agreement should distinguish an AI model, an autonomous agent, a vendor-operated platform, and an employee who ultimately presses the button. It should also state which party owns prompts, training data, generated code, logs, tool integrations, and decisions made with external systems. As of October 1, 2026, there is no generally accepted clause package for agentic AI, so legal teams are combining software licensing, professional services, data processing, cybersecurity, insurance, and outsourcing language rather than signing a standardized “AI agent” contract.

**Also worth reading:** [How Should Companies Put AI Consulting Governance into Practice in 2026?](https://zdnetinside.com/knowledge/how_should_companies_put_ai_consulting_governance_into_practice_in_2026.php) · [How Should Companies Measure Agentic AI ROI Without Inflating the Numbers?](https://zdnetinside.com/knowledge/how_should_companies_measure_agentic_ai_roi_without_inflating_the_numbers.php) · [How Do Companies Measure AI Pilot ROI in 2026?](https://zdnetinside.com/knowledge/how_do_companies_measure_ai_pilot_roi_in_2026.php)

A strong clause set therefore needs six foundations: a precise scope of authority, measurable service levels, human approval gates, data and IP allocation, incident notification, and enforceable remedies. Contracts that mention “AI” without defining the agent’s permissions can leave disputes over foreseeable misuse, unauthorized tool calls, vendor subcontractors, or a customer’s failure to supervise a high-risk workflow. The central question is not whether an AI agent is impressive or efficient. It is whether the parties can prove what the system was allowed to do, what it actually did, and who must pay when those two things diverge.

Companies should also resist the idea that more autonomy always requires fewer restrictions. Higher-value agents may need stronger monitoring because one erroneous action can affect thousands of records or create a security event. Conversely, a narrow customer-service agent with no payment, deletion, or external-communication authority may require a much simpler control model than an agent that changes production code. Contract language should scale with the agent’s permissions, not with the amount of AI marketing language used during procurement.

## Why Traditional Software Clauses Often Fail

Traditional software contracts generally allocate a license, promise basic availability, limit warranties, and assign liability according to each party’s conduct. Agentic systems complicate that structure because an agent interprets instructions and chooses intermediate actions rather than simply returning a fixed output. If it can send email, modify a repository, execute code, negotiate with suppliers, or access customer records, the relevant permissions may exist partly in natural-language instructions and partly in the vendor’s technical controls. A contract that covers only the API can miss what happens when the agent connects to a CRM, cloud console, payment service, or software repository.

The liability gap often arises from four competing claims. The customer may argue that it selected the business objective and approved the deployment. The vendor may say the agent followed a documented policy, while the integrator may blame a customer-provided dataset or an incorrect human instruction. An insurer may exclude losses caused by contractual rather than accidental harm, leaving all three parties to negotiate after the event. Existing service-level clauses may also promise availability while saying almost nothing about incorrect decisions, harmful content, security failures, or unauthorized actions.

A useful drafting technique is to translate model behavior into operational events. Instead of promising that the agent will “be accurate, ethical, and reliable,” the agreement can require a minimum task-success rate, prohibit named action classes, set review thresholds based on financial value or data sensitivity, and require complete logs. For example, a deployment might set a 95% target for correctly routing low-risk support tickets but require human approval for refunds above $500, account termination, regulated advice, or production changes affecting more than 25 users. These are commercially chosen benchmarks, not universal legal standards, but they make performance review possible.

## Recommended Clause Architecture and Approval Thresholds

The authority clause should enumerate systems the agent may access, actions it may take, geographic and account boundaries, operating hours, spending limits, and prohibited uses. It should identify whether the agent may act only after a person requests a task or may continue through a multi-step workflow without additional confirmation. Tool access should be technically constrained as well as contractually described; saying the agent is prohibited from transferring data is weak if its credentials can perform that action. The clause should also state whether the vendor may add new tools or sub-processors, and what notice is required before those additions become active.

Human-review gates should be based on risk rather than user preference. A practical starting policy is no autonomous approval for external legal commitments, regulated decisions, credential changes, destructive database operations, or payments above an agreed amount. Lower-risk actions may proceed automatically after the system establishes identity, authorization, input validity, and a rollback path. Contracts can specify that a human reviewing an action must see the relevant source data, proposed action, expected cost, and uncertainty signal rather than merely clicking “approve.” The agreement should preserve an emergency stop that immediately blocks all tool execution.

| Feature | Narrow Internal Agent | Customer-Facing Agent | High-Risk Operational Agent |
| --- | --- | --- | --- |
| Human approval | Sampled review | Approval for sensitive actions | Approval before each material action |
| Illustrative action limit | No external publishing; changes below $100 | No account closure or regulated advice | No unapproved production, funds, or legal actions |
| Logging period | 90 days | 12 months | 12–24 months plus immutable security records |
| Performance target | At least 98% successful routine tasks | At least 95% task success and 99.9% uptime | Zero unauthorized critical actions; targets set per workflow |
| Incident notice | Within 24–72 hours | Within 24 hours | Within 4–8 hours for suspected security or control failure |
| Liability position | Shared responsibility | Vendor indemnity subject to clear exclusions | Stronger vendor assumption plus insurance and remediation duties |

These numbers are negotiation examples rather than prescribed requirements. Parties should base them on business impact, regulatory duties, and available technical controls. The contract must distinguish a missed monthly percentage target from a severe but isolated breach, because treating every failed task identically encourages either weak monitoring or disproportionate penalties.

## Data Protection, Confidentiality, and IP Rights

The data clause should identify whether prompts, retrieved documents, tool logs, evaluation results, and generated outputs contain personal data, confidential information, trade secrets, or regulated records. A processing agreement should cover permitted purposes, retention, deletion, subprocessors, international transfers, security controls, and assistance with individual rights. It should also address model training: the customer should know whether its data is used to improve a shared model, a customer-specific model, or an internal evaluation process. Silence on training can create a conflict even when operational hosting is properly secured.

Intellectual-property language needs separate treatment for input material, generated output, configuration files, connectors, tool code, and human edits. A statement that the customer owns “all outputs” may be technically uncertain if the system produces only suggestions or if output resembles pre-existing material. The agreement should address what happens when output is non-exclusive, what license the customer receives, and whether the vendor retains rights in underlying orchestration technology. It should also allocate responsibility for third-party code introduced through an agent-generated change, including notices, scanning, replacement, and customer credits where a defect prevents release.

Confidentiality must extend beyond humans. Prompt histories can reveal customer records, system instructions, unreleased product plans, credentials, and legal strategy. Contracts can require encryption in transit and at rest, least-privilege authentication, secret scanning, redaction where appropriate, and limits on vendor personnel access. The parties should decide who may retrieve agent memory or embeddings after termination. A defensible retention rule is to delete customer content within a stated period, commonly 30 to 90 days after contract end, while retaining a shorter, access-controlled record needed for billing, compliance, or dispute resolution.

## Liability, Indemnities, Warranties, and Insurance

A liability clause should distinguish direct financial loss from consequential categories such as lost profits, lost revenue, data restoration, regulatory response, business interruption, and third-party claims. Contract law and public policy may prevent some limitations from applying, particularly where the vendor supplies professional advice or processes regulated data, but the agreement can still allocate risk within permitted boundaries. Blindly copying a “total liability equals fees paid in 12 months” position may be commercially unacceptable when the agent can modify production systems. Conversely, unlimited liability is rarely necessary for every low-risk workflow.

An indemnity should identify covered claims, such as third-party intellectual-property infringement, breach of confidentiality, unlawful processing of customer data, or vendor-caused security incidents. It should state defense control, notice, cooperation, settlement terms, and whether the customer must mitigate. Exclusions should be specific, including customer instructions, modified components, unsupported use, and losses caused by a customer credential that was compromised despite agreed controls. Broad phrases such as “loss arising from AI” can leave the customer bearing losses even when the vendor designed a defective permission model.

Warranties should cover authority, malware-free deliverables, documented security controls, lawful use, service availability, and conformity to agreed specifications. The vendor can appropriately avoid promising that an AI system will always produce a correct or legally safe answer. Instead, it can warrant that evaluation procedures were followed, stated limitations were disclosed, tested use cases met agreed thresholds, and known material risks were not concealed. Insurance requirements should match potential exposure, with limits selected after a quantified scenario review rather than a generic $1 million or $5 million template. Evidence of coverage, certificates, and notice of cancellation should form part of operational administration.

## Service Levels, Monitoring, and Audit Rights

A service-level agreement for an AI agent must measure more than uptime. It should include task success, policy-violation rate, human-escalation time, latency, retrieval freshness, tool-call failures, incorrect external actions, and time to restore service. The agreement should define the denominator and sampling method, because a vendor may report success across millions of easy cases while omitting a small but important class of escalations. It should also identify which metrics come from vendor telemetry and which can be independently tested by the customer.

Monitoring clauses should give the customer reasonable access to security reports, penetration-test summaries, model-change notices, evaluation results, and relevant incident statistics. Full model transparency is not always technically available, but the contract can require explanations of material changes to model versions, system prompts, retrieval sources, tool permissions, or decision thresholds. The customer should have audit rights when an incident occurs or when repeated failures indicate nonconformance. Audit costs can be allocated by cause: the customer pays routine audits, while the vendor pays when a material deficiency is found.

Records should support four distinct purposes: proving an individual action, diagnosing reliability, investigating a security event, and demonstrating compliance. That often requires tool-call logs, timestamps, identities, model and configuration versions, retrieved sources, approvals, outputs, resulting changes, and human interventions. Logs can contain sensitive data, so access and retention should be bounded. As a starting point, organizations commonly retain operational logs for 90 days to 12 months and security records for 12 to 24 months, but regulations, investigations, and contractual commitments can justify a different schedule.

## Procurement, Implementation, and Change Management

The contracting sequence matters because buying a platform and authorizing an autonomous workflow are separate decisions. A master agreement may cover licensing, data, security, and general liability, while a statement of work defines the initial use case, benchmark set, user population, integration architecture, and acceptance criteria. The statement of work should identify which party selects business rules, prepares data, configures tools, trains staff, and verifies the production release. It should include a readiness gate for poor documentation, excessive permissions, missing test cases, or unclear ownership.

Pricing should be evaluated across more than the subscription fee. Buyers should calculate integration work, model consumption, retrieval storage, evaluation datasets, observability, human review, security testing, insurance, and support during incidents. A vendor charging $30 per user per month becomes less predictable if each action triggers separate inference, retrieval, and tool-execution charges. Contracts should therefore set usage allowances, overage rates, price-adjustment caps, and a right to suspend extreme consumption before unexpected spending occurs.

Pilot success should not automatically authorize production deployment. A 30-, 60-, or 90-day trial may establish baseline performance, but scale-up should depend on agreed metrics, risk reviews, and permission reductions. For agents that act externally, a shadow mode can compare proposed actions with human decisions before they are executed. Production expansion should expand one variable at a time, such as user count or permitted action classes, and should trigger a new review if the model, prompt, connector, data source, or risk profile changes materially.

## Common Mistakes and the Right Time to Act

The most common mistake is treating “AI agent” as if it were one stable product category. Contracts fail when teams omit whether the agent sends messages, changes records, commits funds, generates advice, or deploys code. Another error is assigning all accountability to the customer while requiring the vendor to supply model, security, and tool details unavailable to the customer. The opposite mistake gives the vendor exclusive responsibility for business decisions that depend on customer policies and data.

Companies also make vague promises, such as requiring the vendor to guarantee zero errors or “comply with all applicable law” without identifying the relevant systems and jurisdictions. Silent model updates, unlimited subprocessor substitution, unclear training rights, and human approval without meaningful visibility are additional risks. Finally, accepting a generic AI addendum after signatures does not resolve conflicts with the master agreement, statement of work, data processing terms, security schedule, or order form.

A smaller organization should act now if it already lets an agent access customer data, internal code, financial systems, or external communications. Waiting is reasonable for an offline prototype that cannot affect a person, system, or record, provided the team still removes production credentials and prohibits external side effects during testing. Organizations should formalize clauses before launch, but should use lighter controls for a read-only assistant than for an agent authorized to execute transactions. The correct time to negotiate is when permissions, costs, and accountable owners become real, not when a pilot merely produces an impressive demonstration.

The practical first step is to inventory each tool and data source, classify action risk, and draft an authority matrix. Procurement, security, privacy, legal, engineering, and the business owner should then reconcile their terms and test whether the contract matches the system’s actual architecture. A clause review should be repeated after material model, connector, or workflow changes; annual legal review alone will not keep pace with software that can gain or lose capabilities through configuration. Companies that do this will not eliminate every AI risk, but they can replace later uncertainty with clearer responsibility, faster evidence, and more credible remedies.

## Quick answers

### Do AI agents require a different contract from ordinary SaaS?

Usually, yes, when the agent can take external actions rather than only return information. Existing SaaS terms can cover the platform, but an agent deployment also needs clauses for tool permissions, autonomous decisions, human approval, model changes, logs, and liability for completed actions.

### Can a vendor guarantee that an AI agent will never make an error?

A credible vendor will usually avoid an absolute no-error warranty because probabilistic systems can produce unpredictable outputs. The parties can instead define tested use cases, task-success thresholds, prohibited actions, human-review gates, incident duties, and remedies for missed service levels.

### Who should own prompts, logs, and AI-generated output?

Ownership should be allocated separately because each asset raises different questions. Customer data and confidential inputs are commonly controlled by the customer, while the vendor may retain its platform technology; output rights depend on the governing law, use of external material, and what the customer actually receives.

### What should happen when an AI agent causes damage?

The agent itself normally has no contractual capacity, so liability belongs to the companies that designed, deployed, supervised, or instructed it. The agreement should preserve logs, define causation, require notice and mitigation, and allocate third-party claims, restoration work, regulated penalties where insurable, and other recoverable losses.

### How much liability should an AI agent contract include?

There is no universal percentage or dollar cap because exposure depends on permissions, data, transaction value, and the availability of insurance. Low-risk internal assistants may justify narrower terms than agents that deploy code, move money, terminate accounts, or communicate externally.

Canonical: https://zdnetinside.com/knowledge/what_contract_clauses_should_companies_use_for_ai_agents_in_2026.php
Markdown: https://zdnetinside.com/knowledge/what_contract_clauses_should_companies_use_for_ai_agents_in_2026.php/index.md