What contract protections do I need before giving an AI agent access to my business systems?

18 May 2026

Why a standard SaaS contract is not enough

A standard SaaS contract usually assumes the tool stores data, processes data, or helps a user do work. An AI agent is different because it can be allowed to decide what step comes next and then use tools to do it. That could mean reading a customer record, sending an email, creating a ticket, updating a deal stage, exporting a report, changing a calendar, raising an invoice, or modifying code.

The risk is not theoretical. The UK National Cyber Security Centre warns that agentic AI can access data sources, remember context, make decisions, use tools, and take actions in pursuit of a goal. Its guidance says organisations should start small, use agents only for low-risk tasks, and apply established cyber security controls from the outset. It also says you should never grant an agent unrestricted access to sensitive data or critical systems. Source: NCSC guidance on adopting agentic AI.

That changes the contract conversation. You are not just buying software. You are authorising a non-human actor to operate inside your business. If something goes wrong, the contract needs to answer a practical question: who had the right to do what, who approved it, who was monitoring it, and who pays if the safeguard fails?

UK adoption is rising fast enough that this is no longer a niche issue. The Office for National Statistics reported that 23% of UK businesses were using some form of AI technology in late September 2025, up from 9% when the question was introduced in September 2023. DSIT research also found that only 7% of AI adopters were using agentic AI, but that agentic AI was the AI technology where businesses were most likely to report significant implementation barriers, at 32%. Sources: ONS Business Insights, October 2025 and DSIT AI Adoption Research.

The minimum protections your contract should include

For a UK business, the minimum contract protections fall into ten groups. If the supplier cannot accept these in principle, do not connect the agent to production systems.

A practical benchmark: if you would not give a new employee that level of unsupervised access on day one, do not give it to an AI agent because the demo looked impressive.

What UK GDPR Article 28 means for AI agents

If the supplier processes personal data on your behalf, you need a written processor contract under UK GDPR Article 28. The ICO says the contract must include the subject matter and duration of processing, the nature and purpose of processing, the type of personal data, the categories of data subject, and the controller's obligations and rights. It must also require processing only on your documented instructions, confidentiality, appropriate security measures, controls on sub-processors, assistance with data subject rights, breach support, end-of-contract deletion or return, and audits or inspections. Source: ICO guidance on controller and processor contracts.

For AI agents, Article 28 needs to be made concrete. Do not accept a generic data processing addendum that says "appropriate measures" but does not explain what the agent can do. Your schedule should name the systems, data categories, permissions, locations, retention periods, model providers, hosting providers, logging tools, and support teams involved.

The most common contract gap I see is training data. Businesses assume "we own our data" means the vendor cannot use it for model training. That is not safe. The contract should say the supplier must not use customer data, employee data, confidential information, prompts, outputs, embeddings, support tickets, call transcripts, files, or metadata to train, fine-tune, benchmark, evaluate, or improve any model unless you have given specific written approval.

You should also require a clear statement on international transfers. If the AI supplier, model provider, support team, or logging infrastructure is outside the UK, the contract needs the correct transfer mechanism and a realistic description of where data goes. Vague wording such as "data may be processed globally" is not enough for a serious deployment.

The clauses that matter most when the agent can take action

The highest risk is not the agent writing a poor answer. The highest risk is the agent taking a real action that is wrong, unauthorised, or impossible to reverse. That is why the contract must separate read access from write access, and low-risk actions from high-risk actions.

Start with a prohibited actions clause. The agent should not be allowed to delete production data, overwrite backups, approve payments, send bulk external communications, change HR records, terminate accounts, change legal documents, modify security settings, or deploy code unless those actions are explicitly in scope and require human approval.

Then add an approval matrix. For example, the agent may draft a customer email without approval, but cannot send it without approval. It may recommend a refund, but cannot issue one above £100 without approval. It may create a draft invoice, but cannot submit it to Xero or QuickBooks without approval. It may open a pull request, but cannot merge or deploy code. It may summarise HR documents, but cannot change pay, performance, sickness, grievance, or disciplinary records.

You also need log retention. Ask for at least 12 months of searchable logs for ordinary deployments and longer where the agent touches regulated, financial, health, employment, or safety-critical data. The log should show the user's instruction, the agent's plan, tool calls, data accessed, approvals requested, approvals granted, system changes, errors, and rollback steps. If the supplier cannot provide this, you will struggle to investigate mistakes.

Real incidents show why this matters. The Guardian reported in April 2026 that an AI coding agent connected through Cursor allegedly deleted PocketOS production databases and backups in nine seconds, affecting car rental software used for reservations, payments, vehicle assignments and customer profiles. The company reportedly restored from a three-month-old offsite backup and spent more than two days rebuilding from Stripe, calendars and emails. Whether your risk is code, CRM, finance or operations, the contract should assume failure is possible and define the controls before access is granted. Source: The Guardian report on the PocketOS incident.

What liability cap is reasonable?

Most SaaS suppliers try to cap liability at fees paid in the previous 12 months, or sometimes one to three months of fees. That may be acceptable for a note-taking tool. It is usually too low for an AI agent with production access.

For low-risk pilots, a cap equal to 12 months of fees may be workable if the agent has no write access, no sensitive data, and no customer-facing authority. For a real deployment, I would normally expect a separate higher cap for data protection, confidentiality, security incidents, IP misuse, and breach of the agreed access controls. For high-risk deployments, that cap may need to be several times annual fees, backed by cyber insurance and professional indemnity insurance.

The reason is simple: breach costs are not theoretical. The UK Government Cyber Security Breaches Survey 2025 found that 43% of UK businesses identified a cyber security breach or attack in the previous 12 months, equating to about 612,000 UK businesses. Medium and large businesses had much higher prevalence, at 67% and 74%. The same survey found only 14% of businesses reviewed risks posed by immediate suppliers, and only 7% reviewed wider supply chain risks. Source: UK Government Cyber Security Breaches Survey 2025.

IBM's 2025 UK Cost of a Data Breach report also found that 63% of responding UK organisations did not have AI access controls in place, and that third-party vendor and supply chain compromises were the most commonly reported breach cause at 18%. IBM reported UK organisations using extensive security AI and automation had breach costs of £3.11 million, compared with £3.78 million for those not using those technologies. Source: IBM UK Cost of a Data Breach 2025.

That does not mean every small business needs a seven-figure liability clause for a small AI pilot. It does mean the cap should reflect the real operational risk, not just the vendor's subscription price.

What UK businesses are getting wrong

The first mistake is treating AI procurement as an IT purchase only. If the agent touches customer data, employee data, money, legal commitments, regulated activity, or critical operations, legal, data protection, security, and operations should all review the contract before integration.

The second mistake is accepting broad vendor wording. Phrases such as "reasonable security", "service improvement", "affiliates and partners", "anonymous usage data", and "automated actions" need definitions. In AI contracts, broad wording can quietly permit model improvement, overseas processing, opaque sub-processors, wide logging, or uncontrolled tool use.

The third mistake is failing to define the business owner. The NCSC says humans remain accountable for the decision to deploy an agent, the access it was granted, safeguards, and consequences. Your contract and internal policy should name the owner who approves access, monitors behaviour, reviews incidents, and can stop the agent.

The fourth mistake is skipping the exit plan. Before go-live, you should know how to turn the agent off, revoke tokens, disable API keys, rotate credentials, export logs, retrieve data, delete embeddings, remove webhooks, and prove that sub-processors have stopped processing your data.

Finally, do not rely on prompts as a legal control. A system instruction that says "never delete production data" is useful, but it is not a contract, not an access control, and not a substitute for permissions that make deletion technically impossible unless a human approves it.

When this does NOT apply

You do not need a heavy AI agent contract for every AI use case. If a team member uses a locked-down enterprise chatbot to rewrite public marketing copy, with no personal data, no confidential uploads, no integration, and no autonomous action, then a lighter acceptable use policy and supplier review may be enough.

You also may not need a bespoke contract for a very small internal experiment where the agent runs in a sandbox, uses synthetic data, has no internet access, has no production credentials, and can be deleted after testing. That is the right way to start.

But the moment the agent connects to real systems, the calculation changes. If it can read customer data, update records, make decisions, send messages, trigger workflows, or use privileged credentials, you need written protections before it goes live.

If you are unsure where the line sits, start with this test: could the agent's mistake create a customer complaint, regulatory duty, financial loss, operational outage, employment issue, or security incident? If yes, the contract matters.

A practical pre-signing checklist

Before signing, ask the supplier for the following evidence and attach the answers to the contract or order form:

• A list of all systems the agent will access.
• A list of all actions the agent can take in each system.
• A data processing schedule covering UK GDPR Article 28 requirements.
• A list of sub-processors, hosting locations, model providers, logging tools, and support locations.
• A written ban on unauthorised training, fine-tuning, evaluation, or model improvement using your data.
• Technical evidence of least privilege permissions.
• Human approval points for high-risk actions.
• Audit log format, retention period, export rights, and incident preservation rules.
• Incident notification timescales and investigation support duties.
• Insurance details, liability caps, and exclusions.
• Termination, deletion, return, credential revocation, and exit support terms.
• A named business owner on your side and a named accountable contact on the supplier side.

If the supplier resists all of this, that is a useful answer. They may still be a good supplier for a sandbox or advisory project, but they are not ready for autonomous access to your business systems.

If you want help assessing whether an AI agent deployment is safe enough for your business, read our guide to AI automation readiness or book a free consultation. No pitch, no pressure, just a practical review of the use case and the risks.

Is This Right For You?

This applies if an AI agent will connect to systems that contain customer data, employee data, financial records, source code, production databases, contracts, inboxes, support tickets, payment tools, or operational workflows.

It may not apply if you are only using a public chatbot for low-risk drafting with no business system access and no personal data. Even then, you still need internal rules on what staff can paste into the tool.

If the agent can take an action that would matter if a junior employee did it, treat it like a system user, not a piece of software. That means access control, logs, supervision, exit rights, liability, and a written data processing agreement.

Frequently Asked Questions

Do I need a data processing agreement for every AI agent?

You need one where the supplier processes personal data on your behalf. If the agent touches customer records, employee records, support tickets, CRM data, emails, call transcripts or usage logs linked to individuals, assume UK GDPR applies and get Article 28 terms in writing.

Can the AI supplier use my business data to train its model?

Only if you have clearly agreed to it. Your contract should expressly ban use of your prompts, files, outputs, records, embeddings, metadata and system data for training, fine-tuning, benchmarking or model improvement unless you give specific written approval.

Is human approval legally required for AI agent actions?

Not for every action, but it is a sensible contractual and operational control for high-risk actions. Require approval for deletion, payments, external communications, HR changes, legal commitments, security changes, code deployment and anything customer-impacting.

What liability cap should I accept for an AI agent supplier?

For a low-risk pilot, 12 months of fees may be acceptable. For production access, ask for separate higher caps for confidentiality, security, data protection and breach of agreed access controls. The cap should reflect the damage the agent could cause, not just the monthly licence fee.

Should AI agents have administrator access?

Almost never at the start. Use least privilege access, temporary credentials, restricted scopes and separate service accounts. If administrator access is genuinely necessary, it should be time-limited, logged, approved and reviewed after the task.

What should audit logs include?

Logs should show user instructions, agent plans, prompts, tool calls, data accessed, approvals requested, approvals granted, actions taken, errors, system changes and rollback steps. You should have export rights and a retention period long enough to investigate incidents.

Can I rely on the supplier's standard terms?

Usually not if the agent has real system access. Standard terms often miss training data, tool permissions, approval gates, log retention, sub-processor detail, exit mechanics and liability for autonomous actions. Use an order form or addendum to close those gaps.

What is the safest way to start?

Start with a sandbox, synthetic or low-risk data, read-only access, no customer-facing actions and clear human review. Expand only after the agent has been tested, logged, monitored and governed under a written agreement.