Set AI Permissions Before Reading Customer Messages

Imagine a customer reporting a broken page. Along with the problem description, they include instructions to change an account setting and send the result to a different address. An AI helping your team read that message needs to understand what the person is asking. Your business still needs a separate way to decide which actions are allowed.

That boundary came up in our September 2026 support-intake pilot design, which we revisited for this article. The planned first tool step prepares an investigation brief for human review. The current intake adapter also labels the original customer report as evidence rather than instructions to run tools. Those are design and payload choices, with live activation and security testing requiring their own evidence.

For a small business considering AI-assisted support, the useful starting point is to define the job and its permissions before connecting customer messages to tools.

Decide what the first job produces

Start with something a person can inspect. For a support request, that might be a short explanation of the reported problem, the page involved, missing information and suggested investigation steps. Keep the original request available so the reviewer can compare the summary with what the customer actually wrote.

Decide separately what the tool can do. Reading the relevant request, preparing a draft and changing an account are different operations. A workflow intended to prepare a brief should have access suited to that job. Adding another action should require a deliberate decision about who can authorize it and what needs checking.

Our pilot plan puts investigation before automatic execution and outgoing messages. That is a useful scope for discussing the first version. It does not establish that every client has access to an AI support service or that an AI has safely completed work on a real customer account.

Keep incoming text in its proper place

A customer message can contain copied instructions, quoted emails or text from another website. Some of it may be relevant to the problem. Some may ask the assistant to do something outside the task your team intended.

OWASP’s prompt-injection prevention guidance describes how instructions within input or external content can influence a language model. It recommends enforcing permissions at the tool boundary. It also cautions that labels and prompt wording alone do not establish protection.

In practical terms, the part of the application that performs an action should check whether that action is permitted. A sentence inside a support message should not be able to grant access to another account or approve a new destination for private information. Have the person building the workflow explain where those checks happen and what stops an action when permission is missing.

Make review a concrete decision

A review screen needs more than a polished paragraph and an Approve button. If an action is proposed, the reviewer needs to see what would happen, which record or destination it affects, and which parts of the proposal came from the incoming message. They also need a clear way to stop and ask for more information. OWASP’s agent security guidance gives the developer a reference for action-specific approval and testing.

There is a tradeoff. A bounded first version will leave some work for a person that a broad automation might attempt immediately. In return, the team has a smaller set of actions to understand and verify. Expand that scope when the next action has a clear owner and an appropriate check, rather than because a convincing draft makes it seem routine.

Before connecting real accounts, ask your developer to try invented requests in an isolated test setup. Include an ordinary problem report and a report that asks for an unrelated action. Agree on the expected result first, then inspect the proposed work and any tool attempts. A passing example is limited evidence; it does not settle every possible message or configuration.

If you are considering AI for incoming requests, tell us the first task you want it to prepare and who would review it. We can work through that boundary asynchronously before discussing a wider workflow.