Retail Teams Already Ask ChatGPT About Orders. The OMS Sign-In Should Stay in the Estate

Introduction

Retail employees already ask ChatGPT and Claude where an order is, what can be promised, and which shipments are late. The answers sit in IBM Sterling Order Management. The sign-in for that system is a long-lived company credential, and it has to stay inside the estate.

Among retailers observed by Netskope Threat Labs from July 2025 through July 2026, use of personal AI applications fell from 70% to 44%, while organization-managed AI rose from 40% to 73%. The move toward managed tools then stalled. The share of people switching between a personal account and an enterprise account rose from 11% to 18%. Claude Platform is used by 96% of those organizations and ChatGPT by 84%. AI is no longer a pilot sitting beside the working day. It is where people go to ask an operational question.

The risk is the path from that question to OMS. Three paths are in use, and each one fails a different control.

The question is already being asked

Order status is a standing cost, not a new one. In ecommerce helpdesks, “where is my order” is regularly the single largest ticket type. A DigitalGenius cohort in March 2023 put that share at about 21% in a normal month and about 36% across the December–January peak. Those figures are helpdesk benchmarks, not a Sterling estate, and they describe customers contacting a brand. Inside the company the same question is asked by store operations, wholesale account teams, customer-service leads, and planners who do not live in Order Hub.

They ask it in the assistant already open on their desk. A separate OMS console, built so each team can have an assistant of its own, is a second place to log in. People keep the first one.

What they need from OMS is specific and current: order state, what can still be promised, which shipments are late, and what inventory a node can actually commit. A model that has not seen the order will answer from pattern, or from whatever someone pasted into the prompt an hour ago. Pasted order and customer data is already stale, and it is regulated data sitting in a chat transcript.

Where the data is going

Netskope’s same retail set shows what leaves through AI tools. Regulated data accounts for 56% of AI-related data-policy violations, source code 20%, and passwords and API keys 16%. Upstream violations, data sent into an AI tool, are 85% of the AI-related violations they classify. The exposure is not only a careless paragraph. It is credentials and customer records moving into a product the company does not operate.

A second change matters more for an OMS estate. Over that year, the number of agents interacting with remote MCP servers grew by about 400%, and MCP-related events by about 300%. MCP is the open protocol that lets an assistant call tools and data sources outside itself. Netskope’s count is specifically remote servers, hosted on the internet, not a server inside the retailer’s network. Each of those connections is another route between an AI product and a business system.

Retailers are therefore past the question of whether assistants will be connected to operational systems. The open question is who approves the connection, what it is allowed to do, and how it is removed.

Three ways this goes wrong

The assistant is given the OMS password. ChatGPT, Claude, and similar products expect a connection of their own. The OMS sign-in is not that kind of secret. It is long-lived, it is shared across a programme, and once it sits inside a third-party product the company cannot see who used it or withdraw it without changing the password for everyone else. Netskope’s 16% share of violations that are passwords and API keys is the same failure, measured as data leaving rather than as an architecture decision.

Every team gets its own chat. Customer service, stores, and planning each receive a bot wired to a slice of OMS. The integration is repeated, the sign-in problem is repeated, and the person with the question still has to leave the assistant they were already using. The company has funded a new console to solve a habit it did not change.

Nothing is connected, and people copy. The assistant is available and OMS is not. Someone pastes an order, a customer name, a ship-to, or a spreadsheet extract into the prompt. The answer may be plausible. It is not the system of record, and the paste is the regulated-data path in the Netskope figures. Banning the assistant does not close this. The same report says a slow approval process is why people fall back to personal accounts, and the overlap between personal and enterprise use has stopped shrinking.

What a controlled connection looks like

The connection the company can stand behind has a small set of properties.

• People keep asking in ChatGPT or Claude. They do not learn a new console to ask OMS a question.
• The company approves each AI product once. That product receives its own access. Later use of an approved product does not ask for the approval again.
• The OMS sign-in never leaves the connection service the company runs. The assistant never holds the OMS password.
• Removing one product removes that product’s access. The OMS password stays as it was.
• What the assistant can see or change is what that OMS account is allowed to do. A narrow account is a narrow assistant.
• Administration stays with the operator: which products are connected, and which have been removed.

A slow, one-off review for every new assistant is how personal accounts stay in the mix. Netskope’s own recommendation to retail security teams is to treat approval speed as a control.

A shared password cannot be withdrawn from a single assistant without rotating it for every integration that uses it. Orders, inventory, fulfillment, and customer questions stay inside the grants already given to the account. Read access for a status question does not have to include the right to change an order. Actions that move money, credit, or a customer commitment stay with a person until the estate has evidence to do otherwise.

The operator’s record of connections is the difference between a remote MCP server someone stood up and a connection the architecture team can name. Host the connection with the OMS estate. For programmes already running Sterling on Red Hat OpenShift, that is the natural place. The assistant remains a remote product. The credential and the approval record do not.

What this does not replace

This pattern connects approved AI products to OMS. It does not replace the storefront, checkout, or Order Hub, and it does not open a new sales channel.

Shoppers still belong on the commerce journey. People working inside Order Hub or Call Center still belong in those consoles, including any assistant built for that screen. The gap here is the employee who is already in ChatGPT or Claude and needs that product to reach OMS under company control. Treating those as one project produces either a shopper chatbot with an OMS password in it, or an operator assistant nobody opens because the question was asked somewhere else.

What to do on a live estate

Start from the questions teams already ask, not from a catalogue of tools. Order status, promiseability, and late shipments are enough to prove the path. Confirm the answers against OMS, not against a pasted extract.

Give the connection its own OMS account, granted only what those questions require. Resist the shared integration user that can do everything the programme can do.

Approve ChatGPT, Claude, or the next product as separate connections. Keep a list. When a product should stop, remove that connection and leave the OMS password unchanged.

Measure two things security teams already care about: copies of order and customer data into personal AI accounts, and remote MCP servers the estate did not approve. A sanctioned connection is useful only if the unsanctioned ones are visible.

Adaptive Development implements this boundary as the OMS MCP Proxy accelerator: one connection point for a Sterling estate, a separate approval for each AI product, and the OMS sign-in held by the service the company operates on OpenShift. The storefront and Order Hub programmes stay separate work.

Conclusion

Retail has already moved the question into ChatGPT and Claude. Managed AI is now the majority pattern in the Netskope retail set, personal use has not gone away, and remote tool connections are growing several times over in a single year. Sterling OMS remains the system that knows the order, the inventory, and the shipment.

The decision is where the sign-in lives. Put it inside the AI product, and every assistant becomes a holder of a company credential. Leave the assistants unconnected, and people paste the order into the chat. Approve each product as its own connection, keep the password in the estate, and OMS itself remains the limit on what that product can do.

Connecting remote assistants to Sterling OMS sits with AI Engineering.

The order system itself remains an Integration Services programme.