Quick answerA contract covering an AI agent that only reads data or holds a conversation needs terms about data handling and confidentiality. A contract covering an agent that takes real write actions inside a customer's own systems, updating a record, issuing a transaction, changing a configuration, needs a fundamentally different set of terms: scoped and revocable write permissions, an audit log the customer can independently inspect, a defined liability allocation for an incorrect or unauthorized write, and a rollback or compensation mechanism for when one happens. Negotiate these before granting write access, not after the first incident forces the conversation.
Scope the write permissions as narrowly as the use case allows
Do not negotiate a single broad write grant when the actual use case only needs a handful of specific actions. List the exact write operations the agent needs, field by field or endpoint by endpoint if the integration allows it, and put that list in the contract itself rather than leaving it to a technical integration doc that can drift without triggering a contract review. A vendor agreement that grants broad write access because it was easier to negotiate once is much harder to walk back later than one that starts narrow and gets expanded deliberately as trust and track record build. This scoping discipline mirrors the internal design question covered in what data you need ready before onboarding an AI agent, extended here to the contractual layer with an external customer's own systems rather than your own data.
Put liability allocation in writing before the first incorrect write happens
An agent that only reads and talks has a bounded failure mode: it says something wrong, and a human can correct the record. An agent that writes into a customer's system has failure modes with real financial and operational consequences: a mispriced transaction, an incorrectly updated inventory count, a configuration change that breaks another system downstream. Negotiate explicit liability terms for these scenarios upfront, including who bears the cost of an incorrect write, what the notification timeline is once one is discovered, and whether there is a cap. This is a more specific version of the general question addressed in AI agent legal liability for wrong information, narrowed to actions rather than statements, since an incorrect write typically causes more concrete damage than an incorrect answer.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Require an audit log the customer can inspect independently
A customer granting write access to their own systems needs the ability to see exactly what the agent changed, when, and under what authorization, without depending entirely on the vendor's own internal logging to reconstruct it after something goes wrong. Build this into the contract as a requirement, not just an engineering nice-to-have: a customer-accessible audit trail of every write action, retained for a defined period, and made available on request rather than only after a formal dispute. This connects directly to the broader agent-to-agent integration groundwork already covered in what to nail down before a customer's AI agent talks to yours, which addresses the conversational and data-ownership side of two agents interacting; this post's audit requirement is the specific piece needed once one of those agents can actually change state in the other's systems.
FAQ
Should write access always require a separate contract addendum from read-only access? Not necessarily a separate document, but it should be a separate, explicitly negotiated section, since bundling write permissions into a general data-access clause makes it too easy to grant broader access than the use case actually needs.
Who should own the rollback mechanism, the vendor or the customer? The vendor providing the agent should build and test the rollback capability, but the contract should specify the customer's right to trigger it and the maximum time allowed to execute it, rather than leaving rollback as an informal best-effort commitment.
Does this apply to internal, employee-facing agents that write into company systems too? Yes, the same principles apply even without an external customer relationship; the difference is that the terms live in an internal policy or SLA rather than a customer-facing contract, but the scoping, liability, and audit requirements are the same.