Your interns need three approvals to touch production. Your AI agents? Zero.
With MCP, agents can take real action – ✅ connect to databases, ✅ trigger workflows, ✅ access internal systems. The protocol just works.
What's missing is the operational layer that lets platform teams say yes without losing control.
Why Everyone’s Obsessed With MCP Right Now
byu/According-Site9848 inautomation
<!--kg-card-end: html-->
Over the last year, that early experimentation has turned into meaningful adoption.
MCP servers are now a core part of how modern agents interact with tools and data sources. The number of publicly available and deployable MCP servers has grown. So has the adoption.
More importantly, this adoption is happening in enterprise-aligned scenarios where teams are connecting dozens or hundreds of MCP servers in real deployments.
The pattern is clear across early adopters: internal MCP servers exposing company systems, third-party vendor servers, and open-source tools, all flowing through the same agent workflows.
Why operating MCP at scale introduces new requirements
A typical MCP setup today includes:
- Third-party MCP servers maintained outside the organization
- Internal MCP servers owned by platform or infrastructure teams
- Agents consuming both as part of a single workflow
Using multiple types of MCP servers changes the operational equation.
Authentication stops being uniform. Third-party servers use OAuth. Internal servers integrate with Okta or Entra ID. Agents now need credentials for both and the list keeps growing.
Access control gets complex fast. Some tools should be broadly available. Others need tight scoping by team, agent, or environment. Managing this at the agent or server level doesn't scale.
Visibility fragments by default. Usage data lives with each MCP server. Understanding which tools are actually being used, by which agents, and with what impact requires stitching together multiple sources.
Operational changes become risky. Rotating credentials, updating access, or enforcing new policies means touching individual servers or redeploying agents.
How Portkey's MCP Gateway works
The gateway sits between agents and MCP servers. It moves operational concerns out of individual servers and agent runtimes, and into a shared control plane managed by platform teams.
Unified authentication across MCP servers
Yes.
In ad-hoc setups, each MCP server handles auth independently. Agents juggle credentials. Platform teams can't rotate keys without touching every deployment.
The gateway centralizes authentication. Servers are authenticated once. The gateway handles downstream auth with each MCP server say OAuth flows, API keys, custom headers, whatever that server requires.
For internal MCP servers: Connect without distributing credentials. Access is managed at the organization, workspace, or team level.
For enterprise identity: Integrate directly with Okta, Entra ID, or any OIDC/OAuth-compliant provider. Users authenticate with existing enterprise credentials.
For third-party servers: OAuth flows and API keys are managed at the gateway level, not scattered across agent configs.
For existing APIs: The gateway can auto-generate MCP tools from OpenAPI specs, bringing them into the same auth model without building custom servers.
Fine-grained authorization and access control
Authentication gets agents in the door. Authorization determines what they can actually do.
The gateway enforces fine-grained access control across:
- Organizations, workspaces, and teams
- Individual users or agents
- Specific MCP servers
- Individual tools within those servers
Internal systems stay tightly scoped. Common utilities are available broadly. Permissions are policy decisions managed at the gateway—not implementation details buried in agent code.
Change access controls without redeploying agents or touching MCP servers.
Centralized MCP server and tool registry
Once authentication is centralized, access needs to be explicit.
Portkey’s MCP Gateway introduces a centralized registry that makes MCP servers and tools explicit, discoverable, and manageable. Every MCP server is registered once and becomes part of a controlled inventory rather than a hidden dependency embedded in agent runtimes.
The registry provides a clear view of:
- Internal, external, and third-party MCP servers
- The tools each server exposes
- Ownership and intended scope
- Usage across agents and teams
Platform teams can see which tools are being used, by which agents, how frequently, and in what context. This makes it possible to identify critical dependencies, spot unused or risky tools, and understand how MCP capabilities are actually being consumed.
MCP server usage data
By attaching usage data directly to MCP servers and tools, the registry supports informed decisions around access, policy, and lifecycle management.
Policy enforcement at the access layer
The gateway applies policies at the access layer, before requests reach LLMs or MCP servers:
Centralized guardrails: Enforce PII redaction, content filtering, and compliance policies once. They apply uniformly across every agent and workflow.
Block risky tool calls: Define which tools can take which actions. Prevent unauthorized invocations before they execute.
Consistent policies across LLMs and MCP: Use a single control plane to govern both model interactions and tool usage.
End-to-end observability for MCP usage
Portkey’s MCP Gateway provides end-to-end observability across the full agent execution path.
Every MCP interaction is captured in context:
- Which agent made the request
- Which MCP server and tool were invoked
- What parameters were passed
- How the call behaved and whether it succeeded or failed
This MCP-level visibility is correlated with LLM activity, giving platform teams a single, coherent view of how agents reason, act, and interact with tools. When something goes wrong, it is possible to trace failures back to the exact tool call or policy decision that caused them.
Combined with the MCP registry and policy enforcement, this visibility allows teams to operate MCP with the same rigor as any other production system.
What this enables for platform teams
With the gateway in place, MCP becomes infrastructure you can operate deliberately:
- Safe sharing of MCP servers and tools across teams
- Clear ownership and lifecycle management for MCP capabilities
- Centralized enforcement of security, compliance, and usage policies
- Faster iteration without embedding control logic into agents or servers
Most importantly: MCP can move from isolated usage to organization-wide adoption without increasing operational risk.
Built on production infrastructure
The gateway runs on the same infrastructure that processes 640 billion tokens monthly for Fortune 50 companies including DoorDash and Roche.
It integrates directly with Portkey's AI Gateway. Manage models, MCP servers, tools, policies, and observability through one control plane. Use them together or independently.
Also, the gateway is fully open source.
Inspect the code. Run it in your environment. Extend it for your use case. No opaque infrastructure in critical paths. No vendor lock-in.
This is infrastructure you can trust because you can verify it.
Speed up your MCP adoption today
MCP has changed how agents access tools. What’s changing now is how teams operate MCP once it becomes shared infrastructure.
As adoption accelerates, the challenge is no longer protocol support. It’s access control, policy enforcement, visibility, and security. These are platform problems, and they require platform-level solutions.
Portkey’s MCP Gateway is open source and ready to run.
Explore the repository, review the architecture, and try it with your existing MCP servers and agents.
If you’re operating MCP today or planning to roll it out across your organization, get started or book a demo with us!
Top comments (0)