You've built an MCP service that does something genuinely useful. It pulls from Salesforce, cross-references billing data, and updates a support record, all in a single flow and on behalf of a real user. The demo went well. People are using it. Maybe there was even a round of applause.
Then someone in IT or security asks a straightforward question: "Who made that change in Salesforce? And were they actually allowed to make it?"
And the honest answer is: the service account.
That's not a good answer because a service account is not a person. It's a shared account that could have been anyone, running a service that could have been triggered by anyone. And because it isn't acting on behalf of a specific user, it isn't bound by that user's actual permissions — creating real risk that people end up with access to data in underlying systems they shouldn't have. And when the action completes, the record updates, but the person who actually triggered it was never logged.
This is where most enterprise MCP deployments quietly run into trouble — not at the capability layer, but at the security, identity, and accountability layer.
The identity question MCP doesn't answer
When an MCP service acts on a user's behalf, there has to be an answer to the question: whose credentials is it running under, and is it acting within the scope of their permissions?
For simple, single-app tools, the answer is usually fine. You wire up an OAuth connection, it works, and the blast radius if something goes wrong is limited.
But enterprise MCP services aren't single-app. The ones that actually matter (and justify the investment) touch CRM, finance, billing, ops, often in sequence and across teams. For those workflows, getting authentication right means implementing it correctly for every system the tool touches — ensuring each user can only access what they're actually authorized to. That's expensive to set up, fragile to maintain, and almost nobody does it properly.
Service accounts aren't inherently the problem. Some apps need them. The problem comes when a service account is the only option, and it's acting on behalf of every user across every system. At scale, that's a liability because you lose both control and visibility.
So teams do what makes practical sense: they hardcode credentials into the workflow logic. Or they find something in between that works well enough to ship.
The service runs so nobody complains. The identity problem gets buried. The security risk is real.
The cost you don't see until something goes wrong
But the trouble with burying it is that the cost is invisible right up until it isn't.
Every action an MCP service takes under a shared account is an action that can't be attributed. It also means there's no guarantee each user stays within the bounds of their actual permissions — the organizational structures, data restrictions, and access controls they've been individually assigned in the systems they use. Your audit trail tells you something happened, but not who triggered it, not whether they were entitled to do it, and not whether the permissions the service used matched what that person should actually have had.
The result is an agent running with more access than any individual user would ever be granted.
For IT and security teams, this is the gap that blocks MCP at enterprise scale.
What Dynamic Authentication for MCP changes
Dynamic Authentication for MCP is a new capability in Tray Agent Gateway, built on our Agent Identity Management framework. The idea behind it is straightforward: instead of a builder hardwiring credentials into the service, users are dynamically prompted to authenticate at the moment the tool executes — so they stay strictly within their own access and permissions, rather than running under a shared account. Every action that follows is tied to a real identity, with a complete record.
The "dynamic" part matters. With Tray, you can build sophisticated MCP tools that access multiple apps and services, and Agent Gateway handles authentication for each of them on demand — so the right credentials are always in play, for the right user, at the right moment.
For builders, this significantly reduces the overhead and risk of credential management when deploying MCP at scale. You configure which authentications should be user-provided at the authentication level in Agent Gateway. Once set, it applies across every tool that uses that authentication. From that point, each user is prompted for their own credentials when they access the MCP service.
For IT and security, it's a powerful way to bring enterprise auditability to MCP at scale. Every MCP action is attributable to a real user, executing strictly within their own permissions, logged completely. When something needs investigating, the record is there — who did it, what system they touched, and when.
Identity that holds through every layer
The identity problem doesn't just exist at the surface of an MCP service. It follows the execution down.
Enterprise MCP services are rarely single-layer. A tool typically calls sub-workflows, which call further callables, each touching different systems. Most auth implementations handle the first layer and stop there — nested workflows fall back to whatever account is configured at the surface, which means the deeper the service goes, the thinner the audit trail gets.
Dynamic Authentication propagates through every layer of composition. The user's identity follows the execution through every layer of the service. Which means teams building complex, multi-system MCP services don't have to make architecture decisions based on where the identity model will fail. They design for what the process actually requires.
There's a compounding benefit here, too. Because Tray workflows are composable, the same callable logic can be reused across different triggers — a traditional automation, an API, and an MCP tool can all draw on the same underlying workflow. Identity is preserved correctly across all of them. That means you can follow the best, most maintainable design patterns, every time.
Sophisticated MCP Tools meet strong identity management
A sophisticated MCP Tool is one that encapsulates a significant portion of a business process. Enterprises are building these kinds of tools to achieve greater determinism — which is essential for enabling agents to perform complex actions that shouldn't be left to on-the-fly reasoning. Think an Order Management Tool that taps into CRM, ERP, CPQ, and other systems in a single flow.
Building MCP tools with this level of multi-app connectivity is a fundamental requirement for production enterprise MCP. But having users access them on demand introduces significant auth complexity. Building these services from the ground up in code, while ensuring strong authentication across every system they touch, is a significant burden on IT.
At Tray, we call these Composite MCPs — tools that access multiple apps and services, along with all the associated business logic. That's exactly where Dynamic Authentication for MCP shines: IT can build these services, and Agent Gateway handles the auth complexity.
The question you should be able to answer
What does it take to go from MCP pilot to production?
Enterprise MCP is moving fast. The services organizations actually need — the ones that span multiple systems and act on behalf of real people — require an identity foundation that can keep up. Without it, you risk unintended security exposure, a bottleneck to MCP development, and compliance roadblocks.
"As we roll MCP out across Zuora, I don't want end users thinking about which system they're authenticating to or what tools they have access to — that should stay opaque. Tray's Dynamic Authentication lets the prompt drive tool selection and triggers auth only when it's needed, per user. That's the model that lets us scale agents across the enterprise without compromising on user-level permissions."
If someone asked you today "who made that change?", you should be able to give them a name, a timestamp, and confirmation that the action was within that person's actual permissions
That's what Dynamic Authentication for MCP is built to make possible.
- Dynamic Authentication for MCP is available now in Tray Agent Gateway.
- For more information, read the Tray Agent Gateway documentation.
