“Front door, bedroom door.”
At our LEAP on Tour stop in Dallas (the third of our US meetups), NextEra’s Jonathan Foster explained why every hop matters. Most networks put a strong lock on the front door. Once you’re through it, every room in the house is open. An agent that gets past the front door won’t wait to be shown around. It will try every room it can reach, which is why each hop needs its own lock.
When LEAP on Tour opened in Chicago, the questions were technical: Identity, rate limits, inventory. New York steered the conversation toward ownership and trust. Dallas, our final US stop of 2026, brought both together and showed what the work looks like inside a large, regulated enterprise.
Around the tables sat an energy utility, an insurtech, a fintech running risk profiling across a billion trades a day, a travel data provider selling its own MCP server, a heavily regulated public-sector team just getting started, and a consultant advising some of the most AI-forward companies in the market. The conversations were the sharpest of the tour. Chicago was less than two months earlier, but a few months in AI is like years used to be, and you could hear how far the questions had moved.
Here’s what Dallas taught us.
MCP is a new channel, not a new technology
Jonathan Foster is a master architect who oversees architecture governance at a large energy company, across thousands of applications and well over a thousand APIs. Last year his team ran about 80 architecture reviews. This year, they’re already at five times that.
No manual process keeps up with that, so his team built an agentic architecture governance system. A collection of tools they call the Architecture Toolkit injects standards and guardrails directly into the workflow, so anything entering review already arrives in the right shape. Building it taught him four lessons.
1. MCP is a channel, not a capability. Jonathan is comfortable in a terminal, so his first move was to write CLIs against the systems of record he needed. They worked fine, until he handed them to a colleague who asked what a terminal was. That was the moment MCP clicked. A remote MCP server packaged the same APIs and controls for people working in chat assistants. His split: Skills hold knowledge, MCP holds connectivity, and agent plugins package both.
2. Agents act with a scoped user identity. The user’s identity sets what’s possible; the agent’s scope narrows it to what’s allowed. That mattered for users with elevated rights. ServiceNow’s platform administrator was one of the stakeholders in Jonathan’s governance reviews. Since the agent would act with his admin identity, he wouldn’t use the tool until scopes guaranteed it couldn’t reach admin functions. Unattended agents, which run on a loop with no person behind them, have no user identity to borrow. Each runs under its own service account, scoped to its job and issued short-lived tokens. That’s not the shared, all-powerful account everyone starts with; every action still traces to one accountable identity that can be cut off.
3. Authorization needs centralizing as much as authentication. An agent touching three systems shouldn’t need three authorization servers and three token exchanges. His approach is one central authorization service. Some platforms, SAP and ServiceNow among them, won’t trust an outside authorization service, so those flows carry two tokens for now. Identity stays central either way. If a token escapes, you need to know exactly where to kill it.
4. Good design matters more than ever. Agents let you move fast in the right direction or the wrong one. Jonathan’s hardest work wasn’t on the agent side; it was tightening how the business specifies what it expects.
He was just as deliberate about what not to do. Because MCP is just another channel to the same API, the API’s shape carries straight through. That’s why he isn’t running his APIs through a direct API-to-MCP converter, because a poorly shaped API becomes a poorly shaped MCP server that burns more tokens. The same logic decides where MCP is governed. Mission-critical and customer-facing APIs go through an enterprise gateway whether they’re called over HTTP or MCP, and that gateway has to run anywhere, because his estate is multi-cloud, on-prem and even air-gapped. The rule underneath it all: One control plane, with data planes wherever the business needs them. As he put it, it’s APIs all the way down.
Start where mistakes can be fixed
We asked each table where agents and MCP are earning their keep today. The room spanned the whole adoption curve, and the pattern was the same at every stage: Prove value where an error is cheap, then move closer to the business.
At the start of that curve, a heavily regulated public-sector team is just bringing in Copilot and building a custom chat app. Their first question was the right one: Where is the one central point of authentication and authorization?
Jonathan is further along internally, and his approach is to try everything and see what works. His teams use ChatGPT Enterprise, Claude Code, Microsoft 365 Copilot as the low-code layer, and custom chat interfaces on internal systems. Many of those tools still reach internal systems through connectors that call existing APIs directly, and MCP is starting to take over that role. Not all of it stuck; they opened Claude Code up beyond engineering, then pulled it back because of the noise. His own governance agents delivered value in the first week, running on a laptop. Customer-facing work is a different story. Nobody thinks about their electric utility until the lights go off, and when they do, the information has to be right. So agents stay well away from customers, and from the operational technology that runs the grid.
The fintech is furthest in, rolling out 130 agents into production. Their view is that wins on the IT side are easy to show early, but on the business side the real value only appears in production. That’s when their clients, major exchanges and market data providers among them, saw what agent-driven risk modeling could deliver. They’re seeing it operationally too; agents automatically resolve 27% of business operations tickets in production with no human intervention, and 41% of IT tickets in pre-production.
What breaks first isn’t the protocol
Our second question asked what’s holding each organization back, whether the API strategy, the models, MCP itself, or something else. The answers came down to three things: Process, permissions, and cost.
Process. When Jonathan’s team tried to automate its own governance process, the first question was what the process actually was. Everyone did it differently. Agents expose undocumented process fast.
Permission debt. The insurtech wanted to connect an agent to its Microsoft estate and found three months of SharePoint permission cleanup waiting first. For Jonathan, connecting a large ERP system meant custom code just to delegate permissions to the right groups, even for a few selected areas.
Cost. A consultant working with some of the most AI-forward companies described how their worries have shifted. At first it was risk, so they built committees and review boards. Now, it’s cost. Leadership told teams to use AI without limits, engineers ran top-tier models on pay-per-token plans, and then the bills arrived. Some engineers were running dozens of agents in parallel as personal software factories, and nobody could say what they were producing. The insurtech saw the same swing: Executives went from “everybody use it” to tracking the top ten users and asking where the value was. The fix isn’t cutting back but getting smarter, teaching teams which model fits which job, and caching answers that don’t need to be generated twice.
The travel data provider sees cost from the seller’s side. They sell airlines an MCP server for booking, ticket changes, and check-in. The server is cheap to run, but the paid APIs behind it aren’t. One simple destination question can cost 13 cents, across half a million users a month. And airlines budget per passenger, not per token, so the provider prices by the session instead. Another attendee’s advice: If plain code can do the job, don’t send it to an LLM.
At scale, you need one place to say no
The fintech brought the hardest problem in the room. They’re rolling out 130 agents into production, at volumes on the scale of a major stock exchange, and a single trade can touch anywhere from 100 to 2,000 systems. In pre-production, everything looked fine. In production, the sheer number of business scenarios overwhelmed the agents, and they had to pull some back.
That’s the moment Jonathan was describing. Authentication tells you who an agent is acting for. What matters even more now is a single authorization service that decides what each agent can do, and gives you one place to shut it down when something goes wrong. If a token escapes or an agent misbehaves, you need to know exactly where to kill it. With dozens of authorization servers, you don’t.
Who owns it
Jonathan gave the clearest definition of MCP governance we heard on the LEAP tour:
- Discovery. Register every API and MCP server, whatever its tier, in a single place where people and agents can find it.
- Access. One service issues tokens, with coarse-grained control at the front door.
- Ownership. Know who owns each service and where it is in its lifecycle.
- Enforcement. Not just the decision, but the point where it’s applied.
- Observability. When something goes out of spec, you can see it and act.
In Jonathan’s model, the owners of each system of record own its APIs and its MCP servers. The identity team runs the central authorization service, approving every new client and every new scope. That gate can be too tight, too. At first, the team approving requests didn’t yet understand delegated access, so they said no to everything and legitimate use cases stalled.
The insurtech had the opposite problem. They handed out access freely at the start and are now catching up. A cross-functional committee covering security, legal, audit, data, and infrastructure approves access through a documented workflow, with SOC 2 in mind and escalation to the C-suite only when needed. The fintech puts accountability on its Chief Business Officer, with technical stakeholders signing off underneath.
That echoed New York, where a panelist argued governance needs one person ultimately accountable. Dallas agreed, with a caveat: The accountable leader still depends on expertise from below. And whether it’s built in-house, bought from a vendor or run by a third party, every MCP server still needs to be governed and controlled. One attendee’s networking, security, and compliance teams review every vendor MCP server before it’s deployed. After that, every call to it should still pass through your own gateway, under your own identity and authorization rules.
Three cities, one answer
Chicago asked how to govern MCP. New York asked who should own it. Dallas showed both answers working inside a real, regulated enterprise.
The answer is the same in all three cities. MCP is an API with a different shape, so govern it like one:
- Give every agent a scoped identity, separate from the client.
- Centralize authorization, not just authentication.
- Run everything through one control plane.
- Put a named owner behind every server.
The conversation doesn’t stop here. About 160 people registered for LEAP on Tour across the US, and we’re starting monthly virtual office hours to keep it going. We’ve planned the first session for the week of December 7, so watch for the invite on LinkedIn.
In the meantime, one stop remains in 2026. LEAP on Tour arrives in Paris on Monday, November 30, at the Nest Hotel Paris La Défense. Join us in Paris and bring your hardest questions.
