End-user credentials for MCP tools
Updated Oct 1, 2026
Enterprise MCP adoption requires more than exposing tools to AI agents. It also requires a way to control which downstream systems those tools can access, whose credentials are used, and how activity can be traced after the tool runs.
When MCP tools run under a shared admin credential, every action appears to come from the same account. Downstream systems lose user-level attribution, application permissions are applied to the shared credential rather than the person making the request, and one compromised credential can affect every workflow that depends on it.
That model may be acceptable for early experimentation. But it does not scale well for enterprise teams running MCP tools across departments, partners, or customer-facing workflows. The moment a team needs to answer “who did this?” or enforce per-user access in a downstream application, shared credentials become a governance gap.
End-user credentials help close that gap. By requiring each user to authenticate with their own downstream application credentials, Celigo can support more identity-aware MCP tool execution as part of the broader integration capabilities needed to develop, govern, and orchestrate AI agents.
How shared credentials break down at scale
A common pattern in early MCP deployments is to connect tools through a service account or shared admin credential. It is a fast way to get tools working, and it may be acceptable for testing or limited internal use.
The problems appear when MCP tools are used by multiple teams, departments, partners, or customer-facing workflows.
Shared credentials create several governance challenges:
- Downstream audit logs show actions as coming from the same account, making it difficult to attribute activity to the individual user who initiated the request.
- Application permissions are based on the shared credential, not the end user, which can give users broader access than they should have.
- A compromised shared credential can affect every user, tool, and workflow that depends on it.
- Compliance reviews have less user-level evidence to show who performed an action, which system was accessed, and under whose authority.
These are not edge cases. They are the natural limits of applying a shared credential model to multi-user MCP deployments.
For enterprise AI agent workflows, MCP tools need a stronger identity model. End-user credentials help address this by letting each user authenticate with their own downstream application credentials, so access, attribution, and governance can more closely reflect the person behind the request.
What this looks like in practice
Say a support team uses an AI agent with MCP tools that touch Salesforce, NetSuite, and Gmail. Without end-user credentials, every action from every team member looks identical in each of those systems: one shared identity, one shared set of permissions, regardless of who’s actually using the agent.
With end-user credentials, each person’s own identity carries through. Salesforce enforces that person’s actual permission profile. NetSuite applies their specific record-level access. Gmail sends from their own account. The agent doesn’t get broader access than the person operating it already has.
Shared credentials vs. end-user credentials
| What changes | Shared admin credential | End-user credentials |
| Downstream identity | One shared account for everyone | Each person’s own identity |
| Permissions applied | Admin’s broad access, for every user | Each person’s actual permission profile |
| Audit trail | Every action looks identical | Attributed to the specific person |
| Blast radius if compromised | Every user, every tool | Just that one person’s credential |
Admins mark a connection as “end-user credential required.” From that point, each end user provides their own credentials once during a guided setup flow when connecting to an MCP server.
Tools then execute under the end user’s own identity in the downstream app. The downstream app sees an authenticated request from that specific person, with that person’s permissions applied, and logs the action against their account.
How credentials behave once they’re set up
One setup, everywhere it’s needed
Once an end user authenticates, credentials resolve automatically wherever the same parent connection is used, across servers and nested tools, at any execution depth. There’s no repeated setup as your MCP footprint grows.
Every auth type is supported
OAuth, API key, basic auth, and token authentication are all supported. End-user credentials aren’t limited to OAuth flows.
Admin-controlled scope
Admins control which connections require end-user credentials and can configure cross-server reuse so the same parent connection works across multiple MCP servers. End users authenticate once and that credential travels with them.
Admins see status, not credentials
Admins can see whether a given end user’s connection is online, offline, or expired, but they can’t view the actual credential values. If a required connection goes down for one person, that person sees their MCP server as disconnected until they reconnect; it doesn’t affect anyone else.
Why this matters
IT and security teams: End-user credentials help reduce the blast radius of a compromised credential. Instead of one shared admin credential exposing every user and workflow that depends on it, access is tied to the individual user’s downstream application permissions.
Compliance teams: User-specific credentials improve auditability by helping downstream systems attribute activity to the authenticated user, where the downstream application supports user-level logging. That gives teams stronger evidence for access reviews, incident investigation, and compliance reporting than a shared account model.
Platform teams: Once a user authenticates to a downstream application, that end-user connection can be reused across MCP servers and tools that rely on the same parent connection. That reduces repeated authentication steps while keeping access tied to the user rather than a shared service account.
→ Learn more: Configure end-user credentials for an MCP server connection
What this means for governance
End-user credentials are one part of Celigo’s broader enterprise MCP governance model, alongside end users and groups, capability sets, JIT provisioning, and IdP group sync.
Together, these controls help answer the questions that matter as MCP usage scales: who can use which tools, which capabilities they can access, which credentials are used at execution time, and how activity can be reviewed afterward.
End-user credentials close an important part of that governance model at the execution layer. Instead of running MCP tools through a shared admin credential, Celigo can require users to authenticate with their own downstream application credentials. That helps downstream permissions more closely reflect the person making the request and improves user-level attribution where the connected application supports it.
The result is a stronger governance model for enterprise MCP adoption: access is assigned in Celigo, capabilities are scoped through MCP servers and capability sets, and execution can use the end user’s own application credentials rather than a shared service account.
