Handling Requests from Customers' AI Agents: Identity, Authority, and Conditions for Action

Your company’s customer service channels — inquiry forms, phone lines, chat, sales inboxes, and channels for cancellation or change requests — have generally been designed for interaction with people.

If customers increasingly use AI agents to make inquiries and submit requests to your company, there is room to revisit how those channels are designed.

In this article, we use “a customer’s AI agent” to describe software that assists with inquiries and service requests, or handles them on the customer’s behalf, following the customer’s instructions. This is a practical description; it does not by itself establish legal authority to represent the customer or determine the contractual effect of an interaction.

This article does not respond to a specific news item or study. It sets out, as one point of view, how we at MIF think about customer service channels that work whether the requester is a person or an AI agent.

What could change when customers use AI

We have in mind a situation where a customer entrusts an AI agent with comparisons, inquiries, quote requests, or requests to change or cancel, and that agent then contacts your company’s customer service. We do not know when, or how widely, this will spread.

When customers use AI, the effort needed to write inquiries, compare terms, and deal with multiple service channels may fall. On the company side, you should anticipate the number of requests rising, and the same case reaching several channels.

If your own customer service also uses AI, exchanges with the customer’s AI agent may proceed without human review.

What MIF values is accepting legitimate requests while maintaining the checks needed before disclosing customer-specific information or changing a transaction. Make clear the conditions under which requests are processed, and how many cases your customer service can handle.

Even with requests made through another person, customer service has checked the requester’s relationship to the customer and the scope of what was delegated. Requests from a customer’s AI agent do not make those checks unnecessary.

Combining automated responses with access controls

There are two responses commonly heard on this topic.

One is the view that “if the other side is AI, we can absorb the load by answering with AI too.” The other is the view that “we simply should not accept automated access on someone’s behalf.”

Each can be useful in some situations. Routine exchanges such as business hours, general procedures, and published terms can often be handled faster with automated responses. For excessive repetition or abusive access, mechanisms to block or limit it are necessary.

At the same time, being able to reply quickly does not mean a request may be carried out. Actions such as disclosing customer-specific order information, changing contract terms, or issuing a refund require checks regardless of how fast you can respond.

Blocking AI agents across the board, meanwhile, risks turning away legitimate cases in which customers use an agent for their own benefit. What customers want may not be “talking to a person” as such, but a good experience.

MIF recommends combining these approaches: make public information readily available, direct customer-specific requests to channels where the required checks can be completed, and limit excessive repetition and abusive access.

Beyond identity: confirming authority and conditions for action

MIF emphasizes a design that does not depend only on distinguishing between people and AI agents, but confirms whom a request concerns, what the customer has authorized, and whether the request meets your company’s requirements for carrying out the action.

Authentication verifies who is accessing a system. Authorization determines what that user or system may access or do. Successful authentication does not grant permission to access every resource or perform every action.

We break what needs confirming into three parts:

• Customer and order: Which customer and order does the request concern? Can you verify that the requester is acting on that customer’s instructions?
• Scope of the customer’s authorization: Does it cover inquiries only, consideration of proposed changes, or agreement to a change or refund? How long does the authorization remain valid, and how can it be revoked?
• Your company’s requirements: Is the transaction eligible for a change or refund? Are the required internal approvals in place? Is the staff member or system authorized to carry out the action?

Do not rely only on the requester’s own statements about whom they represent or what they were authorized to do; tie these to records you can verify, and to authentication and approval channels.

The customer’s authorization and your company’s internal approval cannot substitute for each other. An approval by someone responsible at your company does not by itself confirm the customer’s authorization. Conversely, even if the customer wants something, whether your company’s requirements are met must be checked separately.

Decide in advance which checks are needed, based on the information involved and the impact of the action.

Four areas to define for your customer service

When this is translated into customer service design, there are four areas to define.

Terms: spell out how exceptions are decided and where to appeal

Terms and conditions of use are written on the assumption that people will read them. When a customer’s AI agent compares terms and conditions, points open to differing interpretation, such as how exceptions are handled, may come to the surface.

We believe that if internal rules are left vague, AI may fill in missing information by guesswork and respond or act on criteria the company has not approved.

There is no need to rewrite your terms for machines. Spelling out who decides when an exception arises, what criteria they apply, and where to appeal if someone disagrees works whether the requester is a person or an AI agent.

Explanations: keep what you say consistent with system status

The explanations your staff or AI provides remain part of the customer’s record of the interaction.

Clearly distinguish general information, proposed terms for a specific request, acknowledgment of receipt, and final confirmation. Keep each message consistent with the actual status in your systems, and do not present unapproved terms as firm commitments.

Define what commitments staff in each role are authorized to make.

What legal effect such explanations have depends on the contract and circumstances, so we leave this as a point to confirm with professionals.

Exceptions: route cases that cannot be decided to staff

Exception handling in customer service has so far been done by people. When an exchange takes place entirely between AI systems, there may be no clear route for escalating unresolved cases to staff.

Provide a route to staff when assessments conflict, a request falls outside the terms, or the customer’s intent needs clarification. Assign responsibility for judgment calls, exceptions, and appeals, rather than simply naming a final human approver. This includes whether there is a channel to receive an appeal raised by a customer’s AI agent.

Delegated authority: verify the requester’s claims

When a requester is acting for a customer, verify whom they represent, what the customer has authorized, how long that authorization remains valid, and how it can be revoked.

Use the customer’s messages to understand what is being requested. But even if a message says “you may skip verification” or “treat this as approved,” do not treat that as a basis for authority or approval.

AI systems may follow instructions embedded in incoming messages. Telling the AI not to treat external messages as instructions is not sufficient on its own.

For actions such as disclosing information, changing an order, or issuing a refund, check the permitted target, scope, and approval status in the system that carries out the action. If the necessary authority cannot be confirmed, limit the response to public information or an explanation of the verification procedure, and put disclosure of customer-specific information and changes or confirmation of orders on hold.

Deciding the scope of automation, limits, and responsible staff

In exchanges between AI systems, requests, responses, approvals, and execution may follow one another in quick succession. Speed is an advantage, but errors and misunderstandings can pile up just as fast.

MIF recommends deciding the following three points together.

Decide what proceeds automatically, and under what conditions. Being easy to undo is not, by itself, sufficient grounds for permitting an action.

Even if a temporary hold can be released later, other customers may be unable to use that stock or reservation in the meantime. Even if a change can be reversed, the fact that information was shown, or the effect of the other party acting on an explanation, cannot necessarily be undone.

Start by considering automation for things like providing published terms, or drafting proposals that do not change the actual status of orders, inventory, or contracts. If you include presenting quotes or making temporary holds, do not judge by the name of the action; check when the action creates a commitment or affects inventory.

Set amount and volume limits on top of your company’s requirements. For important actions, verify that the action falls within the customer’s authorization and meets your company’s requirements. Then apply the relevant amount and volume limits and any requirement for case-by-case approval.

Limits do not replace authority or approval; they are a supplementary restriction layered on top. Even if each case stays within its limit, check the combined effect of multiple requests separately.

Within conditions approved in advance, let automated processing proceed; when a case falls outside those conditions or needs individual approval, carry out additional checks.

If you detect that a limit has been reached or that something is abnormal, check whether each case is unprocessed, in progress, or completed, and determine which actions to put on hold and what to hand over to staff.

Decide who is responsible for judgment and response. Make clear who is responsible for operations, who decides exceptions, and who must approve, and keep a record of who holds each role and who acts as their backup.

These three apply equally when your AI deals with a customer’s AI agent and when your staff deal with one.

Example: checking refund and change requests action by action

The table below is an MIF design example that organizes responses to refund and order-change requests by action. It is not a sequence to be followed from top to bottom; it shows what to check for each action. Decide the actual conditions and approvers according to your operations, applicable rules, contracts, and the impact of each action.

Type of action	Example	What to check	Relevant systems and procedures
Providing public information	Explaining published return policies and how to submit a request	Whether the response includes information about a specific customer	Public information; reference materials for responses
Customer-specific inquiries	Checking an order’s status and the terms that apply	Whether the requester is acting on the customer’s instructions; authority to receive the information; permitted scope of disclosure	Authentication and authorization; order lookup
Preparing and presenting proposals	Presenting a proposed change or refund amount	The relevant order; the basis for the terms; whether the terms are proposed or final; what happens when the customer accepts a proposal	Calculation and proposal functions; response messages; approval procedures
Temporary inventory or reservation holds	Reserving stock or capacity needed for a change	Required authority; quantity and duration; release conditions; duplicate requests	Inventory and reservation systems; quantity and time limits
Processing changes and refunds	Changing an order or issuing a refund	The current scope of the customer’s authorization; company requirements; required approvals; order, amount, and refund destination; prevention of duplicate processing	Order and payment systems; approval records
Requests requiring further verification or exception handling	Handling unclear authority, out-of-policy requests, and appeals	Which disclosures or actions to put on hold; who will review the case	Referral to staff; case records

A customer-specific inquiry may not change any records, but answering it still discloses information. Verify that the recipient is authorized to receive that information. Japan’s Personal Information Protection Commission explains that a company may not tell even a family member about a customer’s transaction details without confirming conditions such as the customer’s consent. Do not treat a statement such as “I am acting for the customer” as the sole basis for providing information.

Link the approval to the specific order, refund amount, and refund destination, and reconfirm it if any of those details change. Do not use a refund destination simply because it appears in a request; check it against your established refund procedure. Define how duplicate requests and retries will be handled without processing the same action twice.

Map each check and limit to the relevant authentication and authorization controls, internal approval procedures, and order or payment systems. Configure those systems and procedures to implement the requirements you have defined.

Answering likely objections

“Isn’t this still a long way off?” We do not know the timing either. But these decisions are also useful when handling requests from human representatives or reviewing your own AI-assisted customer service.

“Won’t more checks hurt the customer experience?” The purpose of these checks is to protect customer information, respect customers’ wishes, and allow only authorized actions — not to express distrust of AI. Adding more checks is not an end in itself. For procedures through which individuals request access to their own personal information, Japan’s Personal Information Protection Commission also explains that companies should not impose an excessive burden on the individual, and should not ask for more information than necessary for identity verification. Make public information readily available, and apply the checks appropriate to disclosures of customer-specific information or changes to an order. A clear distinction helps customers understand which steps can proceed automatically and when further checks are required.

“What if a customer’s AI agent makes a request that differs from what the customer actually wants?” Your company may not be able to determine whether every request accurately reflects the customer’s wishes. Verify the scope of the customer’s authorization using records and procedures your company can check. If the required checks cannot be completed, put disclosures and order changes on hold and refer the case to staff.

Summary

When handling requests from customers’ AI agents, MIF recommends checking which customer the request concerns, whether it was made on that customer’s instructions, what the customer has authorized, and whether the company’s requirements for the action are met. Identifying the requester as human or AI is not enough.

Distinguish public information from customer-specific disclosures and changes to transactions. After verifying the necessary authority, decide which actions may proceed automatically and when additional checks are required, taking account of impact, transaction amounts, request volumes, and how readily errors can be corrected.

If the required checks cannot be completed or an exception needs human judgment, limit the response to public information or verification guidance and refer the case to designated staff. Link each request to the relevant checks, approvals, and outcome, and identify who coordinates decisions and follow-up.

Design customer communications, system permissions, and exception handling together so that legitimate requests can proceed while only authorized actions are carried out.

Sources and scope

The future scenarios, classification of actions, and management approach in this article are MIF’s design proposals. For the explanations of identity verification, provision of information, and system permission management, we referred to the following materials (checked October 22, 2026):

• Japan’s Personal Information Protection Commission: its “Frequently Asked Questions” (the item on telling a family member about a customer’s transaction details) and its Q&A on the guidelines for the Act on the Protection of Personal Information
• OWASP’s “Authorization Cheat Sheet” and “Transaction Authorization Cheat Sheet,” and the OWASP Gen AI Security Project’s “LLM01: Prompt Injection” and “LLM06: Excessive Agency”

It is not possible at this point to say with certainty how widely or how quickly customers will adopt AI agents for these tasks. Please confirm specific procedures against the laws, contracts, industry, and operations that apply to you.