MCP Governance · Operating model
The MCP Operating Model: Roles, Ownership and Decision Rights
Most MCP governance failures are not technical. They are two teams each believing the other owns tool risk, and a third discovering in an audit that nobody did.
The short answer
An MCP operating model assigns each recurring governance decision to a named role: who approves a new server, who classifies tool risk, who authorises a high-consequence action, who owns policy, who answers audit questions, and who decides when an agent is switched off. Seven roles and eight decisions cover almost every estate; the failure mode is not a missing role but a decision two teams both believe the other owns. The test of an operating model is not its diagram. It is whether an engineer at 2am knows who to wake, and whether that person has the authority to act.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸Eight decisions recur in every estate. Each needs exactly one accountable owner, and the common failure is two owners rather than none.
- ▸Seven roles are sufficient: platform owner, server owner, tool risk assessor, policy owner, approver, evidence owner, and agent owner.
- ▸The most frequently unowned decision is tool risk classification, because it sits between security (who has the method) and engineering (who has the context).
- ▸Approval authority must match consequence. An approver who cannot personally absorb the consequence of the action is a signature, not a control.
- ▸Maturity progresses in four stages, and the trigger to advance is always operational pain rather than an initiative: unowned servers, then approval fatigue, then audit pressure, then cross-team routing conflict.
Source: Mark Alex, Real Biz Digital — The MCP Operating Model: Roles, Ownership and Decision Rights (https://realbizdigital.net/insights/mcp-operating-model/). Reproduce with attribution.
Key takeaways
- 01Write the eight decisions down with a name against each. A model expressed as team names rather than roles fails the 2am test.
- 02Give tool risk classification to security as method owner and engineering as context provider, with security accountable. Ambiguity here propagates into every policy rule.
- 03Make the agent owner a real role. Somebody must be accountable for what an autonomous system does, and “the platform team” is not an answer an auditor accepts.
- 04Delegate approval downward as risk classes mature. Central approval of everything is a bottleneck that teaches teams to route around governance.
- 05Keep the standing meeting count at three, with a decision log. Governance forums without decision logs regenerate the same discussion monthly.
- 06Expect the model to change at each maturity stage. An operating model designed for forty servers is wrong for five, and vice versa.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is an MCP operating model?
- The assignment of each recurring MCP governance decision — server approval, risk classification, policy ownership, action approval, evidence, agent accountability — to a single named role with the authority to make it.
- Who should own MCP governance overall?
- One platform or AI infrastructure team owns the estate, the registry and the policy repository. Security owns risk method and the evidence obligation. Business owners retain accountability for their own agents.
- Which decision is most often unowned?
- Tool risk classification. Security has the method, engineering has the context, and both assume the other holds the pen.
- Who should approve high-consequence agent actions?
- Whoever would be accountable if a human had taken the action. If a refund above a threshold needs a supervisor, the agent’s refund needs the same supervisor, not a platform engineer.
- Do we need an AI governance committee?
- Only if it makes decisions. A forum that reviews and advises but cannot approve or refuse adds latency without adding control.
- How many standing meetings does this need?
- Three: a weekly estate operations review, a fortnightly risk and policy review, and a monthly governance decision forum with a written decision log.
- When should the operating model change?
- At each maturity transition, and the trigger is always operational pain: unowned servers, approval fatigue, audit pressure, then routing conflict between teams.
The eight decisions that need an owner
Start with decisions, not with an organisation chart. The chart follows.
Key facts
- ▸Decision four is the one that most often sits with the wrong role. Platform engineers frequently approve business actions because they built the queue, which places consequence-bearing decisions with people who cannot bear the consequence.
- ▸Decision eight needs a documented override. If only the agent owner can stop an agent and the agent owner is unreachable, security must be able to act, and everyone must know that in advance rather than during an incident.
- ▸Decision two is the one that determines whether policy stays maintainable, because classification is what lets rules be written against classes rather than tool names.
| Decision | Frequency | Accountable | Consulted |
|---|---|---|---|
| Approve a new MCP server into the estate | Weekly | Platform owner | Security, data owner, requesting team |
| Classify a tool’s risk | On intake and on schema change | Security (method) | Server owner (context) |
| Own and merge policy changes | Continuous | Policy owner | Tool owners, security |
| Approve an individual high-consequence action | Continuous | Business approver for that domain | — |
| Grant an agent access to a capability | Monthly | Agent owner + platform owner jointly | Security |
| Decide retention and evidence obligations | Quarterly | Evidence owner (GRC) | Security, legal, platform |
| Decommission a server or capability | Monthly | Platform owner | Server owner, dependent teams |
| Suspend or shut down an agent | Rare, urgent | Agent owner, with security override | Platform on-call |
Print this table with real names in the accountable column. If any cell contains two names or a team rather than a person, that is the next gap to close.
Seven roles, with remits that do not overlap
- Platform owner
- Owns the estate as an asset: registry, intake, detection, decommissioning, capacity. Accountable for the answer to “what do we have and who owns each part”. Usually a platform or AI infrastructure engineering lead.
- Server owner
- One named human per MCP server. Accountable for its availability, schema stability, credential rotation and eventual retirement. Without this role, servers become permanent and unpatchable.
- Tool risk assessor
- Applies the classification method to each tool and reclassifies on schema change. Security owns the method; engineering supplies context. Accountability sits with security so that method drift has an owner.
- Policy owner
- Owns the policy repository, the review gate and the promotion pipeline. Accountable for policy health metrics — deny rate, approval queue depth, stale rules. Typically one senior platform engineer with security sign-off rights.
- Business approver
- Approves individual high-consequence actions within a domain, matched to existing human authority levels. Finance approves payments, support supervisors approve refunds, infrastructure leads approve destructive operations.
- Evidence owner
- Accountable for the completeness and integrity of decision records, retention schedules and audit responses. Usually GRC, working with platform to define what is captured.
- Agent owner
- One named human per agent, accountable for what the agent does. This is the role most estates lack, and its absence is what makes incident post-mortems circular.
- ›Agent owner — “the platform team owns the agents”
- ›Server owner — “the team that built it owns it” (which team, after a reorg?)
- ›Evidence owner — assumed to be whoever the auditor emails
- ›Tool risk assessor — assumed to be automatic
- ›Post-mortems with no accountable party, and agents that persist after their purpose ends
- ›Unpatched servers with year-old credentials and no retirement path
- ›Audit findings discovered rather than anticipated
- ›Policy written against tool names, and unmaintainable within two quarters
Seven roles does not mean seven people. In a mid-size estate one engineer holds platform owner and policy owner, security holds risk assessor, and business approvers already exist under other names. The point is that each remit is claimed.
A RACI matrix you can adapt in an afternoon
R = responsible for doing, A = accountable for the outcome, C = consulted, I = informed. One A per row, without exception; that constraint is the entire value of the exercise.
| Activity | Platform | Security | Server owner | Agent owner | GRC |
|---|---|---|---|---|---|
| Server intake and approval | A/R | C | R | I | I |
| Tool risk classification | C | A/R | C | I | I |
| Policy authoring | A/R | C | C | C | I |
| Policy approval for high-risk classes | R | A | I | I | C |
| Credential rotation | C | C | A/R | I | I |
| Action approval (high consequence) | I | I | I | C | I |
| Agent capability grant | R | C | I | A | I |
| Evidence retention definition | C | C | I | I | A/R |
| Audit response | R | C | C | C | A |
| Incident containment | R | A | C | C | I |
| Agent suspension | R | A (override) | I | A (primary) | I |
| Decommissioning | A/R | I | C | C | I |
Two rows deliberately break the one-A rule and it is worth understanding why. Agent suspension has a primary owner and a security override, because the alternative — a single owner who might be unreachable — is worse than the ambiguity. Document the escalation order explicitly rather than pretending there is one owner.
Four maturity stages, and the pain that triggers each
Estates do not advance because of an initiative. They advance because something specific starts hurting. Recognising the pain tells you which stage you are actually in, regardless of what the strategy deck says.
| Stage | Pain that triggers the next stage | First move |
|---|---|---|
| Ad hoc | An unowned server breaks, or a credential leaks, and nobody can say what depends on it | Detection sweep, then a named owner per server |
| Inventoried | Approval fatigue: everything routes to two people who become the bottleneck | Risk classes, so routine actions stop needing approval |
| Governed | Audit pressure: a request for who authorised what, twelve months ago | Tamper-evident decision records and an evidence pack process |
| Optimised | Cross-team routing conflict: two teams want the same capability governed differently | Routebooks and per-team policy overlays on a shared class model |
A common mistake is designing the operating model for the stage you aspire to. An estate of five servers governed with a three-committee model produces theatre; an estate of eighty governed by one engineer’s judgement produces findings.
Three meetings that earn their place
Governance forums multiply easily and justify themselves poorly. These three each produce a decision, and any meeting that does not produce a decision should be a report instead.
Estate operations review
Platform and server owners. New intakes, detection findings, credential age exceptions, dead tools, servers due for review. Output: a ticket per finding, with an owner and a date.
Skip when there are no findings. A meeting that runs when there is nothing to decide trains attendees to disengage.
Risk and policy review
Security, policy owner, platform. New and reclassified tools, policy changes awaiting promotion, shadow-mode diffs, approval queue metrics. Output: promote, revise or reject, recorded against the commit.
This is where the policy health metrics get looked at. Without this meeting they get published and ignored.
Governance decision forum
Adds GRC, agent owners and a business sponsor. Capability grants, retention changes, exceptions with expiry, incidents and their remediation. Output: a written decision log, published.
The decision log is the deliverable. Twelve months of it answers most audit questions before they are asked.
One rule keeps all three honest: every meeting output is a decision with an owner and a date, recorded where a future auditor or successor can find it. Discussions without that shape belong in a document, not a calendar.
Three ownership patterns that reliably fail
Mistake
The committee that advises
A cross-functional forum reviews servers and policies but has no authority to approve or refuse. Teams present, receive comments, then proceed regardless. Latency is added; control is not.
Instead: Give the forum specific approval rights over a defined set of decisions, or convert it into a report. Advisory bodies in governance paths produce delay and false assurance in equal measure.
Mistake
Shared ownership of risk classification
Security and engineering both consulted, neither accountable. Classifications are inconsistent, drift after schema changes, and every policy conversation reopens the question.
Instead: One accountable owner — security — with a documented method and a mandatory consultation step with the server owner. Inconsistent-but-owned beats consistent-in-theory.
Mistake
Platform engineers approving business actions
The approval queue was built by platform, so platform staff approve refunds and payments. They cannot judge whether the action is correct and cannot absorb the consequence if it is not.
Instead: Route approvals to the human who holds equivalent authority for manual actions. If no such human exists, the action should not be automated yet.
Next step
Give every server and every agent a name against it
Barzel Central Gateway makes the ownership record operational rather than documentary: owner per server, risk class per tool, policy owner on every rule, and approval routing to the role that actually holds the authority.
What an operating model cannot fix
Organisational design has real limits and it is worth naming them before someone expects a diagram to resolve a disagreement.
- 01It cannot create authority that does not exist. If nobody in the organisation can refuse a business unit’s agent, writing a role description does not change that.
- 02It cannot substitute for capacity. A policy owner with no time is a bottleneck with a title, and the resulting queue is indistinguishable from having no policy owner at all.
- 03It cannot survive a reorganisation unattended. Ownership records need refreshing whenever teams change, which is exactly when nobody has time to do it — so put it on the reorganisation checklist rather than trusting memory.
Frequently asked questions
What is an MCP operating model?
The assignment of every recurring MCP governance decision — server approval, tool risk classification, policy ownership, action approval, capability grants, retention, decommissioning and agent suspension — to a single named role with the authority to make it, plus the forums where those decisions are recorded.
Who should own MCP governance in an enterprise?
One platform or AI infrastructure team owns the estate, registry and policy repository. Security owns the risk classification method and the enforcement position. GRC owns evidence and retention. Business owners remain accountable for their own agents and for approving high-consequence actions in their domain.
Which MCP governance decision is most often unowned?
Tool risk classification. Security owns the method but lacks the context for each tool; engineering has the context but not the method. Both assume the other holds the pen, and the resulting inconsistency propagates into every policy rule written against those classes.
Who should approve high-consequence AI agent actions?
The person who would be accountable if a human had taken the action. If a refund above a threshold requires a support supervisor manually, the agent’s refund requires the same supervisor — not a platform engineer, who can neither judge correctness nor absorb the consequence.
Do we need an AI governance committee for MCP?
Only if it holds real decision rights. A forum that reviews and advises without the authority to approve or refuse adds latency and false assurance without adding control. Either grant it specific approval rights or replace it with a written report.
What is the agent owner role and why does it matter?
One named human accountable for what a specific agent does — its purpose, its capability grants, its suspension, and its eventual retirement. Estates without this role produce circular incident post-mortems and keep agents running long after their purpose has ended.
How many standing governance meetings are needed?
Three: a thirty-minute weekly estate operations review, a forty-five-minute fortnightly risk and policy review, and a monthly governance decision forum with a published decision log. Each must produce decisions with owners and dates; anything else should be a report.
What are the maturity stages of MCP governance?
Four: ad hoc, where teams connect servers directly with personal credentials; inventoried, where a registry with owners and risk classes exists; governed, where policy is versioned, tested and evidenced; and optimised, where routebooks, change impact analysis, capacity forecasting and delegated approval are in place.
What triggers progression between maturity stages?
Operational pain rather than strategy. An unowned server breaking moves you from ad hoc to inventoried; approval fatigue moves you to governed; audit pressure forces tamper-evident evidence; and cross-team routing conflict pushes you to optimised.
Should approvals be centralised or delegated?
Centralised initially for lack of an alternative, then delegated by risk class as classification matures. Central approval of everything becomes a bottleneck that teaches teams to route around governance, which is a worse outcome than delegated approval with clear ceilings.
How should agent suspension authority be structured?
Give the agent owner primary authority and security a documented override, with an explicit escalation order. A single owner who might be unreachable during an incident is more dangerous than the small ambiguity of a dual path, provided the order is written down in advance.
How does the operating model relate to policy as code?
Directly: the policy owner role exists to own the repository, the review gate and the promotion pipeline, and to be accountable for policy health metrics. Policy as code without a named owner produces a repository that only grows, because nobody has the standing to delete a rule.
Glossary
- Operating model
- The assignment of recurring decisions to accountable roles, together with the forums in which those decisions are made and recorded.
- Decision right
- The authority to make a specific decision without requiring another party’s approval.
- Accountable owner
- The single named person answerable for a decision’s outcome, distinct from those responsible for executing it.
- Agent owner
- The named human accountable for a specific agent’s purpose, capabilities and behaviour.
- Server owner
- The named human accountable for one MCP server’s availability, schema, credentials and retirement.
- Policy owner
- The role owning the policy repository, its review gate and its health metrics.
- Evidence owner
- The role accountable for completeness, integrity and retention of decision records, and for audit responses.
- Approval delegation
- Distributing approval authority to domain owners by risk class, rather than centralising all approvals.
- Decision log
- A published record of governance decisions with owner and date, which answers most audit questions pre-emptively.
- Security override
- A documented secondary authority to act — typically to suspend an agent — when the primary owner is unavailable.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · ISACACOBIT 2019 Framework ↗Governance and management objectives, including segregation of duties.
- 02 · AxelosITIL 4 — change enablement ↗Established change-management vocabulary this article borrows for MCP estates.
- 03 · NISTNIST AI Risk Management Framework ↗Govern-map-measure-manage; the vocabulary most enterprise AI risk programmes are written against.
- 04 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
- 05 · ISOISO/IEC 27001 — Information security management ↗The ISMS baseline that agent-layer controls have to fit inside rather than beside.
- 06 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
- 07 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 08 · Center for Internet SecurityCIS Critical Security Controls ↗Control 1 and 2 — inventory of assets and software — restated here for MCP servers and tools.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). The MCP Operating Model: Roles, Ownership and Decision Rights. Real Biz Digital. https://realbizdigital.net/insights/mcp-operating-model/
Try the mechanics on a live server
To watch a real tools/list response, and see how much surface one server exposes, before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel Central Gateway is this layer, sold as a running product
Twenty-five tools covering identity-aware policy, tool routing, risk scoring, approvals, routebooks, workflow simulation and SIEM evidence. Ten policy inputs, six enforcement outcomes, per-user OAuth/OIDC. The Community tier is free, so an evaluation costs an afternoon rather than a purchase order.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Community | Free | 1,000 tool calls/mo · full policy engine, registry, routing, audit | Evaluating the estate, or one team proving the path works |
| Starter | $10/mo | 10,000 calls/mo · everything in Community | One or two production agents against a handful of servers |
| Team | $79/mo | 100,000 calls/mo · routebooks, simulation, change impact | A platform team governing an estate of 5–20 servers |
| Business | $149/mo | 250,000 calls/mo · estate-wide evidence export | Multi-team governance with SIEM obligations |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.