An MCP server for business is the entry point through which customers’ AI agents (ChatGPT, Claude, and others) access a company’s services: they search for products, check availability, and view order history. A public server without sign-in returns the same anonymous response to everyone. For an agent to work with a specific customer’s data, authorization is required: under the MCP specification, this is OAuth 2.1 — the agent receives its own token, the person chooses permissions themselves and can revoke access, and the server checks rights on every call. That’s what VkusVill did in October 2026.
Prepared by AIrassvet October 16, 2026 based on VkusVill’s article in the company’s blog on Habr, the CNews news item from October 15, 2026, and the authorization and security sections of the current Model Context Protocol specification (version 2026-07-28). It is intended for owners of digital products, e-commerce leaders, and IT directors deciding whether to open their services to customers’ AI agents and how to do it safely. We did not test VkusVill’s MCP server or measure its impact: the rollout scheme, tables, and checklist are the editorial team’s methodology. AIrassvet is not affiliated with VkusVill, CNews, or the MCP developers; the section at the end of the article describes the publisher’s services.
Contents
- At a Glance
- What Changed at VkusVill
- Why Businesses Need an MCP Server and When a Public One Is Enough
- How OAuth Access Works
- What the MCP Specification Requires
- How to Design Permissions
- Risks and How to Address Them
- Step-by-Step Launch Plan
- Frequently Asked Questions
- Primary Sources and Verification Method
At a Glance
- Customers are already showing up with agents. VkusVill launched a public MCP server in December 2025, and on October 15, 2026, it added authorization: now, with the buyer’s permission, the agent can see the catalog for their address, online order history, favorite product, and personalized discounts.
- A public server is not enough when the answer depends on the customer. VkusVill’s agent searched across the entire catalog, and some of the products it found turned out not to be available for delivery from the store or dark store that would fulfill the order.
- The authorization standard is already defined. The MCP specification builds access on OAuth 2.1: the server is a resource server, the agent is a client, and the token is issued for a specific server and specific permissions.
- The key decision is the permission set. Narrow read permissions, separate permissions for personal data, and separate permissions for actions such as placing an order reduce the damage if a token is compromised.
- It’s best to launch in stages: public catalog → reading personal data → actions with human confirmation.
What Changed at VkusVill
VkusVill released the first version of its public MCP server in December 2025 as an experiment for developers and AI agent users. The server could search products in the catalog, show ingredients and nutrition information, and assemble a link to a ready-made cart; later, recipe search, barcode search, and alternative-product matching were added (CNews, 10/15/2026).
The company describes the main problem directly: search in the public server covered the entire catalog, while on the website the customer sees only the assortment of the store that will deliver the order. Passing the store as a parameter did not work — for some addresses, delivery is possible from several dark stores, and the final one is determined by the algorithm. In addition, without sign-in the agent does not have access to personalization and the loyalty program (VkusVill’s blog on Habr).
The solution is access to the personal account via OAuth 2.0 with PKCE. The company formulated four information security requirements:
- the agent signs in under its own credentials, not the customer’s username and password;
- the agent does not get access to the customer’s personal data beyond what is allowed;
- the person chooses what they are willing to delegate to the agent;
- the person can revoke access.
After authorization, the agent gets access to four capabilities: catalog search for the user’s address with real-time availability, online order history, favorite product, and personalized discounts; the server checks permissions on every request. According to the company, from January to September 2026 the average daily number of orders related to the MCP server grew by more than five times (CNews) — these are VkusVill’s own figures, and the absolute values were not disclosed.
Why Businesses Need an MCP Server and When a Public One Is Enough
MCP (Model Context Protocol) is an open protocol that gives an AI agent access to external tools and data. For a company, an MCP server is an “agent-facing storefront”: the same catalog, booking, or personal account, but in the form of functions the agent can call.
An agent channel does not replace the website or app: it is an additional entry point for customers who already delegate tasks to an assistant. What to choose at the start depends on whether the answer changes from customer to customer.
| Scenario | Public server without sign-in | Server with authorization |
|---|---|---|
| Catalog, descriptions, and prices for everyone | Enough | Not needed |
| Availability and assortment by the customer’s address | Not accurate: the agent does not know the delivery point | Needed |
| Order history, loyalty, discounts | Not available | Needed, with separate permissions |
| Placing an order, booking, payment | Only a cart link for the person | Needed, plus human confirmation |
| Internal company data | Not allowed | Employees only, via corporate login |
A public server is enough if the agent only needs to find and compare directories, catalogs, or schedules. Authorization becomes necessary when the answer depends on a specific person or the agent needs to do something on their behalf. Starting with a public version is a sensible approach: VkusVill collected feedback for almost a year before adding sign-in.
We explained in more detail how to connect third-party MCP servers to your own agents in our breakdown of 2GIS MCP servers, and we covered how to prepare an online store for agents in our article on smart search for online stores.
How OAuth Access Works
OAuth is a delegated access standard: a person allows an app to act on their behalf within selected permissions without giving it their password. In MCP, the agent plays the role of the app.
Using VkusVill as an example, the process looks like this (company blog):
- Customer registration. The user registers an OAuth client and specifies the return address (redirect URI) of their agent platform — for Claude.ai it is
https://claude.ai/api/mcp/auth_callback, and for ChatGPT the address is taken from the plugin creation window. For now, it is only possible to create a personal agent linked to the owner’s loyalty card; the company says multi-person clients and an affiliate program will come later. - Transferring credentials to an agent. The client ID and secret are sent by email. The company also warns users not to paste them into chat with the agent or share them with untrusted services. That same email includes a link to revoke access; for now, deletion can take up to 24 hours.
- Human consent. On the first request, the agent generates a link, the person follows it, and chooses which actions and data the agent can access (scopes).
- Token. The temporary code is exchanged by the agent for a JWT access token with a 24-hour lifetime; after that, authorization must be completed again. Automatic token refresh, instant revocation, and an access management dashboard are on the company’s roadmap.
PKCE — an OAuth extension that prevents an interceptor from exchanging a stolen authorization code for a token: the client proves that it was the one that initiated the login.
A short token lifetime and required re-login are inconvenient, but they limit damage: a stolen token stops working after 24 hours.
What the MCP specification requires
The MCP specification (version 2026-07-28) describes authorization for HTTP-accessible servers. Key requirements (Authorization section):
| Requirement | What this means for the company |
|---|---|
| An MCP server is an OAuth 2.1 resource server | Token issuance is handled by an authorization server—yours or an existing corporate one—and the MCP server validates the tokens |
The client must specify the resource parameter (RFC 8707) |
The token is issued for a specific MCP server, not “for everything” |
| The server must verify that the token was issued specifically for it | A token issued for another service, even if valid, must be rejected |
| An invalid or expired token returns 401 | The agent understands that re-login is required |
| Insufficient permissions return 403 with the required scopes | The agent can request additional permission from the user |
| Client registration: Client ID Metadata Documents are recommended; dynamic registration is allowed but marked as deprecated | Decide in advance how agent platforms will register with your service |
| Minimum permissions when selecting scopes | The agent requests only what is needed for the task |
The separate security document (Security Best Practices) names the anti-pattern “token passthrough”: an MCP server accepts a token without checking who it was issued to and forwards it to internal APIs. The specification explicitly forbids the server from accepting tokens that were not issued for it. For intermediary servers that call third-party APIs, consent is required for each client, and the consent screen must show the client name, requested permissions, and return URL.
How to design permissions
The permission set is what a person will see on the consent screen and what will determine the damage if a token is leaked. In the MCP security document, broad permissions like files:* or db:* are cited as examples of poor design: they increase the impact of token compromise and make the audit log harder to interpret.
Practical scheme for a customer-facing service (editorial method):
| Group | Example permission | Risk if leaked | Human confirmation |
|---|---|---|---|
| Catalog by address | catalog:read |
Low | Not needed |
| Order history | orders:read |
Medium: personal data | Once at consent |
| Loyalty and discounts | loyalty:read |
Medium | Once at consent |
| Cart | cart:write |
Medium | Recommended before payment |
| Order and payment | orders:create |
High | For each order |
| Profile, address, and phone number changes | profile:write |
High | Do not grant to agents at launch |
Pre-launch checklist:
- Each MCP server tool is tied to one permission; read and write tools are separated.
- The agent receives only the data needed for the task: for example, order history without a phone number or address if they are not required.
- The token lifetime is defined and matches the risk level; access can be revoked, and revocation timelines are clearly communicated to the user.
- The server verifies the token audience and permissions on every call.
- Client credentials are issued over a secure channel, and the user is warned not to share them in chat.
- Every call is logged with the client and user ID.
- Money-related actions and irreversible operations require human confirmation outside the agent.
Risks and how to mitigate them
Authorization answers the question of "who can do what," but it does not make an agent safe on its own.
| Risk | How it shows up | What to do |
|---|---|---|
| Excessive Privileges (OWASP LLM06) | The agent was given more functions and permissions than the task requires | Least-privilege scopes, separate read and write tools, confirmation for risky actions |
| Token forwarding | The server passes the client's token to internal APIs | Check the audience; use your own service access when calling internal systems |
| "Confused deputy" | A proxy server with one static client lets an authorization code be obtained without the user's consent | Consent for each client, a secure consent screen |
| Credential leak | The user pasted a client secret into a chat with the agent | Warnings, short token lifetime, fast revocation |
| Prompt injection through data | Text from reviews, product descriptions, or notes reaches the agent as an instruction | Return data to the agent, not commands; do not give tools dangerous actions without confirmation |
OWASP describes the excessive privilege category in Top 10 for LLM Applications 2025 (LLM06 Excessive Agency). For more on autonomy boundaries, see the article "Managing AI Agent Autonomy", and for gateway-level protection, see the breakdown of the LLM firewall.
Step-by-step launch plan
Editorial methodology; timelines depend on the readiness of the company's API and authorization server.
- Inventory. List 3–5 tasks that customers are already trying to hand off to assistants: find a product, check order status, book an appointment. For each one, define the data and source systems.
- Public server. Open only public data: catalog, reference info, schedule. Collect call logs and feedback to see which tools are needed and where the agent lacks context.
- Read authorization. Connect the authorization server, assign permissions to read personal data, limit the token lifetime, and enable access revocation.
- Confirmed actions. Add cart, order, or booking only with human confirmation and an activity log.
- Metrics. Track the success rate of calls, 401/403 errors, access revocations, complaints, and orders coming through the agent channel. To see the impact, compare against the baseline before launch.
Frequently asked questions
What is an MCP server for business?
It is a service through which customers' AI agents call company functions over the open Model Context Protocol: searching products, checking availability, and viewing orders. It works like a storefront for agents alongside the website and app.
Why does an MCP server need authorization?
Without login, the server responds the same way to everyone and does not know the customer's address, history, or discounts. OAuth authorization lets the agent work with the data of a specific person within the rights they chose and makes it possible to revoke access.
What authorization standard does the MCP specification require?
OAuth 2.1. The MCP server acts as a resource server, and the agent is the client. The token is issued for a specific server (the resource parameter in RFC 8707), and the server must verify that the token was issued specifically for it.
Does the agent receive the customer's password?
No. The agent signs in with the customer's OAuth credentials, and the person confirms on a separate page which data and actions are available. The password for the personal account is not passed to the agent.
Can the agent be allowed to place orders?
Technically yes, but this is a high-risk action. It makes sense to start with read permissions and give ordering and payment separate permission, confirming each operation with a human.
Where should a company start?
Start with a public server using public data and a call log. Once it becomes clear which data agents are missing, add read authorization, then confirmed actions.
Primary sources and verification method
Method: on October 16, 2026, we read VkusVill's article on Habr and the CNews news item, extracted the requirements, authorization steps, and list of new capabilities, cross-checked the OAuth requirements against the current MCP specification 2026-07-28 and the security document, and matched the risk categories against OWASP. AIrassvet did not conduct its own testing of VkusVill's MCP server; the permission tables, risks, checklist, and launch plan are the editorial methodology.
- Habr, VkusVill blog, 10/15/2026: "VkusVill built an MCP server with authorization" — requirements, OAuth 2.0 + PKCE steps, token lifetime, plans.
- CNews, 10/15/2026: "VkusVill updated its MCP server" — server history, four new capabilities, order growth according to the company, product manager comment.
- Model Context Protocol: Authorization, version 2026-07-28 and Security Best Practices.
- OWASP: LLM06:2025 Excessive Agency.
Limitations: order growth of five times is VkusVill's claim without absolute figures or methodology; server functions may change, and the current description is published on the server page. The MCP specification is updated regularly — verify requirements against the current version.
How AIrassvet helps open up company services to customers' AI agents
An MCP server is an integration with your systems: catalog, CRM, order management, loyalty program. On the AIrassvet website the directions directly related to this task are described:
- process audit and data preparation: which tasks customers delegate to agents, what data they need, and which of it is personal data;
- development of AI agents and integrations with communication channels and business systems — including tools through which external agents access services;
- automation of actions in ERP, 1C, and browser interfaces where the system does not have a ready-made API;
- integration, testing, and support after launch: call scenarios, permission checks, and logging.
The first step is to choose one customer task, describe the current customer journey, data source systems, security constraints, and the criterion by which the launch of the agent channel will be considered successful.
Bottom line: the agent channel starts with access rights
The VkusVill example shows how the agent channel is evolving: first a public catalog, then OAuth sign-in, where the person selects permissions, the token lives for 24 hours, and the server checks rights on every call. The MCP specification already defines this framework: OAuth 2.1, a token tied to a specific server, and a ban on forwarding someone else’s tokens.
A company that wants to accept customers with AI agents does not need to open ordering and payments right away. It is enough to start with public data, then add narrow read permissions, and grant actions only with human confirmation.