A Customer Request Is Not Blanket Permission for Your AI Agent

Your customer asked you to book an appointment. They did not ask you to share their entire history with every tool your agent can reach.

Separate the requested outcome from the data journey

A customer asks your assistant to arrange a visit. The assistant finds an appointment, checks the CRM, reads an earlier email and contacts a subcontractor. The result might be useful. It does not follow that every piece of information accessed or shared was necessary, expected or lawfully processed. The instruction describes an outcome. Your business still decides which routes to that outcome are acceptable.

This is a particularly important distinction for agents because the route can change between otherwise similar requests. One booking might require only a postcode and available dates. Another might tempt the system to search an entire mailbox or send a detailed customer history to an external tool. Technical access, user authority and a lawful basis for personal information processing are related questions, but they are not the same question.

In its October call for evidence on lawful processing, the ICO explicitly says that a contract or a user's instruction does not automatically provide a lawful basis for all subsequent processing. Different stages can require different bases. It also explains that the contract basis applies where handling the information is objectively necessary to provide the service requested, not simply where it would make the provider's workflow easier.

What this means in practice is simple: describe the shortest acceptable data journey before connecting the agent. Identify the person whose information is involved, the purpose, the minimum fields and the recipient. Then identify what would make the task exceed that boundary. A request to book an engineer should not silently become permission to profile the household, enrich a marketing record or disclose an unrelated complaint. Those are separate processing decisions, even if the same assistant can perform them.

The instruction describes an outcome, not unlimited permission to use the customer's information.

Build a processing map, not a single permission checkbox

Start with one real workflow and separate its processing activities. For a service booking, these might be interpreting the enquiry, retrieving the customer's address, checking availability, passing contact details to an engineer and retaining the appointment record. Model improvement, supplier analytics and future marketing should appear separately rather than being folded into the booking because they happen on the same platform.

Give each activity an owner and a clear explanation of the proposed lawful basis. Do not let the agent invent that explanation at runtime. Where contract is proposed, ask why the activity is objectively necessary for the requested service. Where legitimate interests is proposed, complete the appropriate assessment rather than treating the label as a convenient fallback. The ICO's current discussion specifically warns against assuming that legitimate interests applies by default.

The map should also distinguish your organisation from the suppliers it uses. A model provider, a booking platform and a specialist external tool may have different roles and different data uses. Read the relevant terms and settings. A supplier saying it offers a compliant product does not establish that your chosen use, fields, recipients and retention arrangements are appropriate. Salesforce Agentforce or a custom assistant connected to a CRM still needs that deployment-level analysis.

A useful record can be modest: activity, purpose, person affected, fields, recipient, proposed basis, supporting assessment and permitted fallback. Add a separate flag for device access or sensitive information so those questions cannot disappear into a general approval. This is an operational design record, not a request to write a legal essay for every button. Its value is that a reviewer can identify the unsupported step before the agent performs it, rather than reconstructing the justification after a customer objects.

Map the booking, the analytics and the marketing as separate activities, even when one platform performs all three.

Use consent where it fits, not as a universal repair

One tempting answer is to put a large 'I agree to AI' checkbox in front of the whole service. That may feel decisive, but it does not solve the underlying design problem. An individual cannot make an informed, specific choice about a data journey you have not understood or explained. An approval screen also cannot make unnecessary collection necessary or remove your other data protection responsibilities.

The ICO lists five characteristics of valid consent in its agentic AI discussion: freely given, informed, specific, unambiguous and revocable at any time. That is a useful product review checklist, not permission to collect consent indiscriminately. Where consent is the basis you rely on, the system needs a meaningful way to respect refusal and withdrawal. Merely storing a timestamp beside an ambiguous checkbox does not establish that the choice was valid.

Keep consent distinct from an operational confirmation. Asking 'Shall I send your address to this engineer to arrange the visit?' can help the customer understand and control a particular disclosure. Whether the underlying processing relies on consent, contract or another appropriate basis depends on the facts. Do not label every confirmation as GDPR consent, and do not assume that a confirmation proves the whole workflow is lawful.

Device access needs separate attention too. The ICO explains that storing information on, or accessing stored information from, an end user's device engages PECR requirements: an applicable exception or consent is needed. That is not automatically settled by selecting a UK GDPR basis for the wider service. If your agent reads a browser session or local information, ask the responsible specialist to examine that behaviour specifically. Where special category information is involved, assess the additional requirements rather than assuming ordinary consent or a general contract is enough.

An approval button, valid consent and a lawful basis are three different things.

Put the boundary in the tools the agent can actually use

A carefully written instruction is useful, but it should not be the only barrier between a routine task and an excessive disclosure. Give the agent a booking tool that accepts a defined set of fields rather than unrestricted access to customer records and a general-purpose send function. Make the permitted recipient and purpose visible in the workflow. Reject extra fields rather than hoping the model remembers not to include them.

Consider a hypothetical plumbing business. Its assistant can share a service address, contact number, fault description and appointment window with an approved engineer. It cannot send the customer's full support history. If an access requirement contains health information, the workflow pauses for an appropriately authorised person to decide what is necessary and how to handle it. This example illustrates a design choice, not a claim that every business has the same legal basis or obligations.

What this means in practice is that approval has to match the action. A reviewer should see the actual recipient and proposed fields, not a vague message saying the agent is about to 'complete the booking'. If the recipient changes, or a new tool needs additional personal information, re-evaluate that step. A previous approval should not become a reusable token for a materially different disclosure.

Test the exception path as deliberately as the successful booking. What happens if the preferred supplier is unavailable? Can the agent choose another supplier without checking whether that recipient is approved? Does it copy private email content into a tool error report? Can the task complete without optional information? A good fallback is often to save a minimal draft and ask a person to finish it. That is more useful than treating every uncertain request as permission to explore further.

Make the permitted disclosure a tool constraint, not just a sentence in the prompt.

Reduce friction by narrowing the task, not weakening the check

The strongest counterargument is commercial: customers want a completed task, not a series of privacy questions. That concern is legitimate. Repeatedly asking people to approve routine steps can make a service harder to use and encourage thoughtless clicking. The answer is not blanket permission. It is a narrower service with clear defaults, predictable recipients and additional checks only when the task genuinely changes.

Predefine the ordinary route. Tell people in plain terms what the assistant does and which information it normally needs. Keep optional uses separate. Reserve an extra confirmation or human review for material changes such as an unexpected recipient, sensitive information or a new purpose. Measure completion time alongside excessive disclosures, failed withdrawals and tasks that could not proceed without optional data. Faster is not better if the design quietly removes meaningful choice.

There is a current UK reason to make this practical rather than theoretical. The ICO consultation opened on 8 October and closes on 20 November 2026. Its six substantive themes include lawfulness, transparency and purpose limitation. In a separate 8 October supervision update, the ICO named ten foundation model developers that had made or committed to changes, including Amazon, Anthropic, Google, Microsoft and OpenAI. These are examples of regulatory scrutiny, not a certification that any particular agent configuration is compliant.

The call for evidence describes current thinking and asks for practical experience; it is not a new blanket legal permission or a final agent-specific code. Existing duties still need to be assessed against your facts. This week, choose one customer workflow and review the point where it first reaches outside your organisation. Ask what permits that precise disclosure, what the customer understands and what happens if the information cannot be shared. A short, tested answer is worth more than an ambitious promise that the assistant will handle everything.

Reduce friction by making the permitted route predictable, not by treating every request as blanket agreement.