What Is Your AI Agent Allowed to Commit You To?

Software that only answers questions is easy to reason about. Software that acts is not. An agent that can book the travel, send the follow-up, open the ticket, place the order, or push the change is doing work that staff previously handled themselves. The interesting questions are about authority, not intelligence.

Quick answer. An AI agent that can act — send email, place orders, change records, move money — can take actions in your company's systems and communications without a person handling each step. The practical question is not whether it is clever but what it is permitted to do without a person. Four things settle that: the scope of what the agent may do, the threshold above which a human approves, a log that shows what it did, and what happens when it goes outside those limits. The tool's settings are important, but they are not a substitute for clear vendor terms and an internal policy. Accord & Shield Legal, PLLC reviews AI vendor agreements and drafts internal AI use policies for businesses in Arizona, California and Texas, starting with a free 15-minute consultation.

A deployment decision can focus narrowly on the workflow and leave unanswered what the company is willing to let the tool do.

Start with the boring question: what can it actually do?

Not what the vendor's page says it can do — what your configuration permits. An agent connected to a mailbox can send things. An agent connected to a payment method can spend. An agent connected to a CRM can change the record that your invoicing runs on. Broader access creates more opportunities for error or misuse. During setup, it is easy to grant more access than the intended use requires.

Write the intended scope down before the first run, in plain terms: what it may do, what it may never do, and which systems it may touch. That document does two useful things later. It gives you something to compare the vendor's terms against, and it gives you something to compare the agent's actual behaviour against.

Set the threshold where a human is required

For an agent that can take meaningful action, set a line: below it the agent may act alone; above it, a person approves. Most teams never state the line, which means the tool's defaults set it for them.

The threshold does not have to be a dollar amount, though that is the easiest one. It can be a kind of action — anything that sends to a customer, anything that changes a price, anything that touches a signed agreement, anything that creates an obligation to a third party. What matters is that the line exists, that it lives somewhere other than one person's head, and that the tool is actually configured to enforce it.

Assume you will have to prove what happened

When something goes wrong, the first question is what the agent did and when. That is a logging question. It is partly a contract question: does the vendor keep a record of the agent's actions, can you export it, how long do they retain it, and can you get it quickly when someone is asking?

The time to establish that is before you need it. If a customer, auditor, or regulator asks what happened, you will want records that let you reconstruct the agent's actions.

What your vendor agreement should settle

Most of this is ordinary contract work, and the terms that matter for an acting agent are not the same as the ones that matter for a chatbot:

• Scope and permissions — what the product may do in your systems, and what changes if the vendor ships a new capability. Many AI products expand what they can do without a new contract. We cover the questions worth asking an AI vendor in a separate post.
• Logs and audit — what is recorded, how long it is kept, and how you get a copy.
• Data use — whether your inputs and outputs train anything, and whether your customers' data is in scope.
• Subprocessors — who else touches the data, and whether you are told when that list changes.
• Failure and notice — what the agreement requires if the agent acts outside the agreed scope, including how and when the vendor must notify you.
• Exit — how quickly you can turn it off, and what you take with you.

What your own policy should settle

The contract governs the vendor. It does not govern your team. A short internal policy is usually the missing half:

• Who may connect an agent to a company system at all.
• What the approval threshold is, in the terms above.
• Who is accountable for a given agent — an actual named person, not a team.
• What someone does when an agent has done something it should not have: who is told, how the agent is stopped, and what gets preserved.

None of that requires a long document. It requires a decision, written down.

Where your customer contracts come into it

If an agent touches work you do for customers, review the commitments in those contracts first. Using software to perform the work does not by itself change what the agreement says about confidentiality, customer data, security practices, or subcontractors. Before an agent touches customer work, confirm that the planned use fits those commitments.

The part worth getting right first

If you only do one thing: write down what the agent may do, and the line above which a person approves it. Everything else — the vendor terms, the logging, the policy — is easier once that exists, because it gives you something concrete to use in reviewing the vendor's commitments and your team's practices.

This post is general information about contracting for AI tools and is not legal advice. What your business should do depends on your agreements, your systems, and the facts. Reading this post does not create an attorney-client relationship. For guidance on your specific situation, please consult a qualified attorney.