What Should an AI Agent Contract Say?

What you can decide after checking the facts

A better-informed decision starts with what is known, what still needs checking, and who will take the next step. The following are practical objectives to consider for this particular issue:

• Specify authority limits.
• Assign provider and customer obligations.
• Describe log and audit requirements.
• Establish intervention and exit procedures.

Why the evidence matters

US-TechLaw is an independent technology-law research and consulting platform. This page uses the applicable official rules and product-provider documentation as reference points, rather than relying on broad claims about what every AI system or business must do. Where company-specific contracts or settings would change the conclusion, they are identified as facts to verify instead of assumed. The research is informational and does not replace qualified advice for a particular situation.

How to raise your specific question

Describe the decision or problem in a few sentences, identify the product or system involved, and state what result you need to understand. Do not send privileged documents, complete customer files, credentials, or sensitive operational records in an initial email. The scope, appropriate expertise, and any secure exchange of additional documents should be determined separately before detailed review.

Questions worth preparing:

• Is the vendor delivering software, a managed service, or an integration?
• Are provider logs and model changes contractually visible?

Questions, documents and safeguards to review

How is an AI agent different from ordinary software?

An AI agent can go beyond answering questions. Depending on its configuration, it may call tools, update records, send communications, and make choices within a workflow. The agreement should identify that operational role in ordinary language and specify the connected services and permitted action categories. A contract for a text assistant should not simply be reused for an agent that can amend customer accounts. Define whether the product is experimental, supervised, or approved for live operations, and ensure the written description matches the actual technical permissions.

What actions is the agent permitted to take?

Write permissions as actions that can be tested. “May assist customer support” is vague; “may draft replies but may not send them without approval” establishes a checkable boundary. Distinguish reading files, summarizing data, editing records, contacting outsiders, approving a request, and changing security settings. Identify prohibited actions and circumstances requiring human review. If the agent can add tools or invoke third-party services, the agreement should explain how the authorized scope can change. Supporting configuration records should show that technical access corresponds to what the customer approved.

How should approval and human review work?

Human oversight needs a practical design, not only a statement that the customer remains responsible. Specify who receives approval requests, which action categories require consent, how long an unanswered request may remain open, and what happens when the reviewer rejects it. Where a workflow can cause material harm, provide an interruption path and a named escalation owner. A contract can allocate responsibilities for these controls, while the implementation record verifies that they function. NIST's risk-management materials support proportionate governance and monitoring of AI-system risks. (NIST AI Risk Management Framework, Generative AI Profile)

Which data and connected systems can it access?

An agent that reads a knowledge base poses different access questions from one that can edit the CRM, use email, or invoke an external API. Identify each connected system, credentials model, personal-data category, and permitted transfer. Require the parties to describe whether actions run under an end user's identity, a service account, or another agent identity. The chosen mode matters because it can change what the agent can see. Include responsibility for access reviews, revocation after staff changes, and controls over sensitive information exposed through generated replies.

What must the provider record and report?

Operational records make a contractual promise verifiable. Identify which prompt versions, tool invocations, approvals, configuration changes, and error events must be retained, who can inspect them, and how sensitive information will be protected. Define who reports a material incident and what technical facts an initial report should include. Avoid an unlimited requirement to preserve every conversation regardless of privacy and security needs. The evidence scheme should let the customer reconstruct important actions without unnecessarily creating a new repository of confidential information.

Who handles mistakes and third-party dependencies?

Separate the supplier's promises about its software from the customer's choices in configuring it. The provider may control model updates or hosting; the customer may select business rules, approve data sources, and decide which employee may publish an agent. A third-party connector might have its own limitations. Describe change notifications, required approvals, and what happens if an important integration fails. The allocation should be tailored to the actual system rather than copied from a general SaaS template. Specific contract wording requires review of the transaction and governing law.

What happens when the model or agent changes?

Exit planning matters when the agent has learned operational patterns through prompts, workflow rules, connected tools, and records. Determine which instructions, logs, configurations, datasets, and decision histories can be exported in a usable format. Specify how the agent is suspended, how credentials are revoked, and what evidence remains accessible for incident review. If the supplier changes a model or removes a tool, the customer should know whether regression testing is required. The goal is continuity of the customer's process and a controlled handover, not a promise that one vendor's agent can be moved unchanged to another.

How does the customer exit without losing its workflow?

A useful negotiation sequence begins with a workflow diagram, then an action-and-data table, then specific contract provisions. Review the terms against a realistic incident: an agent sends a message it should have drafted only, or changes a record that should have required approval. Can the parties identify who should have stopped it, which record would prove the sequence, and how it would be corrected? If the answer is unclear, the technical configuration and agreement are not yet aligned. Document open issues before the product is launched to customers.

Example: how the decision changes with the facts

Illustrative scenario, not a client case or statement of actual results.

A software supplier promises an AI assistant that will “manage customer cases.” During testing, the customer discovers the agent can close cases automatically, although the buyer expected only suggested replies. A useful contract should define whether closure is permitted, which cases require approval, how actions are logged, who controls connector permissions, and what happens after an incorrect closure. The company can then compare the signed promises with the actual configuration. If supplier or customer changes an action after launch, a documented review should occur. This example shows the difference between a broad description of convenience and a testable statement of authority.

Decision and evidence table

Documents and facts to prepare

For a reliable review, identify the specific system or agreement, the date and version of its relevant terms, the business decision being made, the people affected, and the records available to support the answer. The most helpful starting material for this topic is: Agent clause-selection matrix and contract-to-control traceability grid. A request for information should remain proportionate; sensitive records should be exchanged only through an appropriate authorized process.

Frequently asked questions

Is a general software agreement enough?

Not always. Autonomous actions, approval boundaries, tool access, and records may need additional express terms.

Who chooses the approval threshold?

It should be agreed by the responsible parties and reflected in the actual technical configuration.

What if the agent changes after signing?

The parties should define change notification, testing, and approval for materially different actions.

What to check before acting

Before acting, write down the decision your team needs to make: Help buyers and vendors identify contract terms that govern what autonomous agents may do. List the relevant documents and settings, the facts still missing, and the person who will confirm each point. Review the decision again if the agreement, software features, workflow, or governing requirements change. Seek qualified professional advice when the specific legal question or regulated activity requires it.

Practical guides for AI-agent business decisions

Continue with the specific business problem and compare the applicable requirements with related guidance.

• Can You Change AI Agent Providers Without Losing Your Workflows?
• Can AI Agents Handle Customer Service for Your Business?
• Can Your AI Agent Place Business Orders Without Approval?

Related business and technology guides

• Explore AI Agent Responsibilities
• Related research and practical support
• Who Is Responsible If Your AI Agent Makes a Mistake?
• How Do You Control What Copilot Studio Agents Can Do?