How to set access rules for AI agents in a telecom back office

An agent prepares credit notes for customers affected by an outage in one valley. Its prompt says: never credit more than one month’s fee, and only for customers on the affected access node. On most days that works. Then a customer forwards a long email thread to support, and somewhere in it is a sentence the model treats as an instruction. Or the list of affected customers comes from a ticket that someone edited by hand. In both cases the prompt was the only limit on what the agent sent to billing.

Access rules for agents have to be enforced by the systems that hold the data and execute the actions. This article sets out six rules for doing that in a telecom back office, with an example from daily operations for each, and explains where the MCP authorization specification helps.

Why an instruction to the model is not a control

A language model follows instructions with high probability, and the text it reads while working is part of its input. A customer email, a ticket comment or a note in a CRM record can all change what it does next. That makes a prompt a good place to describe a task and a weak place to enforce a limit.

A control is something that still holds when the model gets it wrong. The billing system refuses a credit note above the limit. The order system rejects a cancellation from an identity that has no right to cancel. The log records the attempt either way.

The MCP specification puts this duty on the server side: servers that expose tools must validate inputs, implement access controls and rate limit calls (MCP specification, Tools). Microsoft’s 2026 Work Trend Index makes a similar point for organisations as a whole and asks IT to manage agents with “identities, permissions, policy enforcement, and lifecycle management” (Microsoft, 2026).

Check identity, role and permission on every access

Every request from an agent carries its own identity, separate from the person who started it, and the system checks role and permission on each request. The check runs on each request because an agent may run for hours, and its rights may change in that time.

Each agent also has a named person who is responsible for it, checks its results and corrects its errors.

Example: a port-out. A request arrives to move a customer’s number to another operator. An agent may read the customer, the active services and the open invoices to check that the request matches the contract. When it asks for the final invoice to be created, the billing system checks the agent’s identity and role again for that specific action, and refuses if the role covers reading only.

Separate customer data

Agents see the customers they work for, and nothing else. For an operator that sells through resellers or runs several brands, this separation has to exist in the data model and in every query, so that a filter in the agent’s instructions is never the only barrier.

Example: a reseller’s agent. A reseller sells your fibre under its own brand and wants its own agent to check the status of its customers’ orders. The agent’s identity belongs to that reseller, and every query returns only that reseller’s customers. If the agent asks for an order number that belongs to another reseller, the answer is the same as for a number that does not exist.

Give each agent only the rights it needs

Rights follow the task. An agent that prepares a relocation list reads orders and technical feedback. An agent that drafts dunning letters reads invoices and payments. Neither can change a tariff.

The MCP authorization specification asks clients to request only the scopes they need, and lets the server answer a request with too few rights with 403 Forbidden and an insufficient_scope error naming the scopes required (MCP specification, Authorization). The MCP security guidance lists wildcard scopes, and relying on the scopes in a token without authorization logic on the server, among the common mistakes (MCP Security Best Practices).

Example: a bulk tariff migration. You retire an old DSL tariff and move its customers to a fibre or successor tariff. The migration agent may read the contracts in that tariff and create change orders for exactly that segment. It cannot cancel contracts, issue credits or touch customers on other tariffs, even if a customer’s case looks like it needs one of those.

Release cancellations and credits explicitly

Some actions end a service or move money. For those, the agent prepares the case and the system holds it until a named person releases it. The release is a separate step with its own permission, recorded with the name of the person who gave it.

Example: a credit note. After the outage, the agent drafts credit notes for the affected customers and attaches the evidence: access node, outage window, monthly fee. The notes sit in billing with the status “awaiting release”. Someone in billing reviews the batch, releases it or sends individual notes back. The agent’s role has no permission to release, so no wording in a prompt can make it do so.

The same applies to cancellations and port-outs. The agent can check the data, prepare the final invoice and list what is unclear. The step that ends the service is taken by a person.

Keep an audit log of which agent did what and when

The log answers the questions you will be asked months later. For each action it records the agent, the person responsible for it, on whose behalf it acted, the operation, the records it touched, the values before and after, the time, and who released it if a release was needed. Refused requests belong in the log too, because they show you where an agent keeps trying something it should not.

Example: a disputed tariff change. Three months after the migration, a customer says they never agreed to the new tariff. The log shows the date on which the migration agent created the change order, the batch it belonged to, the person in product management who released that batch, and the notification sent to the customer. Without that, you are reconstructing it from email.

Test revocation and stopping running jobs

Revoking an agent’s rights only counts if the next request fails. Test it before you rely on it, and test it while a job is running.

Example: stopping a migration halfway. The tariff migration is running over a few thousand contracts when someone notices the new price is wrong. Three things need to happen at once: the agent’s rights are revoked, its queued change orders stop, and you know exactly which contracts were already changed. Rehearse this in a test environment: start a batch, revoke the agent partway, and check that the next call is refused, that nothing else is processed, and that the log tells you where it stopped.

Short-lived tokens help here. The MCP authorization guidance recommends them, because a stolen long-lived token keeps working for longer (Understanding Authorization in MCP).

Where MCP authorization helps, and where it ends

If your agents reach business systems through a remote MCP server, the authorization specification covers the connection. It follows OAuth 2.1. The MCP server acts as a resource server, must validate that an access token was issued for it, and must not accept or pass on tokens meant for other services. Authorization is optional in the protocol, and implementations over HTTP should follow the specification (MCP specification, Authorization).

That tells the server which client is calling, for which user, with which scopes. The decision whether this agent may prepare a credit note for this customer, and whether a person has released it, still belongs to the business system behind the server. When you evaluate a vendor, ask to see both layers and the log entry each one writes.

How METAVSHN handles access for people and agents

METAVSHN has one access layer for people and agents: identity, roles, rights, releases and the audit log. It sits in front of billing, CRM, orders, the product catalogue and the warehouse, so the same rule applies whether a member of staff opens a customer record or an agent asks for it through the METAVSHN CLI or MCP server. Customer data is separated per tenant, cancellations and credits go through releases, and the permission hints in the CLI grant nothing by themselves. The platform is hosted in our own datacenters in Zurich.

We run an ISP ourselves (Ticinocom runs on METAVSHN), so these rules come from the cases we handle every week: port-outs, outage credits and tariff migrations.

If you want to see how a release and its audit entry look for a credit note prepared by an agent, book a 30-minute security walkthrough with us: contact METAVSHN.

Sources

All sources accessed on 31 October 2026.

1. Model Context Protocol, “Tools”, specification version 2026-07-28, July 2026. modelcontextprotocol.io
2. Model Context Protocol, “Authorization”, specification version 2026-07-28, July 2026. modelcontextprotocol.io
3. Model Context Protocol, “Understanding Authorization in MCP”, July 2026. modelcontextprotocol.io
4. Model Context Protocol, “Security Best Practices”, protocol version 2026-07-28, July 2026. modelcontextprotocol.io
5. Microsoft WorkLab, “2026 Work Trend Index Annual Report: Agents, human agency, and the opportunity for every organization”, 5 May 2026. microsoft.com