A common enterprise AI requirement now sounds almost trivial: connect Microsoft Copilot to our internal tools through MCP. The transport is the easy part. The security boundary is where the design either becomes enterprise-ready or quietly creates a second, weaker way into the same systems.
Do not ask only, “Can the AI reach the tool?” Ask, “Who does the tool believe is asking?”
Four questions to ask before exposing an MCP server
Before an internal MCP server is made reachable from Copilot, another agent platform, or any remote AI client, four questions should have unambiguous answers:
- Who authenticated? The organisation should know which real user initiated the request.
- Which MCP capability is being exposed? A remote connection should not turn into a general-purpose route into the server.
- Whose identity reaches the protected resource? Access should remain bound to the actual user where that is the intended security model, rather than being silently substituted with a gateway or service identity.
- Can existing MCP servers be reused safely? Rewriting a working local server purely to make it remote often creates more code and more security surface than value.
These questions are broader than JD Edwards. They apply to files, diagnostic tools, databases using integrated OS authentication, internal APIs, administrative utilities and every other capability an organisation might put behind MCP.
Authentication at the front door is not enough
Microsoft Entra ID authentication can establish who is allowed to connect to an MCP endpoint. That is important, but it does not by itself answer what happens after the gateway accepts the request.
If every downstream tool runs under the same powerful service identity, then ten thousand individually authenticated users can still become indistinguishable at the systems that hold the data. The gateway knows who they are; the resource that matters may not.
That creates an awkward split. The AI layer has one identity model, while the existing enterprise systems have another. Security teams then have to maintain a second set of permissions that tries to imitate the first one.
Prefer the boundaries you already trust
Enterprises have spent years deciding who may read which folders, reach which servers, access which databases, query which resources and perform which operations. An AI integration should preserve those decisions rather than route around them.
The strongest pattern is simple to describe: access to the protected resource stays bound to the person who actually made the AI request. Their identity is not replaced with another identity on the way to the resource, so their existing rights remain the authority that decides what can happen.
If Alice asks Copilot to read a protected file, Alice reads the file. The file access occurs under Alice’s identity and Alice’s existing permissions. Copilot is helping Alice do the work; it does not become a new reader with broader rights to the organisation’s files.
If Alice asks Copilot to query a database that uses integrated OS authentication, the database access occurs as Alice, not as a shared AI or gateway account.
The protected resource authorises Alice first. The AI receives only the information returned by the MCP operation Alice was authorised to perform; it is not independently granted a broader identity over the underlying files, servers or databases.
The same test works in reverse: if Alice can reach a resource and Bob cannot, adding Copilot should not make them equivalent simply because they happen to use the same MCP gateway.
What about existing STDIO MCP servers?
A large amount of useful MCP software was built as a local STDIO server. That is a perfectly sensible shape for a tool that originally ran next to an MCP client. Enterprise AI platforms increasingly need authenticated remote access instead.
There are two ways to respond: rewrite every local MCP server into a network service, or put the enterprise boundary in one place and leave the business tool alone. The second pattern is often easier to govern because the responsibilities remain separate: the gateway owns remote access and identity; the MCP server owns its particular capability.
For tool-oriented MCP servers, that reuse can be very direct: existing STDIO MCP tool servers can normally remain unchanged behind the gateway. Servers that depend on richer client-side or server-initiated MCP interactions — such as sampling, elicitation or subscriptions — may require adaptation, so compatibility should be assessed rather than assumed for every possible MCP capability.
What a security review should ask for
A useful review is much more concrete than “is MCP secure?” MCP is a protocol; the security outcome depends on how it is deployed. Ask the proposed solution to demonstrate:
- authenticated enterprise access rather than an anonymous endpoint;
- protected-resource access remaining bound to the signed-in user where user-specific security is intended;
- no automatic elevation to a broad shared identity;
- the ability to reuse narrow, existing MCP servers rather than building an unrestricted agent shell;
- simple revocation when a user loses access to the underlying resource;
- no substitution of the user identity with a broader backend identity merely because the request arrived through AI;
- an explicit allowlist of MCP backends, so the AI cannot choose arbitrary programs to run;
- limits that protect gateway capacity and inbound request size;
- auditing that ties activity back to user, endpoint, tool and outcome;
- read-only operational visibility into gateway health and activity.
That is also a better procurement conversation. It turns “secure AI” from a slogan into a set of behaviours that can be tested.
Where Steward fits
Steward is designed for this exact boundary: authenticated remote MCP access for Microsoft Copilot and compatible enterprise AI clients, reuse of existing tool-oriented STDIO MCP servers, and access to configured protected resources kept bound to the actual requesting user identity without substituting another backend identity. This includes configured file shares, servers and databases that use integrated OS authentication.
The important claim is not that it invents a new permission model. It is that it avoids forcing you to invent one.
If the business already trusts its user identities and permissions, the MCP layer should preserve them all the way to the protected resource rather than flattening many users into one backend account.