MCP User Identity vs Shared Service Accounts

There are two very different statements that can both sound like “our MCP server uses enterprise authentication.” In the first, access to protected resources remains bound to the signed-in employee’s actual identity. In the second, the employee is authenticated only at the gateway, after which every request runs under one shared service account.

The gateway may know who Alice is while the backend sees only “MCP-Service”.

Why shared service accounts are so attractive

Shared identities are popular because they simplify integration. The service receives one set of permissions, developers test one access path, and backend systems do not have to understand anything about the individual AI user.

For a tightly scoped system-to-system process, that may be exactly right. A nightly integration job is not a human being and often should have its own carefully limited identity.

The problem starts when an interactive AI assistant is acting on behalf of many different people. The service account then becomes a funnel through which users with different jobs, responsibilities and entitlements arrive at the backend as the same principal.

What gets lost when everyone becomes the same account?

• Existing permissions. The file share, server, application or database using integrated OS authentication is no longer accessed under the identity of the person whose permissions were reviewed and approved.
• Least privilege by user. The shared account often needs the union of permissions required by all of its users, which can be far broader than any individual should possess.
• Simple revocation. Removing Bob from a resource may no longer remove Bob’s AI-assisted route to that resource if the service account still has access.
• Clear accountability. The AI layer may record the user, but native resource logs and controls can show only the shared identity unless another correlation mechanism is maintained perfectly.
• One source of truth. Administrators now have to manage both the organisation’s normal access model and a second policy layer for what the shared MCP identity may do for each user.

What identity-preserving access changes

Identity-preserving access keeps a simple rule intact: when the assistant works for Alice, protected-resource access stays bound to Alice’s actual identity; when it works for Bob, it stays bound to Bob’s. If Alice asks Copilot to read a file, Alice reads the file. If she asks it to query a database using integrated OS authentication, the database access occurs as Alice. Copilot is the interface for the request, not a replacement identity standing above the organisation’s permissions.

This matters because enterprise permissions are not merely technical configuration. They encode approvals: the finance group may reach one share, the support team another, administrators a third. Keeping access bound to the caller means those existing decisions remain the authority, instead of being replaced by a second AI-specific approximation.

When a shared identity can still be the right answer

There is nothing inherently wrong with service accounts. The question is whether the identity matches the workload.

A shared identity is often reasonable when the MCP tool exposes one narrow business operation whose own rules fully determine what can happen; when the underlying resource has no user-specific access distinction to preserve; or when the tool deliberately acts as an application rather than as the human caller.

It becomes harder to justify when the tool reaches ordinary files, servers, databases using integrated OS authentication or other internal resources that already enforce user-specific access.

Questions to ask an MCP gateway vendor

• After the user authenticates, does protected-resource access remain bound to that actual user identity, or is another identity substituted?
• If two users have different rights to the same file share, server or database using integrated OS authentication, will the MCP path preserve that difference automatically?
• If a user loses their normal access tomorrow, does the AI path lose it automatically too?
• Does the solution require a broad shared service account to read user-protected resources?
• Can existing tool-oriented STDIO MCP servers normally remain unchanged, or must they be rewritten to understand a new identity scheme?

Those questions reveal far more than a generic statement about supporting SSO.

Where Steward fits

Steward is a secure MCP gateway designed around the interactive-user case: Microsoft Entra ID at the remote boundary, compatible tool-oriented STDIO MCP servers behind it, and access to configured protected resources kept bound to the actual requesting user identity without substituting a shared or gateway identity. Existing file and server permissions, and permissions on databases using integrated OS authentication, can therefore remain authoritative.

That is particularly important wherever the protected resource already distinguishes users — including databases using integrated OS authentication and diagnostic/file-oriented tools such as the MCP Server for Log Analysis, where different users may legitimately be entitled to different servers, folders and log files.