Tools in an organization

Look at the picture on the left. Four agents connect directly to four services. That means sixteen connections. Each connection has its own login, its own rules for what is allowed, and its own log, if it keeps one. If an auditor asks which customer records agents read last Tuesday, you would check each of those sixteen connections.

The picture on the right shows a gateway. This is a single entry point that all agents use to reach company tools. It does three jobs in one place: it identifies the caller, decides what the caller can access, and records what happened.

Sierra built one. By its own account, in July 2026, 89% of its employees actively used its internal gateway to connect agents to 45 services¹. Its first rule is about what goes in, before any check runs: “The best way to make sure that an agent can’t do something unexpected with sensitive data is to avoid giving it that data in the first place. We therefore spent a lot of time on tool design in the gateway, deciding what is safe to expose and when.”¹ A gateway is where a company decides what its agents can see at all.

The gateway also monitors what comes back. Sierra keeps “a full audit log of data that was accessed about our customers” and blocks attempts to access sensitive data about more than one customer in the same session¹. Determining which customer a piece of data belongs to is not a free operation. So, the check runs in three passes: a deterministic step lists potential customers, a fast model narrows them down, and a slower model makes the final decision on the customer and the data’s sensitivity¹. The idea is to use the expensive model only when the cheaper steps cannot resolve the issue. Sometimes, looking across multiple customers is legitimate. Sierra allows this through a separate path, outside the agent’s session: “it happens out-of-band, requires explicit approval, and also gets added to the audit log”¹.

Cloudflare offers a similar product. Its post says that a user connecting to an MCP Server Portal first signs in through the company’s identity provider (the single sign-on service that already knows every employee), and then “Cloudflare enforces which MCP Servers the user has access to, regardless of the underlying server’s authorization policies”². Administrators “review and approve MCP servers” before users see them, and each user is shown only “the curated list of servers and tools they are authorized to use”². Its post adds that request data “was scattered across every individual server” and that “Server Portals aggregate all MCP request logs into a single place”². This is the vendor’s description of its own product, not an independent evaluation.

What does a gateway cost? Neither source provides a number, so we will reason about it. Someone must build and maintain it, and every connection now relies on it. Each additional check, like Sierra’s model passes, adds processing to calls involving sensitive data. And it only protects traffic that actually passes through it. Cloudflare’s launch post said so about its own portal, as a gap it planned to close: “Unless an MCP Server author enforces Authorization controls, users can still technically access MCPs outside of a Portal”².

Consider two jobs. First, an engineer asks an agent in chat to open a pull request. Second, a job runs every night at 2 a.m. and posts a summary of support tickets to a team channel. No one is at the keyboard for the second job. What identity should each job use?

Sierra’s answer is short: “Interactive work runs as the user. Scheduled or shared workflows run as service accounts with only the permissions they need.”¹ A service account is an identity that belongs to a job, not a person. The reasoning follows from who is present. In chat, a person asked for the work and is watching it, so the agent can do exactly what that person could do, and no more. At 2 a.m. no person is there. If the job borrowed the account of whoever built it, it would carry that person’s full access, including everything the job never needed, and would keep it after that person changes teams. A service account fixes both: it has only the permissions the job needs, and it belongs to the job.

Sierra adds one more safeguard for automations that handle customer data: “pre-authorized workflows that explicitly declare which customers and tools they’re allowed to access before they ever run”¹. The scope is written down before the job starts. A person can read it, rather than the agent deciding it while the job runs.

Identities also have to be removed. MCP has an extension for this, enterprise-managed authorization. It names the problem: when each employee authorizes each server on their own, “Offboarding requires revoking access across every service individually.”³ Under the extension, “the organization’s IT or security team manages access policies in one place”³. The client gets a special token from the company’s identity provider and exchanges it for an access token from the MCP server’s own authorization server³. Employees without permission get an error, and “the MCP client never receives a token for unauthorized servers”³. Revoking access at the identity provider takes effect “immediately across all MCP clients”³. That is what the specification describes. It says nothing about how many companies use it. Chapter 4’s section on MCP authorization covers how a single server checks a token; chapter 6’s section on whose keys follows the same question down to a single call.

A gateway is one place for control. The other is the admin console of the agent host your company already uses, such as ChatGPT or Claude. OpenAI’s workspace controls for ChatGPT offer a clear example. They separate the question into three parts: “Role access controls who can use an app. Actions controls what the app can do. Permissions controls when ChatGPT asks before using an app.”⁴ Who can use it, what it can do, and when it asks. These three axes are set independently.

The second axis, what the app can do, includes a setting for future actions. Apps gain new actions over time. An admin might have approved an app before those new actions existed. Under “New actions”, the choices are “Enable all new actions, Only enable new read actions, Disable new actions”⁴. We recommend the middle option for most companies: new read actions arrive switched on, and new write actions stay off until an admin turns them on. “Disable new actions” applies only to actions added later; “it does not disable actions that were already enabled”⁴. The third axis, when ChatGPT asks, also has a limit. “Allow all actions” lets ChatGPT act without further prompts, but only for an individual app that supports it: the option “carries elevated risk and is not offered in the standard workspace-wide selector”⁴.

The most useful sentence on that page is this one: “Provider approval, OAuth scopes, and ChatGPT action settings are separate checks. Approving a provider scope does not automatically enable a new action, and changing a future-action policy does not remove existing provider consent.”⁴ This means there are several locks in a row. Opening one does not open the next, and closing one does not close the ones behind it. A common mistake is to think you have turned something off when you only changed one of these settings.

Anthropic’s connectors for Claude add the question of whose permissions a connector uses. “Claude inherits each person’s permissions from the connected service”⁵. If a user cannot open a file in the source system, the connector cannot access it either⁵. The exception is a shared credential: “Custom connectors that use a shared credential reach whatever that credential can access.”⁵ On Team and Enterprise plans, “everyone who uses the connector reaches the service with that same credential, so use one limited to what members should access”⁶. Custom connectors also access “arbitrary services that have not been verified by Anthropic”⁶. Per-user sign-in respects each person’s limits; a shared key gives everyone the key’s limits.

Hosts can also allowlist servers. In Windsurf’s legacy Cascade agent, users can add their own MCP servers by default, but “once you allowlist even a single MCP server, all non-allowlisted servers will be blocked” for the team⁷. Patterns are anchored to the whole string “to prevent partial matches”⁷. One entry changes the team from open to closed. This is a decision you should make intentionally.

How many servers are available? In November 2025, in a post marking MCP’s first year, its maintainers wrote that over that year the number of active servers went “from just a few experimental ones to thousands”⁹. “Thousands” is their word, not a count you can check. No one reviews thousands of servers by hand within a company.

Chapter 4’s section on annotations and the registry explained what the official MCP Registry stores: metadata pointing to packages, with format checks and manual takedowns⁸. For a company, two more sentences on that page are important. First: “The metadata hosted by the MCP Registry is deliberately unopinionated. Downstream aggregators can provide curation or additional metadata such as community ratings.”⁸ The registry does not make judgments. Second: “The MCP Registry does not support private servers.”⁸ Your company’s internal servers will not be listed there at all.

So a company needs its own list. Microsoft announced in May 2025 the design of “an MCP server registry service, which allows anyone to implement public or private, up-to-date, centralized repositories for MCP server entries”¹⁰. That was an announced design. Windsurf’s documentation covers two agents: Devin Local, the default for new tabs, and the legacy Cascade agent⁷. For Devin Local, enterprise teams can replace the default Devin Desktop MCP marketplace with their own registry URLs, to control which servers their users see there⁷. Read the fine print: with several registries configured, users see “the union of all registries”⁷, so each added registry widens the list instead of narrowing it. And for the legacy Cascade agent, which has no marketplace, registries change nothing; the allowlist is the control⁷. Narrowing is the job of a list your company curates, an allowlist, or a portal like Cloudflare’s, where administrators approve servers before users see them².

1. From memory, draw the ‘before’ and ‘after’ states of a gateway. Name the three jobs it gathers in one place and two of its costs.
2. Imagine a company deploys your Studio tool server. What identity should an engineer’s chat session use when calling the server? What identity should a nightly job use? Write the nightly job’s declared scope in a single line.
3. Explain to a teammate, in three sentences, why an approved OAuth scope, a listing in a registry, and an entry on an allowlist are three different checks.