Structuring an AI Center of Excellence Charter
A charter must define shared infrastructure, not just decision rights and committees.
Most AI governance charters collapse because they define who has authority but not what infrastructure that authority actually governs. So you end up with a document full of titles and committees, but every department still has to build the same connections, the same permissions logic, and the same data-access rules on its own, isolated from every other team doing the exact same work.
The failure pattern is visible across most charters: a CoE that only "advises" has no way to stop any single piece of it, because advice was never going to be enough.
A charter is the founding specification for a shared capability platform that defines what infrastructure teams build and share together. Anything less produces governance theater: a document people point to in meetings but nobody checks before shipping. Two structural traps make this worse. A fully centralized model bottlenecks delivery, because every team has to wait in line behind IT for approval on things they could have shipped weeks earlier. A fully federated model does the opposite: every team builds and rebuilds the same thing, each slightly differently, until nothing matches and governance breaks down. The charter's actual job is to resolve that tension, by specifying not just who holds decision rights, but what shared infrastructure those decision rights apply to.
What a charter must define to create governance infrastructure
A charter that governs AI across a company needs three things before a single agent goes into production: precise decision rights, coverage across a fixed set of risk domains, and a published turnaround time teams can actually plan around.
Start with decision rights, because this is where most charters go soft. There's a real gap between writing "the CoE will advise on AI deployments" and writing "the CoE must approve any AI deployment that touches customer data, regulatory compliance, or systems of record before it reaches production." The first sentence is a suggestion. The second is enforceable. So the rest of the charter has to use language closer to the second kind.
Four domains need explicit coverage, because a gap in any one of them turns into organizational liability sooner or later. Skip any one of these, and the gap doesn't stay theoretical. It becomes the incident nobody saw coming because nobody owned that corner of the charter.
None of this works without a clock. Teams need to know what crosses the line into CoE review. Customer data, regulatory systems, and systems of record are the clearest tripwires, and the charter should name them directly so teams don't have to guess where the line sits.
The integration layer beneath governance commitments
A charter can get every decision right and still fail in practice if the integration layer connecting it to company systems isn't standardized. If there's no shared protocol for connecting models to company systems, every new tool and every new model becomes a fresh integration the CoE has to evaluate, approve, and monitor from scratch. Governance that has to be rebuilt for every connection is a backlog.
The Model Context Protocol (MCP) enters the picture as a structural answer to a structural problem. The MCP specification describes it as an open protocol that connects large language model applications with external data sources and tools through one standardized method, so you don't need a custom adapter for every single pairing of tool and model.
The math behind this matters more than the description. An enterprise running several models across several client environments, alongside dozens of internal services, faces what's commonly called the N×M problem: every uncoordinated integration multiplies the number of connections the CoE has to track and secure. MCP turns that multiplication into addition. If you build one server per internal system, any MCP-compatible client can use it, and that turns N×M into N+M. CData's enterprise MCP guide calls this the "missing AI layer," a standardized bridge between company systems and the fast-growing set of AI models and assistants trying to reach them.
The protocol's backing reflects more than a single company's bet. In December 2025, Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, co-founded with Block and OpenAI, and backed by AWS, Google, Microsoft, Bloomberg, and Cloudflare. A CoE charter should name MCP as the approved integration layer directly, so that every new agent deployment inherits a governed connection pattern already in place, instead of inventing a new one that someone else will have to review later.
The July 2026 specification change that removes the primary engineering objection to enterprise MCP deployment
The specification released on July 28, 2026 makes MCP stateless at the protocol layer, and people call it the largest revision since the protocol launched. That one change answers the most common engineering objection to deploying MCP at enterprise scale: that it couldn't scale horizontally without a lot of extra infrastructure work.
The _meta field changed what happens under the hood: every request now carries its own protocol version, client identity, and client capabilities inside it, so it no longer relies on a session set up earlier in the conversation. That sounds like a small technical detail, but the practical effect is large: any request can now land on any server instance sitting behind a plain round-robin load balancer, with no shared storage required to keep track of who's mid-conversation with whom. An MCP deployment's infrastructure footprint now looks like any other standard web service, so it no longer needs its own scaling plan.
Two new headers matter for anyone running a gateway. For anyone building enterprise gateway patterns, that's a real operational improvement.
A formal deprecation policy now comes with a twelve-month minimum window, so you can plan upgrades on a schedule instead of scrambling when something breaks without warning. That predictability is close to a prerequisite for any serious production governance commitment: a charter can't promise stability on top of a protocol that might change under it without notice. The charter itself should name the specification version it sanctions and commit to a review cadence that lines up with that twelve-month deprecation window, so the governance document stays in step with the protocol it depends on.
Enterprise-Managed Authorization and the gap between identity policy and runtime access
The most consequential governance development tied to this specification cycle is Enterprise-Managed Authorization (EMA), which reached stable status on June 18, 2026, ahead of the July 28 specification, and was then formally folded in as an official extension in that release. EMA moves the authorization decision out of the hands of individual employees clicking "allow" on individual servers, and puts it inside the enterprise identity provider, where the CoE can actually manage it as policy rather than hope employees make good choices one prompt at a time.
The old model had real costs. The EMA announcement describes the per-server consent prompt approach as a structural problem: manual onboarding work piling up for every new tool, security teams with no way to enforce policy once a user had clicked through a prompt, and a blurry line between personal accounts and work accounts that made audits harder than they needed to be.
If you sign in once under EMA, you get access to every approved server without further setup. The enterprise identity provider becomes the authority deciding which clients can reach which servers, and at what scope. Okta is the first named identity provider supporting EMA. Anthropic and Microsoft appear as client-side implementers, and Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase are listed as server-side implementers, with Slack listed as in progress.
A charter cannot leave out this limitation: EMA governs connection-level access. It decides whether a given user can connect a given client to a given server, and nothing more. It does not inspect MCP traffic after that token has been issued. Once an agent is inside a system, EMA has nothing left to say about what that agent actually does there. You need a separate runtime enforcement layer because a charter that treats EMA as sufficient on its own leaves a hole exactly where the company's actual risk lives. The charter needs to specify both layers by name: EMA for connection-level governance through the identity provider, and a distinct runtime policy layer for governing individual agent actions once a connection is live.
The gateway and registry pattern as the CoE's operational enforcement point
Two components turn charter language into something a CoE can actually run day to day: a registry that tells teams and agents what tools exist and have been approved, and a gateway that checks policy at runtime before any call to a downstream system goes through.
The gateway pattern routes all MCP traffic through one central point for policy enforcement, monitoring, and multi-tenant control. Teams find what's available to them through an internal portal, rather than being handed a server URL by a colleague who happened to set one up. That distinction carries real weight: a team profile is the CoE's actual approval record, written down in a system, for what that team is allowed to reach. It replaces an ad hoc chain of "ask around and someone will share the link" with something an auditor can check.
The registry needs to cover five things to do its job. It needs an inventory and discovery layer, so anyone can see what servers exist, what tools they expose, and who owns them. It needs identity tracking, so users, automated workloads, and agents each carry a distinct, preserved identity rather than blending into one generic account. It needs policy decisions recorded, so you can see who can discover and invoke each server or tool. It needs runtime enforcement, so the gateway checks policy before any downstream call runs, not after. And it needs lifecycle management, covering how a capability gets approved, updated, deprecated, rolled back, or retired without leaving old, unused routes sitting around as a security risk.
For every server, the registry should record ownership, environment, approval state, version, authentication method, and policy references. That's the metadata that turns a registry into governed infrastructure instead of a list somebody keeps in a shared drive. The official public registry at registry.modelcontextprotocol.io launched in preview on September 8, 2025, and it offers namespace verification, standardized metadata, and an API other registries can pull from. A curated, verified directory with security audits, usage data, and service-level commitments appears on the MCP 2026 roadmap as an "On the Horizon" aspiration, not a committed deliverable for any specific quarter, so a CoE building its registry today should plan around what exists now rather than what might ship later. The charter should require, in plain terms, that no MCP server reaches production without a complete registry entry and a gateway team-profile assignment attached to it.
Security constraints the charter must name rather than defer
A well-built charter names its known risks instead of discovering them after something breaks. Two constraints matter enough to spell out directly: a latency floor that rules MCP out of certain workflows, and a tool-poisoning risk that makes unrestricted server installation genuinely dangerous.
MCP carries a baseline amount of latency, which makes it a poor fit for anything happening on a latency-sensitive path, like a checkout flow or a trading system. A charter has to answer both risks with specific, written controls rather than a general promise to "take security seriously." It should require permission scoping, matching an agent's access to whatever permissions already exist in the underlying system rather than expanding beyond them just because the integration makes it technically possible. It should require least-privilege enforcement tied to each team profile. a customer-support MCP server, for example, should expose CRM read access and ticket-creation tools, and nothing resembling database administration or billing system access. And it should require that every agent action gets logged: who approved which server, when, at what scope, and exactly which calls got made while that approval was in effect. Without those records sitting somewhere auditable, a company doesn't have governance. It has a policy document and a hope that nothing goes wrong.
Department-specific MCP servers and the charter's skill-sharing commitment
A charter promises to share skills across the company, but that only means something once it produces capability other teams can actually reuse, and department-specific MCP servers are where that promise either gets kept or quietly drops.
Take RevOps as an example. Once a team connects through an MCP server, an AI assistant can handle complicated Salesforce reporting, build out pipeline reviews, and run compensation-model analysis that used to mean merging several exported Excel files by hand. The server only exposes whatever records and objects the authorized Salesforce user already has rights to see. You don't redefine permissions for the sake of the integration; you inherit them straight from the access that already existed.
Sales teams get a similar pattern through Salesloft's MCP server, launched in 2026. It's read-focused: it reads live pipeline data, deals, accounts, and call data, which lets a team ask an assistant to summarize deal health, flag accounts at risk, or pull notes from a recent call, all without jumping between separate systems to piece the picture together.
The registry connecting these servers to other teams is what makes either of them company-wide instead of team-local. A RevOps MCP server, once it's registered and approved a single time, can be discovered and reused by any other team with the right access, rather than get rebuilt from scratch by every department that happens to need something similar. That's the charter's skill-sharing commitment made literal: one approved capability, available to everyone cleared to use it.
