Why production AI depends on more than connectivity.
In the last few articles, we’ve looked at how AI systems can be connected to HPE Nonstop environments, why Nonstop is unusually well placed to participate in AI-driven workflows, and what kinds of practical use cases become possible once that connection exists – Bridging Worlds: AI Meets Nonstop Through Model Context Protocol, AI and the Nonstop Advantage, and From Connectivity to Capability: Leveraging AI on HPE Nonstop.
Moving the discussion away from abstract AI enthusiasm and towards something more useful is the point: how existing Nonstop applications, data and operational processes can be made available to modern tools without changing the systems that already work.
But once that bridge exists, the next question is unavoidable.
Who, or what, should be allowed to use it?
A demonstration can get by with broad permissions, a simple test transaction, and a friendly environment where the consequences of a mistake are low. Production systems are different. In a Nonstop environment, the applications being exposed are often part of payment processing, telecommunications, retail switching, fraud management, or other business-critical workflows. “Let’s see what happens” is not an acceptable operating model for these systems.
Governance is central to any serious AI integration strategy.
Access is not governance
It is tempting to think of governance as a policy issue, something that sits around the technology rather than inside it. In practice, the distinction does not hold for long.
If an AI assistant can query the status of a Pathway serverclass, run a diagnostic transaction, retrieve customer or transaction data, or trigger some form of operational workflow, governance becomes part of the integration design. Knowing that a request arrived over TLS, or that the caller presented a valid token, is only the starting point.
The enterprise also needs to know what capability was exposed, which client was allowed to invoke it, where the request was routed, and how that interaction can be reviewed later, down to the input provided and the response returned.
That is a more demanding requirement than simple connectivity, and it is where Nonstop users are likely to be more realistic than most. The platform has always been used in environments where access control, auditability, operational discipline and change management matter. AI does not remove any of those requirements. If anything, it makes them more important.
A request originating from an AI tool is no less significant than one coming from a web application, mobile app, batch process, API gateway, or operator screen. If it can touch a production transaction path, it needs to be governed accordingly.
Expose capabilities, not systems
One of the most useful ways to think about AI governance is to avoid exposing systems directly.
An AI client should not be given broad access to a backend application and left to work out what to do. It should be presented with a carefully defined set of capabilities, each with a clear purpose, clear inputs, clear outputs, and clear authorisation requirements.
In MCP terminology, these are exposed as tools. In Nonstop terms, those tools might map to Pathway server transactions, Guardian or OSS processes, HTTP endpoints, TCP/IP services, or other configured backend resources. The AI-facing capability should be deliberately designed, not merely opened up.
There is a big difference between exposing “run any PATHCOM command” and exposing “return the current status of this defined set of serverclasses”. A similar gap separates a general transaction enquiry from a masked, read-only transaction summary built for a specific operational support workflow.
The second approach is far more likely to make it through a production risk review.
This is also a natural fit for the way uLinga Nexus works. Nexus is not simply a pipe between an AI client and a Nonstop backend; it provides a configured integration point where capabilities can be defined, authenticated, authorised, transformed, routed and traced. JSON payloads can be converted into the DDL-defined structures expected by existing Nonstop applications. Responses can be transformed back into formats that modern clients can understand. Existing applications can participate without needing to be rewritten for AI.
Governance becomes much easier once the integration layer is explicit like this. An exposed capability that is configured and managed can also be reviewed, tested, limited and monitored.
Figure 1 — An AI client connects through uLinga Nexus, which authenticates, scopes, transforms and traces each request before it reaches a defined Nonstop resource.
Least privilege applies to AI too
Most organisations already understand the idea of least privilege: users and applications should only have access to the functions and data they need to perform their role.
The same principle applies to AI clients, and in uLinga Nexus it is applied at the point where a capability is defined, not left to the client to observe.
An AI client is never pointed at a backend and left to work out what to do. It is presented with individually defined tools, each bound to one specific operation. A diagnostic tool, for example, can be defined as a single fixed command such as a serverclass or process status query, rather than a general “run any command” capability. The client can supply values only for the parameters the tool explicitly exposes. It cannot substitute a different command, and it never sees the backend directly.
The same boundedness applies to data. A file-retrieval capability is defined by a template that matches a specific location and pattern, for example a particular log or source subvolume. Nexus turns that template into a constrained resource: the client can list and read only the files that match the pattern, and cannot reach outside it. “Retrieve operational data” becomes “read the files in this one defined place” — a very different proposition in a production risk review.
Authentication and transport still matter, and Nexus applies them. MCP endpoints sit behind an OAuth2 bearer-token profile: Nexus validates each incoming token’s signature, against the identity provider’s published keys, and its expiry, before any request reaches a tool. A client must present a valid, current token issued by the trusted provider to invoke anything at all. Where finer-grained separation is needed between what different clients may do, it is expressed primarily in which tools each client is given and how narrowly each tool is defined, together with the scopes the identity provider issues — not by exposing one broad tool and hoping the token restrains it.
The management interface follows the same discipline. It can be disabled entirely, bound to a single management address, and required to run over TLS. For accounts that do reach it, access is role-based, including a read-only role that can inspect configuration and status but cannot start, stop, or reconfigure anything. The same least-privilege thinking that governs an AI client’s tools governs who can change the integration itself.
Someone still has to decide which tools exist, how narrowly each is scoped, which clients can authenticate, and what each tool is allowed to touch — a security problem, an integration problem, and an application design problem all at once. Nexus makes those decisions explicit and configurable rather than implicit.
Human approval is not a failure of automation
There is a tendency in some AI discussions to treat full autonomy as the goal. That might make for an impressive demonstration, but it is not always the right model for production systems.
In many Nonstop environments, the more credible pattern is: AI observes, AI analyses, AI recommends, a human approves, and a governed tool executes.
Far from a compromise, that workflow is often exactly what the business needs.
Figure 2 — A five-stage workflow. Read-only, approval-gated and fully automated tools sit at different points on this line.
Consider an operational incident involving a Pathway application. An AI assistant might gather status information, inspect configured resources, compare behaviour across related serverclasses, retrieve relevant EMS messages, and run a test transaction, then recommend that a particular action be taken. In some environments, the assistant may only present that recommendation to an engineer. In others, it may be allowed to execute a narrowly defined remediation tool after explicit approval.
Both models can be valuable. The right choice depends on the risk of the action, the maturity of the process, and the organisation’s appetite for automation. What matters is that the integration layer can support the control model — read-only tools, approval-gated tools, and fully automated tools should not all be treated the same way.
Auditability makes AI operationally defensible
AI systems can be difficult to explain in a traditional sense. The surrounding enterprise process does not have to share that problem.
For production use, organisations need to be able to reconstruct what happened. Which client connected? Over which session, and from where? Which tool was invoked? Which backend resource was it routed to? Did the request succeed or fail?
Nexus ties these interactions together. Each MCP interaction is associated with a client identity and a session, and the tool invoked is linked to the specific backend resource it was routed to, along with the success or failure of each request. Operations gets a reconstructable trail of which capability was used, in which session, against which backend, and with what outcome — the same discipline normally applied to application, operator, or partner-initiated activity, now applied to AI-initiated activity.
As integrations mature, this trail is designed to be extended with the richer detail regulated environments will want to associate with each invocation, such as the granted scopes, the parameters supplied, the response returned, and the time taken. Because the interaction passes through a single configured integration point, the record has one place to live and one place to be reviewed, according to the organisation’s normal security and retention policies.
An AI deployment without this visibility is hard to approve for serious use. One with it becomes a much more practical conversation: an invoked tool is recorded and attributable, and a backend response can be traced back to the interaction that produced it. That is the difference between operationally defensible and merely impressive.
Start small, but design properly
The right starting point for most organisations will not be the highest-value, highest-risk transaction. It will be a bounded use case with clear operational value and limited downside.
Read-only diagnostic tools are a good example. So are masked enquiry transactions, structured operational summaries, or tightly scoped support workflows. These use cases let an organisation prove the integration pattern, validate the security model, test auditability, and build confidence with operations and risk teams before expanding capability from there.
Nonstop environments suit this incremental approach well. Existing applications can remain in place. Individual capabilities can be exposed through Nexus as needed. Governance can be applied at the tool level. Each new use case can be assessed on its own merits rather than folded into a large, speculative AI programme.
It is a more modest approach than some AI narratives suggest — and considerably more likely to work.
The control layer matters
For Nonstop users, the attraction of AI is not that it replaces the qualities of the platform. It is that AI can make existing systems more accessible, more useful, and easier to operate, while leaving the core transaction processing environment intact.
None of that works without controlled access.
uLinga Nexus provides a practical foundation for that control layer. By combining MCP support with the security, transformation, routing and tracing capabilities required in real Nonstop environments, it lets organisations expose useful capabilities without handing over unrestricted access to the systems behind them. That distinction will matter more, not less, as AI projects move from proof of concept to production.
Whether AI can connect to HPE Nonstop is no longer the question. It can.
How that connection is governed, constrained, observed and trusted is what separates an interesting demonstration from a production architecture.
This article is part of an ongoing series exploring the role of AI, Model Context Protocol (MCP), and controlled access to HPE Nonstop systems. Previous articles have covered the foundations of MCP-based integration, the Nonstop advantage in AI-enabled environments, and the practical capabilities that become possible when AI can interact with existing Nonstop applications. For more information about uLinga Nexus, contact Infrasoft at info@infrasoft.com.au.