The hard part of an MCP gateway is auth

Sierra's Mihai Parparita published field notes on building the company's internal MCP gateway, and the framing is the most honest thing in it: MCP is "ancient" technology by AI-industry standards, so wiring agents to internal systems should have been straightforward, and instead it became "another engineering iceberg". The tip above the waterline is the part that demos well: 89% of Sierra employees now connect agents to 45 different services from a single page. The mass underneath is auth.

It's the best field report on internal agent platforms this year, and every team standing up an agent gateway should read it before writing a line of code. But walk the seven lessons in order and a pattern shows up. The expensive ones are barely about MCP at all. They're about identity, scopes, consent, and audit. Enterprise software has worked on those four for twenty years, and agents have made all four urgent again at once, in a context where the old answers do not transfer cleanly.

We are not watching from the outside. WorkOS runs Horizon, an internal agent platform with its own shared MCP surface, and hit the same wall from the same direction. This is a reading of Sierra's post, not a lecture at it.

The spec left the gateway undefined, and everyone is filling the gap privately

Back in March we went through MCP's 2026 roadmap and flagged gateway and proxy patterns as an open area: authorization propagation, session semantics, and visibility boundaries were all unspecified. The conclusion then was that without specification-level guidance, every enterprise ends up inventing its own gateway behavior.

Sierra's post is what that looks like from inside a company that did it well. It is a field report on the gap, not a counterexample to it.

The part that looked hard was the part that wasn't

Sierra's context lives in Slack, GitHub, Salesforce, the data warehouse, production systems, internal docs, and dozens of other SaaS products. Connecting an agent to all of that is real work, and the write-up is refreshingly candid about how much of it turned out to be integration grind rather than protocol design: dozens of tools per official MCP server that didn't match how employees actually worked, a REST extension mechanism to patch the gaps, sidecar processes, one service instance per region.

None of that is what gated the rollout. What gated the rollout was being able to turn it on safely. Sierra says the access-control and audit system underneath the gateway is what ultimately made the gateway possible, and what gave legal and compliance the confidence to roll it out across the company.

That is the whole argument. The gateway was a feature. The authorization model was the product.

"An agent can't misuse what it never sees" is an authorization model

Lesson 3 is the strongest section in the post, and it starts from exactly the right premise: the safest way to stop an agent doing something unexpected with sensitive data is to never hand it the data. The motivating nightmare is cross-customer bleed, an agent reading one customer's internal operating procedures and "helpfully" reusing them for another.

Note where the difficulty actually sits. Sierra's production systems were already partitioned by customer identity; the gateway's problem was the gray-area sources (Slack channels, internal documents, ad hoc analytics) that carry no sensitivity or provenance metadata at all. So they built a multi-pass classifier: a deterministic phase proposes candidate customers, a fast model narrows the list, a slower model decides which customer the data is about and how sensitive it is, all of it feeding an audit log that blocks touching two customers' sensitive data in one session. Cross-customer access is still possible for incident work, but out-of-band, explicitly approved, and logged.

The classifier is genuinely theirs. Inferring tenancy from unstructured internal data is a data-classification problem, and nobody sells that for your Slack.

Everything wrapped around it is standard equipment. Identity reaching every tool call, permissions checked per tool rather than per server, queries filtered by organization, an audit event on every meaningful call: that's per-tool MCP authorization, where getSession() hands a tool the user's ID, org, role, and permissions, and workos.auditLogs.createEvent() records what it touched. Cloudflare's demo MCP server gates a single tool behind a single named permission assigned in AuthKit, so the tool visibly disappears from the agent's list when the caller's role doesn't carry it. That is "an agent can't misuse what it never sees," implemented as a permission check instead of a policy document.

The reason those audit events have to be their own thing, rather than a log line, is the subject of a separate argument: you can sample 1% of requests for performance monitoring, and you cannot sample 1% of agent actions for an auditor.

And the out-of-band approval for cross-customer work lands in the same place as session-scoped authorization: access bounded to one task, expiring with the session, unrenewable by the agent, requiring a human to explicitly approve a new one. The shapes match closely enough to be worth noticing, with one difference in reach. Pipes MCP applies that control to third-party OAuth connections like Snowflake, Drive and Salesforce, where Sierra applied their own version to internal data sources. Same control, different surface.

Lesson 7 is the one the industry keeps relearning

Sierra's identity rules of thumb: interactive work runs as the user; scheduled or shared workflows run as service accounts holding only the permissions they need. The reasoning is worth quoting to anyone still shipping agents on a personal API key. A recurring automation that inherits one employee's broad access either breaks when that person changes roles, or worse, quietly keeps running with their access. For automations touching customer data Sierra went further, with pre-authorized workflows declaring up front which customers and tools they may reach.

This is correct, and it is also the spec for the agent identity AuthKit ships. An agent gets its own registered identity rather than borrowing a human's. You choose whether agents may exist unclaimed at all, or must bind to a user before they can act. An unclaimed agent runs read-only until a human vouches for it, and full permissions wait for that moment. When a person does vouch, the credential the agent gets back carries an act claim naming who authorized it, so every downstream call is attributable to a real human rather than a shared bot account someone has to reverse-engineer mid-incident. The token itself encodes sub, org_id, and act, so your API never has to take an agent's word for who it's acting on behalf of.

The scheduled half of Sierra's rule has its own answer, and it is the harder one. A nightly job runs at 6am when there is no session, no browser, and nobody present to consent. The pattern there is a durable connected account rather than a session: the user's authorization outlives any login, the worker pulls a per-connection credential using nothing but an API key and the user ID it is acting for, and every pull emits an audit event with actor.type: 'agent'. Worth being straight about the tradeoff, because that post is: scopes there are whatever the provider granted at connect time, not per task. If the Drive scope is broad, a confused agent reads broadly. That is exactly the gap session-scoped authorization is for, which is why the two models are complements rather than alternatives.

The discovery side is standardized too. An unauthenticated call returns a WWW-Authenticate header pointing at protected-resource metadata, which points at authorization-server metadata carrying the agent registration and claim endpoints. There's even a generated auth.md: onboarding instructions written for an agent rather than a person, with the curl commands for your environment already filled in.

"Don't fight the weights" means auth outlives the gateway

Lesson 6 is where the gateway abstraction cracks, and Sierra is honest about it. GitHub's full MCP server made agents burn context discovering hundreds of tools and choke on large responses, so they handed agents the gh CLI instead, because the models already know it cold. They made the same call for AWS, preferring the aws CLI over proxying it.

Then look at what that required. Sierra wanted every write and destructive operation tied to user intent and approval, so the compromise was minting a separate GitHub token scoped to read-only access on specific repositories, handed to the agent for its CLI calls.

That is an authorization server issuing narrowly-scoped credentials to a non-human principal, which is the exact responsibility... and the controls have to live somewhere the proxy cannot reach.

Lesson 4 pushes the same direction from another angle: 80% of a workflow rounds down to 0% of the value, so the gateway had to reach 100% coverage through REST extensions, sidecars, and per-region instances. Every one of those escape hatches is another credential surface, and each hand-built extension is a fresh place for a long-lived secret to end up.

What the cottage industry is actually building

There's a growing market of MCP gateway products, and the pitch is usually consolidation: one place to connect agents to everything. Sierra's post is the clearest evidence yet that consolidation is the easy half. The hard half is a list every enterprise identity team would recognize:

‍

That last row used to say Dynamic Client Registration, and it is worth saying why it doesn't any more. The MCP 2026-07-28 spec deprecated DCR in favor of Client ID Metadata Documents, keeping DCR only for backward compatibility. A CIMD client ID is a self-hosted HTTPS URL any authorization server can resolve, where DCR credentials are keyed to the server that issued them. If you are building the client-identity layer of a gateway this quarter, build the one the spec is moving to.

Sierra was right to build one gateway rather than seven, and right that permissioning, auditing, and legal review should happen once instead of once per team. The scope of "once" is the open question. Sierra solved it once for Sierra. The rest of the industry is solving it once per company, in parallel, from scratch.

Buy the underwater half

The closing line of Sierra's post is that the gateway became plumbing, with the complexity staying below the waterline unless you're the one building it. That's the correct end state, and it's the correct end state for auth too. Nobody wants to think about token exchange while investigating an outage.

The difference is who maintains the plumbing. Sierra built an identity, permission, consent, and audit layer, and then inherited the job of keeping it alive: every new SaaS connection, every new escape hatch, every new client, every service owner they onboarded to spread the load. That work compounds, and it compounds on the team least likely to have spare capacity.

If you're standing up an internal agent gateway this quarter, budget for the fact that the connectors are the demo and the authorization model is the project. Build the part that's specific to you. Sierra's customer classifier is a good example of work nobody could have sold them. Buy the part that's specific to nobody: an authorization server that speaks OAuth to MCP clients, agent identities distinct from human ones, permissions checked per tool, and an audit log your compliance team already trusts.

The iceberg is not an argument against building. It is an argument against every company rebuilding the same submerged mass in parallel.