What Should Your Terms of Service Say About AI Agents?

Most terms of service were written on the assumption that a human is reading the screen, and that assumption is no longer safe. If your product has accounts, software is already logging in as your users, and your agreement probably says nothing about it. The fix is not a rewrite. It is five decisions you can make in an afternoon: whether you permit agent access, how you tell delegated access apart from bulk automation, who answers for what the agent does, what remedy you have short of shutting an account off, and whether your technical controls match the document.

The part most founders have not noticed

There are two conversations about AI agents and only one of them gets written about. The loud one is about the companies building agents. The quiet one, which involves far more businesses, is about everyone whose product agents are already using.

If you sell software with a login, some percentage of today's sessions are a person telling a tool to go handle something for them. Your support queue will see it before your legal file does: a customer says the app "broke" during a flow no human would have run that fast. That is not a hypothetical risk to manage next year. It is traffic you already have and cannot currently name.

Why your existing terms do not cover this

Pull up your agreement and look for the word "automated." If you find anything, it is almost certainly an anti-scraping clause written to stop competitors from harvesting your data at scale. That clause was drafted with a crawler in mind, not a tool your own paying customer chose to point at their own account.

That mismatch creates the actual problem. Most terms also contain a flat prohibition on sharing credentials. Read literally, that language bans the agent your best customer is enthusiastic about using, which means you are either enforcing a rule you do not believe in or ignoring a term in your own contract. Neither is a good position, and the second one is worse than having no clause at all. A term you never enforce is evidence you did not mean it.

Founders sometimes assume the anti-hacking statutes cover the gap. They are a thinner tool than most operators expect, courts have been reading them narrowly for years, and the law on who is responsible when software acts on a user's instruction is actively moving. Plan around your own contract instead. It is the document you control.

The five decisions

One: decide whether you permit agent access, and say so. The wrong answer is silence. Silence means your position gets set later by whoever is arguing with you. Pick yes, no, or yes-with-approval, and write it down.

Two: separate delegated access from bulk automation. These are different activities and they deserve different rules. A customer directing a tool at their own account, with their own credentials, inside their own plan limits is a product question. A third party pulling your catalog at machine speed is a different one. Terms that treat both as "bots" will either be too permissive on the second or absurd on the first.

Three: say who is responsible for the agent's actions. If a user delegates to a tool, the cleanest position is that the user remains responsible for what happens in their account, including orders placed, data exported, and changes made. Say that plainly. It resolves the argument that starts the first time an agent misreads an instruction and does something expensive.

Four: give yourself a remedy that is not termination. Most agreements offer one lever, which is suspension, and it is too blunt to actually use on a paying customer. Add rate limits, a right to require identification of automated traffic, an approval or allowlist path, and the ability to suspend a specific integration rather than an account. Graduated remedies get used. Nuclear ones do not.

Five: make the document match the building. If your terms require agents to identify themselves, you need some way to tell whether they did. If they impose rate limits, those limits should exist in code. Terms your systems cannot see are aspirations.

If you are the one building agents

The same analysis runs in reverse, with one addition. Your exposure sits mostly in other companies' terms of service, which means it is contract analysis and it is site by site. A few large platforms have already amended their user agreements to address buy-for-me and LLM-driven tools directly, and more will.

Two practical notes. Document how your agent actually communicates, because the architecture matters to the legal analysis and your next diligence process will ask. And keep your sales team calibrated: "a court said this is fine" is a claim that will be read closely by a customer's counsel, and it is rarely what any decision actually said.

What is still open

A fair amount. Congress is looking at agent access from the opposite direction, with a discussion draft circulating that would require the largest platforms to let authorized agents act for users rather than let platforms exclude them. It has not been introduced and is not something to build a plan around, but it signals that the eventual fight is about interoperability, not trespass.

The harder questions have no answer yet. When an agent acts on an ambiguous instruction and gets it wrong, whose loss is it. When a site publishes content designed to steer agents toward its own products, is that marketing or manipulation. Agency and payments law were not built for a counterparty that is guessing at intent. Anyone telling you this is settled is selling something.

Which is the argument for handling it in your contract now, while it is a drafting exercise instead of a dispute.

Where to start

Open your terms of service and answer the five questions above. If four of them are unanswered, that is normal and it is a one-sitting fix, not a project.

Frequently Asked Questions

Do I have to allow AI agents to use my product?

No. Nothing requires you to accept agent traffic. The decision is yours, and the point of addressing it in your terms is to make the decision deliberately rather than inherit one by silence.

My terms already ban bots. Isn't that enough?

Usually not. Anti-bot language is typically anti-scraping language, aimed at third parties harvesting data at scale. It does not describe a customer pointing a tool at their own account, and applied literally it often prohibits something you would actually want to permit.

Who is responsible if a customer's AI agent does something costly in their account?

That depends on what your agreement says, which is the reason to say something. The common position is that a user who delegates to a tool remains responsible for actions taken in their account. Absent language, you are arguing from first principles at the worst possible moment.

Should I ban credential sharing with AI tools?

Look at the clause you already have, because most agreements ban credential sharing outright and were not written with agents in mind. Decide whether you mean it. If you want to permit delegated access, carve it out explicitly and set conditions rather than leaving a prohibition you do not intend to enforce.

Is there a law coming that will settle this?

Not yet. A federal discussion draft addressing agent access to large online platforms has circulated but has not been introduced, and the broader questions about responsibility for autonomous software remain unresolved. Contract terms are the practical tool available now.