Blog / Agent development and automation

Governing the MCP servers and AI agents you already run

Most teams govern MCP after the fact. The choice between proxying the servers you have and replacing them decides most of what follows.

Alistair Russell avatar

Alistair Russell

Co-founder and CTO

Most teams start governing MCP after the fact, with servers already running and agents already connected. There are two ways to take control. A proxy gateway sits in front of the servers you have and adds authentication, access rules, and logging. The other approach retires those servers and publishes governed tools that call the same systems’ APIs directly. Tray Agent Gateway takes the second approach. Each tool runs with a named user’s permissions or a scoped service account, and every call lands in one audit log, whichever AI client makes it. It won’t sit in front of a vendor’s MCP server you need to keep, and an agent’s own model and memory stay with whoever built it.

The usual starting point looks like this. Engineers connected Claude and Cursor to MCP servers for GitHub, Salesforce, and a couple of internal systems months ago. A team is piloting agents in Copilot Studio. Then a security review asks for a list of what AI can reach, and nobody can produce one. Governing that estate is a different job from designing governance on a blank page, and it starts with finding out what exists.

Find out what you have

Before choosing an approach, build the inventory: which MCP servers are running, who connected them, which clients use them, and which credentials each one holds. Some of that is visible in your identity provider, your DNS logs, and your expense reports. Some of it lives only on engineers’ laptops. How shadow MCP spreads, and how to find it covers where to look, and the AI and MCP governance page sets out the stages that follow discovery.

Two ways to take control

Every MCP gateway makes one design choice that decides most of what follows: does it sit in front of the servers you already run, or does it replace them?

Proxy the servers you have Replace them with governed tools
What changes for teams Agents point at the gateway, and the servers keep running behind it Agents use tools the platform publishes, and the separate servers are retired
Where credentials live With each server, unless the gateway brokers them With the platform, scoped to each tool
How finely access can be restricted Depends on what each server exposes and what the gateway can filter Per tool and per operation, because the platform defines the tool
What you still maintain Every server, its updates, and its credentials The tools you publish
Audit A log at the gateway, plus whatever each server records One log for every call
Suits Teams that depend on specific vendor servers today Teams that would rather run fewer servers
Examples Workato, Boomi, TrueFoundry, Kong, Docker, Microsoft Tray.ai, Composio, Zapier, Boomi Connect, Workato's prebuilt MCP servers

Examples from our comparison of MCP gateways, checked against each vendor’s own pages.1

Neither approach is right for everyone. If a team’s daily work depends on a particular vendor’s MCP server, a proxy governs it where it is. If the estate is a server per system, each with its own credentials and its own log, replacing them leaves fewer things to secure and fewer logs to reconcile.

What good governance records

Whichever approach you choose, the log is what you’ll be asked for. For every call, it should show the person behind the request, the client or agent that made it, the tool it called, the credentials it ran on, and what happened. Shared service accounts are the common gap: when every action runs under one account, the log names a service rather than a person. The MCP security and governance framework sets out the controls in more detail.

Agents need more than a gateway

A gateway governs what an agent can reach. It doesn’t decide which agents should exist, who owns each one, how they’re tested before they reach production, or when they’re retired. Those lifecycle questions sit alongside tool access, and the checklist for governing AI agents in production covers them, including where dedicated model governance tools fit.

Can Tray.ai govern your MCP servers and AI agents?

Yes, by replacing the servers with governed tools. Tray Agent Gateway for MCP connects to each system’s API directly through Tray’s 700+ connectors and publishes governed MCP tools on top.2,3 A tool can be a single connector operation or a whole workflow packaged as one composite tool, such as a Customer 360 lookup that pulls from Salesforce, Zendesk, and Stripe in one call.3

  • Who can call what. MCP servers are configured per workspace, with selective tool exposure and an access management allowlist of users.2
  • How clients connect. AI clients authenticate with OAuth2 or an API token.2
  • Whose credentials run. Each tool runs on a shared service account or on the end user’s own credentials, and the user is prompted to authenticate at runtime when a tool needs it.2
  • What gets recorded. Logs show which user ran each tool and which authentication it used. Sensitive data is protected through access controls and masking, and rate limits and audit logs apply at organization and workspace level.2

Granularity is where replacing servers pays off. To give agents read-only Salesforce access, you expose the query operations and leave out create, update, and delete. That control isn’t available when an agent connects to a server directly and tool availability is managed on the client side.2

Agent Gateway governs MCP whichever client makes the call. Agents in Copilot Studio, Claude, OpenAI, or your own framework get the same policies, and you don’t need to build your agents on Tray to use it.3 For agents you do build on Tray, Agent Builder adds guardrails and audit logs to the agent itself.4

J.W. Pepper used Agent Gateway to reduce more than 500 MCP tools to about 20 governed workflows, with zero raw database access.1

“We can now use Tray.ai to spin up new MCP Tools on a managed path. IT approves what's built, enforces policies and permissions, versions it, and publishes. We get centralized visibility and auditability across the MCP Servers and Tools we deploy — reducing risk.”

Marcus Dubreuil Enterprise Architect, AI & Automation Strategy, J.W. Pepper

Where Tray isn’t the answer

Two situations call for something else. If a team needs a specific vendor’s MCP server to stay in the request path, Agent Gateway won’t sit in front of it, and a proxy gateway such as Workato, Boomi, Kong, or Docker will.1,3 And if you need policy over how a third-party agent reasons, which model it uses, or what it remembers, that belongs with the agent’s own platform or a dedicated AI governance tool. Agent Gateway governs what an agent can reach and do through tools.

Getting started

Agent Gateway for MCP is part of the Agent Development add-on, and your Tray account team switches it on for your organization.2,4 From there:

  1. Configure a workspace MCP server and add tools, either workflows or connector operations.
  2. Set how each tool authenticates, with a service account or the user’s own credentials.
  3. Add users to the access management allowlist.
  4. Connect a client such as Claude Desktop, Cursor, or VS Code over OAuth or an API token, test the tools, and expand to composite tools.2

Retiring the old servers can happen one system at a time. Publish the governed tool, move the agents that used the old server, and switch the server off once nothing calls it.

Sources

  1. Tray.ai blog, The 11 best MCP gateways for enterprise governance in 2026: https://tray.ai/blog/best-mcp-gateways/
  2. Tray.ai documentation, Agent Gateway overview: https://tray.ai/documentation/platform/artificial-intelligence/agent-gateway/overview
  3. Tray.ai, Agent Gateway for MCP: https://tray.ai/platform/agent-gateway/
  4. Tray.ai, pricing: https://tray.ai/pricing/

Related how-to guides

Step by step guides with copy-paste prompts for your coding assistant, and what it takes to run each one in production.

How to build

Integration

MCP audit trail

Log every MCP tool call with the person, the assistant, the tool, what went in and what came back, mask what should not be stored, and send it to security's tools.

Splunk Datadog Snowflake Okta

How to manage

Automation

MCP server lifecycle

Publish MCP servers through an approval, keep a version history with a way back, tell the agents that depend on a tool before it changes, and retire what nobody uses.

GitHub Jira Slack Snowflake

How to build

Automation

MCP tool access review

Review on a schedule which MCP tools exist and which people and AI assistants can call them, send each owner the usage behind it, and revoke what nobody uses.

Okta Snowflake Slack ServiceNow

All how-to guides

Frequently asked questions

Can Tray.ai govern our MCP servers and AI agents?

+

Yes. Tray Agent Gateway for MCP replaces separate MCP servers with governed tools built on Tray's connectors and workflows. It controls who can call each tool, whose credentials it runs on, and what gets logged, for any AI client. It doesn't proxy existing servers, and it governs what agents can reach through tools rather than the agents' own models or memory.

Should an MCP gateway proxy existing servers or replace them?

+

It depends on what you already run. If teams depend on specific vendor MCP servers today, a gateway that proxies them governs them where they are. If you'd rather run fewer servers, a platform that publishes governed tools from its own connectors replaces them with one layer, which means fewer credentials to hold and fewer logs to reconcile.

Does Tray Agent Gateway sit in front of our existing MCP servers?

+

No. Agent Gateway connects to each system's API directly through Tray's connectors and publishes governed MCP tools in place of the separate servers. If a specific vendor's MCP server needs to stay in the request path, Agent Gateway doesn't sit in front of it.

Which AI clients work with Tray Agent Gateway?

+

Any MCP-compatible client, including Claude, ChatGPT and other OpenAI clients, Copilot Studio, Cursor, VS Code, and agents built on your own framework. The same policies apply whichever client makes the call.

Can an MCP tool run with the end user's own credentials?

+

Yes. Each tool can run on a shared service account or on the end user's own credentials. When a tool uses the user's credentials, they're prompted to authenticate at runtime, and the log records which user ran the tool and which authentication it used.

Do we need to build our agents on Tray to use Agent Gateway?

+

No. Agent Gateway governs MCP regardless of the client, so agents built in Copilot Studio, Claude, OpenAI, or your own framework get the same policies. Agent Builder is there for teams that want to build agents on Tray as well.