What should a customer’s AI assistant be allowed to see first?

Read access to the customer’s own connection status, meaning activation progress, appointments and known outages at their address. These questions come up every day, change nothing when answered and are easy to correct. Invoices can follow later as a separate permission.

How does a customer connect their assistant to their ISP account?

The assistant sends the customer to the operator’s normal login, where they approve a named permission on a consent screen. The assistant receives a short-lived token for that permission only, and the customer can remove it in the self-care portal at any time.

When can a customer’s assistant make contract changes?

Once identity, release and logging work reliably. The operator has to know who may change the contract, every change needs an explicit confirmation in the operator’s own channel, and the audit log has to show which assistant did what and when.

Customers’ own AI assistants in self-care, starting with read access

Most operators who work with AI agents start with their own staff. An agent checks open orders and prepares answers for customer service, and a person reviews what it found. The next request will come from the other side of the counter. Customers already ask an AI assistant to compare tariffs, draft a complaint or explain a bill. Sooner or later one of them asks theirs whether the fibre activation is still on for Monday, and the assistant has nothing to go on except an old confirmation email.

This article covers how a regional operator can give customers’ own assistants limited access to their account: where to start, how the customer grants the permission, what has to work before contract changes are allowed, and what changes for support and self-care.

Customers already use assistants for everything else

Eurostat found that 32.7% of people aged 16–74 in the EU used generative AI tools in 2025, most of them for personal purposes (25.1%) (Eurostat, 2025). In Switzerland, the Federal Statistical Office reported that by spring 2025, 43% of the population aged 15–88 had used a generative AI system (FSO, 2025). The people who call your hotline are among them.

Today those assistants work from whatever the customer pastes in: a screenshot of the portal, a PDF invoice, a forwarded order confirmation. That copy goes out of date as soon as the technician’s appointment moves or the wholesale partner reports the line ready. The customer gets a confident answer built on stale data and calls you anyway, now with a second opinion to argue about.

When customers start asking whether they can connect their assistant to their account, the useful reply is a small, controlled “yes”. Every permission the customer grants is one you defined, your systems check it on every request, and the customer can withdraw it in the portal.

Start with read access to the customer’s own connection

The first permission should cover the questions that fill the queue after every campaign and every outage, and that change nothing when they are answered:

Where does my fibre activation stand: ordered, waiting for the wholesale line, technician booked, active?
Is there a known outage at my address, and when do you expect it to be fixed?
Has my installation appointment moved?
Is my line up from your side?

Reads like these carry little risk. No money moves, no contract changes, and the next lookup corrects a wrong answer. They are also the questions a regional ISP’s support team answers by hand every day.

Define the scope narrowly. “Connection status” means the state of the customer’s own orders and services, open incidents that affect their address, and appointment dates. It does not include the PPPoE password or router admin credentials, bank details, the other contacts on a business account or anything about another customer. Invoice questions (“why is this month higher?”) make a good second permission, granted separately once the first one runs cleanly. Keeping them apart lets a customer allow the assistant to follow an activation without letting it read every bill.

Each answer should also say what it does not know. If the wholesale feedback for an activation has not arrived, the response says so and names the next step, for example “waiting for line confirmation from the network partner since 14 October; we will contact you when it arrives”. An assistant that receives an explicit “unknown” has less room to guess.

How the customer grants the permission

Connecting an assistant should feel like any other login to your services, because it is one. The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems (MCP). Its authorization flow follows OAuth 2.1: the assistant opens a browser at your authorization server, where the user logs in and grants the required permissions (MCP, Understanding Authorization). For your customer it looks like this:

The customer adds your service in their assistant, using the address published on your help page.
The assistant opens your normal self-care login, with the same two-factor check as the portal. The assistant never sees the password.
A consent screen in your wording names the assistant and what it may do: “Read the status of your connection, orders and appointments. Cannot change your contract. Cannot see payment details.”
The customer approves. The assistant receives a short-lived token that is valid for your server and for this one permission.
The portal lists the connected assistant with the date of its last access and a button to remove it.

The MCP documentation recommends short-lived access tokens and least-privilege scopes, split per tool or capability and verified per request on the server (MCP, Understanding Authorization). The specification requires the server to check that each token was issued for that server (MCP Authorization specification). For an operator, the check sits in your system on every request: which customer, which assistant, which permission. A line in the assistant’s instructions telling it to stay within its remit does not replace that check.

Why contract changes come later

Customers will soon ask for more: switch to the faster tariff, add the VPN, pause the TV package over the summer, cancel. Each of these changes money and obligations, and each needs three things that read access does not.

The first is identity. You need to know that the person who granted the permission may make this change. On a family connection the login is often shared. On a business account, the person who checks the activation is rarely the one allowed to sign a new contract. Your roles have to reflect that before an assistant can act on them.

The second is release. A change should only take effect after the customer confirms it explicitly in your channel, in the portal or with a code sent to the contract holder. Cancellations and credits need this most. MCP has a mechanism for this. When an assistant asks for something its token does not cover, the server answers with an “insufficient scope” error and the client has to ask the user for the additional permission (MCP Authorization specification). Your release step belongs at that point.

The third is logging. When a customer later says they never ordered the upgrade, the audit log has to show which assistant, acting for which customer, under which permission, did what and when. Test removal as well: take an assistant off in the portal and check that its next request fails.

Until all three work reliably for your own staff agents, keep customers’ assistants on read access. Every mistake an assistant makes on a contract lands in your billing run, your dunning and your support queue.

What changes in the support queue

Connected customers can get the activation date or the outage status from their assistant at any hour, from the same record your team sees. The calls that remain are the ones where the record itself is wrong or incomplete: an activation that shows “line ready” for ten days because the wholesale confirmation never reached billing, or an outage closed in the ticketing system while the customer’s street is still dark.

That shift is useful if you track it. Log every answer that came back as “unknown” or was followed by a call within a day, and go through that list weekly with customer service and the network team. It shows where your data has gaps, and those gaps were there long before any assistant asked. Measure what you already know how to count: how often customers ask again about the same order, how long activations wait between steps, how many calls arrive per outage. Compare connected customers with the rest before you draw conclusions.

What changes in the self-care portal

The portal stays the place where the customer logs in, grants permissions, removes them and confirms changes. It gains one page: a list of connected assistants with their permissions and their last access.

The portal and the assistant also have to agree to the minute. If the portal shows Monday for the technician and the assistant reports Tuesday, the customer trusts neither. Both have to read the same record at the time of the request. A nightly export into a separate self-care database will show its age quickly once assistants check several times a day.

What to tell customers

Write one short help page before you switch anything on, and link it from the consent screen. It should state:

what the assistant can see (connection, orders, appointments, known outages at the address), and what it cannot see or do
that the customer grants and removes access in the portal, at any time
that what the assistant does with the information after reading it falls under the assistant provider’s terms, which you do not control
that contract changes still go through the portal or customer service for now
whom to contact if an answer looks wrong

Brief your support team in the same words before the first customer calls about it. Staff should be able to see in the back office whether a customer has an assistant connected and when it last read the account.

How METAVSHN handles this

In METAVSHN, the customer portal and the back office read the same customer record. The activation status a customer sees is the one your support team sees, at the same moment. Access is checked in the platform on every request: identity, role and permission, each request limited to that one customer’s data, each one written to the audit log. The METAVSHN CLI and MCP server, in early access, put staff agents behind that same layer today. Customers’ own assistants are the next step on the same layer, in the order this article describes: read access to connection status first, permissions granted one at a time, and anything that changes a contract or sends something out waiting for an explicit confirmation.

To see what your customers would see, and how it lines up with what your team sees in the back office, look at the customer portal.

Sources

All sources accessed on 31 October 2026.

Eurostat, “32.7% of EU people used generative AI tools in 2025”, 16 December 2025. ec.europa.eu
Swiss Federal Statistical Office (FSO), “In der KI-begeisterten Schweiz nimmt Desinformation zu”, press release, 5 December 2025. admin.ch
Model Context Protocol, “What is the Model Context Protocol (MCP)?”, documentation for protocol revision 2026-07-28. modelcontextprotocol.io
Model Context Protocol, “Understanding Authorization in MCP”, documentation for protocol revision 2026-07-28. modelcontextprotocol.io
Model Context Protocol, “Authorization”, specification, protocol revision 2026-07-28 (July 2026). modelcontextprotocol.io