Put one gateway in front of every agent-to-tool call

An agent has no sense of what it ought to be allowed to do. It does what it’s asked, with whatever access its token carries. If the token reaches every repository, the agent can reach every repository. If the token has full access to the CRM, so does anyone who can get a sentence in front of the agent.

That makes agent access a different kind of problem from user access. A person with too much access usually does nothing with it. An agent with too much access will use it the moment someone, or something, asks.

Agents you have not counted

Most organizations believe they know which agents are running. The evidence says they’re optimistic.

Those two figures come from the same 418 people.¹ The survey has a sponsor with an interest in the answer, so weigh it accordingly. What I’d keep is the gap between the two numbers.

Confidence ran ahead of reality. If you can’t list the agents, you can’t list what each one is allowed to touch.

Four incidents in five months

Between May and September 2025, four incidents showed how agent and integration access goes wrong. Each is worth telling accurately, because the lesson is in the detail.

GitHub MCP, May 2025. Invariant Labs showed that a malicious issue planted in a public repository could hijack an agent connected to the official GitHub MCP server. The agent, asked to look at open issues, read the planted instructions, pulled data from the user’s private repositories and published it in a pull request on the public one. Invariant’s point was that the flaw sits outside the server code, so GitHub can’t patch it on the server side. The control has to live in the agent system: in what the agent is allowed to reach while it works.²

Asana MCP, June 2025. A bug in Asana’s MCP server could expose one customer’s project data to users in other accounts. Asana said plainly that it wasn’t a hack. It took the server offline the same day, and the server stayed down for about two weeks.³

Salesloft Drift, August 2025. Attackers used compromised OAuth tokens from the Salesloft Drift integration to export data from numerous corporate Salesforce instances, then combed the exports for further credentials, AWS keys and Snowflake tokens among them. Mandiant’s advice afterwards included reviewing integrations for overly permissive scopes, such as full access, and avoiding them.⁴

Postmark-MCP, September 2025. An npm package impersonating Postmark’s MCP server added a single line that blind-copied every email it sent to an address the attacker controlled. Koi Security, which found it, described it as the first malicious MCP server seen in the wild. It had been downloaded 1,643 times before it was removed.⁵

None of them needed a novel exploit

Strip off the brand names and look at the mechanisms. A poisoned piece of text the agent was asked to read. A bug in how one tenant was separated from another. Tokens with broad scopes, stolen from one connected app. A fake package installed by name from a public registry.

All of it is old. What the four share is that an agent or an integration held access, and nothing checked, at the moment of the call, whether that access should be used for this request, by this caller, against this system.

The token was the whole of the policy.

That’s the gap to close, and it sits in one place: between the agent and the tool.

One front door

The pattern the better-run programs are adopting is simple to describe. Whatever agent your people use, ChatGPT, Claude, Gemini, Copilot or one you built yourselves, it reaches your systems through one gateway. Salesforce, NetSuite, Snowflake and your homegrown APIs sit behind it. Every agent-to-tool call goes through that one door.

Four controls live in that gateway, and each one answers one of the incidents.

Allow-listing. Only approved MCP servers are reachable. A developer can still paste a server into a local config, but the call goes nowhere unless the server is on the list. That’s the direct answer to Postmark-MCP.

Identity at call time. The agent acts as the person asking, with that person’s permissions, decided when the call is made. The alternative is a shared bearer token or an API key in a config file, which turns every call from every user into the same caller with the same reach.

An agent can still be fooled by poisoned text with identity at call time in place. What changes is the reach: a fooled agent can do only what the person in front of it was already allowed to do.

Least-privilege scopes. Grant each connection the narrowest scope that does the job. Full access is never the default. That’s the Salesloft Drift lesson, in Mandiant’s own terms.

Every call logged. Which agent, which tool, whose identity, which system, and what came back. When something goes wrong, the log is the difference between knowing what was exposed and estimating it.

What Gartner says, and where it hedges

Gartner’s guidance on MCP, from May 2026, lands in the same place. Its authors advise making an MCP gateway the control plane for all agent-to-tool interactions, standardizing on governed remote MCP servers, and establishing an enterprise registry of the MCP servers you allow.⁶

A fair reader will raise the counterpoint, so here it is. An earlier Gartner document on MCP security prefers self-hosted MCP servers to remote ones.⁷ A CISO may quote that back at anyone selling a hosted gateway, and it’s a reasonable position.

The argument holds either way. The four controls are about identity, scope, allow-listing and logging, and each works the same wherever the server runs. A self-hosted MCP server behind a gateway still needs an allow-list, still needs the caller’s identity, still needs narrow scopes and still needs every call recorded. Put the servers wherever your risk team is comfortable. Put the gateway in front of them either way.

Where to start

Start with an inventory: every agent, and every MCP server sitting in every developer’s configuration. You will find more than you expect, and the survey above suggests your confidence about the count is the first thing to discard.

Then route agent-to-tool traffic through one gateway, and turn on the allow-list first. It’s the cheapest control to apply and the one that stops the most obvious class of attack. Scopes and identity follow, connection by connection. Logging comes with the gateway, which is the point of having one.

The same principle runs through the rest of the three-layer model: the control belongs between the thing that acts and the systems it reaches, and the credential never sits with the builder or the agent.

How Tray does it

On Tray, the Agent Gateway in Tray iPaaS exposes Tray’s 700+ connectors as governed MCP servers, with every call audited, so every agent reaches your systems through one front door.

Tray Helix sits on the same foundation for the apps people build with AI assistants. A Helix app never holds a secret: it reaches Salesforce, Slack or any connected system through a managed auth alias, resolved by the platform at run time, and the foundation layer keeps the credential, the identity and the audit trail in one place for both products.