FairByDesign — Operational AI Governance Series

Field Signal

Model Context Protocol, or MCP, is mostly discussed as an integration breakthrough. That is accurate, but incomplete.

Anthropic introduced MCP on November 25, 2024 as an open standard for connecting AI applications to the systems where data lives — files, databases, APIs, developer tools, internal systems, external services — without every system needing a custom connector. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a Linux Foundation directed fund co-founded with Block and OpenAI. Anthropic and the MCP project report more than 10,000 active public MCP servers and adoption across ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, and other platforms.

That solves a real engineering problem.

It also creates a governance problem.

Once AI systems can connect to tools, APIs, databases, files, workflows, identity systems, codebases, and external services, governance stops being a policy conversation and becomes an operational architecture problem.

MCP is not the governance layer.

It is the tool-and-context connection layer that exposes the missing governance layer.

The Argument

MCP may become one of the most important operational surfaces in AI governance, because it sits close to the moment where model output can become system action.

This does not mean MCP is bad. It also does not mean MCP should be treated as a compliance framework. That would be the wrong category. MCP is a protocol layer. It standardizes connection. Governance has to decide what those connections are allowed to do, under what conditions, with what evidence, and with whose authority.

The distinction matters.

A model that only generates text creates one kind of risk. A model that can call tools, access live data, send messages, alter records, generate tickets, initiate workflows, or trigger downstream automation creates a different risk surface. OWASP’s LLM Top 10 (2025) already names this shift through risks such as prompt injection (LLM01), improper output handling (LLM05), sensitive information disclosure (LLM02), and excessive agency (LLM06). OWASP defines excessive agency as the condition where an LLM-enabled system can perform damaging actions because it has too much functionality, too many permissions, or too much autonomy relative to the task. In late 2025 OWASP went further and published a separate OWASP Top 10 for Agentic Applications (2026) specifically for systems that plan, decide, and act across tools.

That is the MCP governance issue in plain sight.

The more standardized the connection layer becomes, the more urgent the control layer becomes.

The Governance Problem

The governance problem is not simply that MCP connects AI to tools. The problem is that connection changes the nature of accountability.

Before tool use, the central question is often whether the model output is accurate, biased, misleading, unsafe, or overtrusted. After tool use, the question expands: what action path can the system enter?

That question has already appeared across the emerging governance and security literature around agentic AI. NIST’s AI Risk Management Framework treats AI risk as a lifecycle-wide govern, map, measure, and manage problem, not a one-time approval event. NIST’s Generative AI Profile (NIST AI 600-1) adds that generative AI risk management has to account for deployment context, monitoring, provenance, testing, and misuse. The Cloud Security Alliance’s proposed Agentic Profile for the NIST AI RMF goes further, calling for autonomy-tier classification, tool-use risk modeling, action-consequence mapping, runtime behavioral metrics, delegation-chain monitoring, and structured incident response for agent compromise and drift.

That is the same direction MCP pushes organizations.

Once AI systems are connected to tools, governance has to move from abstract approval into runtime control. The organization must know what the agent can reach, what it can trigger, what it can change, what it can expose, and who can stop it.

Emerging agentic AI research makes the same point in more technical language. These are proposed architectures rather than settled standards, but they point in a consistent direction. The AAGATE paper proposes a Kubernetes-native governance control plane for agentic AI because traditional application security tooling is not enough for autonomous, language-model-driven agents in production. The MI9 runtime governance paper argues that agentic systems capable of reasoning, planning, and executing actions create governance challenges that pre-deployment review cannot fully anticipate. A 2025 survey on autonomy-induced security risks in large-model agents identifies tool misuse, irreversible tool chains, memory poisoning, and action-layer fragility as risks that emerge when agents move beyond static inference into dynamic environments.

This is why MCP should not be treated as mere plumbing.

Plumbing determines where power can flow.

The Five-Question Accountability Test

When MCP is introduced into an AI workflow, governance teams should not begin with a policy slogan. They should begin with five operational questions.

First, what can the AI system reach? The organization needs a clear inventory of MCP servers, connected tools, data sources, file systems, APIs, repositories, messaging systems, and workflow systems. NIST AI RMF already emphasizes inventory, roles, and system context. MCP makes that inventory harder to ignore, because the connection layer becomes a map of possible access.

Second, what can the AI system do? Reading a file is different from writing to a database. Summarizing a ticket is different from closing it. Drafting an email is different from sending it. Suggesting a workflow action is different from triggering it. OWASP’s excessive agency category forces teams to ask whether the system has more functionality or permission than it needs.

Third, what requires approval before action? Not every tool call should be treated equally. Low-impact retrieval does not need the same friction as record modification, payment routing, customer communication, code deployment, security containment, or HR workflow influence. The governance layer has to define approval gates around consequential actions.

Fourth, what evidence is captured? A serious AI workflow should preserve enough evidence to reconstruct what happened later: system identity, tool call, prompt or instruction context, source data, user identity, authorization state, output, action taken, reviewer decision, override, escalation, timestamp, and downstream result. NIST’s Generative AI Profile and AI RMF both support this evidence-centered posture through their emphasis on monitoring, measurement, documentation, and lifecycle risk management.

Fifth, who can stop the workflow?

Human oversight is not the presence of a human somewhere near the system. Under the EU AI Act, human oversight for high-risk AI systems is expected to enable people to understand limitations, monitor operation, avoid overreliance, interpret outputs, and intervene where necessary. For connected AI systems, that intervention requirement has to become operational: pause, revoke, roll back, escalate, or disable access.

These questions are not decorative. They are the difference between MCP as integration plumbing and MCP as a governable operational surface.

A starting control matrix

MCP capability	Governance risk	Required control
Read files / databases	Sensitive data exposure	Scoped access, source logging, data minimization
Send email / update ticket	AI output becomes external action	Approval gate, human reviewer, immutable log
Modify records / trigger workflow	Irreversible or consequential action	Step-up authorization, rollback plan, stop authority

Three rows are enough to start. The point is to tie each capability to a named risk and a required control before the connection goes live, not after an incident.

Why Existing Answers Are Not Enough

Most AI governance programs were built around models, vendors, risk assessments, policy documents, acceptable-use rules, and periodic reviews. Those still matter. But they do not fully answer the MCP problem.

MCP shifts attention from model behavior alone to connection-mediated action.

A model can be acceptable in isolation and dangerous in context. A tool can be safe for humans and unsafe for unconstrained agent use. A permission can be reasonable for a user and excessive for an AI workflow. A log can prove that a request happened while still failing to show why it happened, what context shaped it, who authorized it, and whether the action should have been allowed.

This is why agentic AI governance work increasingly focuses on runtime governance, control planes, telemetry, action constraints, authorization monitoring, and containment. The emerging literature is not saying “write better principles.” It is saying the governance problem has moved into the system boundary where reasoning, tools, identity, permissions, and action meet.

MCP lives directly at that boundary.

FairByDesign Reframe

The FairByDesign position is simple:

MCP connects systems. Governance controls action.

That sentence is the whole argument.

MCP should be understood as an operational surface, not as a governance answer. It gives AI systems a standardized way to reach context and tools. That makes it useful. It also makes it consequential. The fact that MCP’s stewardship moved to a neutral foundation in late 2025 reinforces that the protocol is converging on shared infrastructure — but protocol stewardship is not the same thing as workflow accountability. Open-source governance of the MCP protocol and enterprise governance of MCP-enabled AI actions are different governance objects. The differentiator for an organization is no longer connection. It is control.

The governance layer around MCP should include identity, permissions, approval gates, logging, audit trails, human stop authority, escalation rules, and evidence that governance actually happened.

This is where AI governance has to mature.

Not just model cards. Not just principles. Not just approval checklists. Not just “human in the loop” as a comfort phrase.

The mature version is a control architecture around the action path.

Control Translation

For organizations already experimenting with MCP or MCP-like tool connections, the practical translation is clear.

• Start with an MCP connection inventory. List every MCP server, tool, resource, prompt, data source, identity boundary, and downstream system. Treat undocumented MCP servers as shadow infrastructure.
• Classify tool actions by consequence. Separate read-only retrieval, low-risk drafting, internal workflow preparation, external communication, record modification, financial action, security action, code action, and legally consequential action.
• Apply least privilege. The MCP server should not inherit broad permissions just because the user or host environment has them. Scopes should be narrow, role-based, auditable, and revocable.
• Create approval gates. Any MCP-mediated action that changes records, sends external communication, modifies production systems, affects access, influences employment, touches money, or changes security posture should have explicit review rules.
• Capture evidence. Logs should not merely show that a tool was called. They should preserve who or what initiated the call, what context shaped it, what tool was invoked, what parameters were used, what output returned, whether a human approved it, whether the action executed, and what happened next.
• Design human stop authority. A human must be able to pause the workflow, revoke access, escalate suspicious behavior, disable a tool, roll back a change where possible, and preserve evidence for review.
• Test adversarially. Prompt injection, tool poisoning, excessive agency, improper output handling, and sensitive data disclosure are not theoretical categories. They should be tested as part of MCP deployment readiness.

Evidence Notes

The strongest existing support for this argument comes from five overlapping bodies of work.

The first is the MCP documentation itself, which frames MCP as an open protocol for integrating LLM applications with external tools and data sources. That supports the claim that MCP is a connection layer, not a governance framework.

The second is OWASP’s LLM Top 10 (2025) — especially prompt injection, improper output handling, sensitive information disclosure, and excessive agency — plus the separate OWASP Top 10 for Agentic Applications (2026). These support the claim that tool-connected LLM systems require action-path controls.

The third is NIST AI RMF and NIST’s Generative AI Profile, which support lifecycle governance, context-aware risk management, monitoring, documentation, testing, and management of generative AI risks.

The fourth is emerging agentic AI governance research — AAGATE, MI9, and the Cloud Security Alliance’s proposed Agentic AI RMF profile. These are proposed architectures and preprints, not settled industry consensus, but they point consistently toward the same shift: from static governance to runtime governance, control planes, autonomy classification, tool-use risk modeling, and containment.

The fifth is broader agent policy work from organizations such as the World Economic Forum and Partnership on AI, which emphasize that AI agents require evaluation, governance, oversight, and review mechanisms because they can act across software environments and decision contexts.

These sources do not all use the same vocabulary. Some say “agentic AI.” Some say “tool use.” Some say “runtime governance.” Some say “excessive agency.” Some say “control plane.” MCP adds a specific protocol layer to that larger discussion. The conclusion is the same: once AI systems can act through tools, governance has to become operational.

Institutional Question

The institutional question is no longer whether an organization has an AI policy.

The sharper question is this:

Can the organization prove that an AI-mediated action was authorized, bounded, logged, reviewable, reversible where possible, and owned by an accountable human role?

If the answer is no, the system may be connected, but it is not governable.

Series Bridge

This piece sits inside the FairByDesign operational AI governance series because MCP makes the central FairByDesign problem harder to avoid.

AI governance is moving from policy language into systems control.

Agent  →  Action  →  Control  →  Oversight

MCP strengthens the “Agent → Action” side of that chain. The next governance frontier is building the “Control → Oversight” side with equal seriousness.

Subscribe / Support

FairByDesign develops public-interest research on AI governance, operational readiness, human oversight, and accountability infrastructure for live AI systems. If this work is useful, subscribe to the Mercury Brief, support the research, or share it with someone building or governing AI systems before the plumbing becomes invisible.

Insight

MCP is not the governance layer; it is the operational surface where governance has to become real.

FAQ

Is MCP itself an AI governance framework?

No. MCP is a protocol for connecting AI applications to external tools, systems, and data sources. Governance has to be built around how those connections are authorized, constrained, monitored, logged, reviewed, and stopped.

Why does MCP matter for AI governance?

Because it standardizes the connection between AI systems and external tools. Once a model can access tools or trigger workflows, governance must address action-path control, not only model evaluation.

What is the main risk of MCP?

The risk is not MCP alone. It is deploying MCP-enabled systems without identity controls, least privilege, approval gates, tool-use logging, audit trails, escalation paths, and human stop authority.

What should organizations do before deploying MCP?

Inventory MCP servers and tools, classify action consequences, restrict permissions, define approval gates, log tool calls with context, test prompt injection and excessive agency risks, and assign human authority to pause or revoke access.

How does this relate to agentic AI?

Agentic AI systems reason, plan, use tools, and act across workflows. MCP can be part of the infrastructure that enables that tool use, which makes it relevant to agent governance, runtime control, and accountability design.

References

Anthropic. (2024, November 25). Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol

Anthropic. (2025, December 9). Donating the Model Context Protocol and establishing the Agentic AI Foundation. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation

Cloud Security Alliance AI Safety Initiative. (2025). NIST AI Risk Management Framework: Agentic Profile [Proposed profile]. Retrieved June 4, 2026, from https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/

European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. https://eur-lex.europa.eu/eli/reg/2024/1689/oj

Huang, K., Lambros, K. R., Huang, J., Mehmood, Y., Atta, H., Beck, J., Narajala, V. S., Baig, M. Z., Ul Haq, M. A., Shahzad, N., & Gupta, B. (2025). AAGATE: A NIST AI RMF-aligned governance platform for agentic AI [Preprint]. arXiv. https://arxiv.org/abs/2510.25863

Model Context Protocol. (2025). Specification. https://modelcontextprotocol.io/specification/

National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). https://www.nist.gov/itl/ai-risk-management-framework

National Institute of Standards and Technology. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

OWASP. (2025). OWASP Top 10 for Large Language Model Applications. https://owasp.org/www-project-top-10-for-large-language-model-applications/

OWASP GenAI Security Project. (2025). OWASP Top 10 for Agentic Applications for 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

Partnership on AI. (2025). AI agents & global governance. https://partnershiponai.org/wp-content/uploads/2025/09/agents-policy-analysis.pdf

Su, H., Luo, J., Liu, C., Yang, X., Zhang, Y., Dong, Y., & Zhu, J. (2025). A survey on autonomy-induced security risks in large model-based agents [Preprint]. arXiv. https://arxiv.org/abs/2506.23844

Wang, C. L., Singhal, T., Kelkar, A., & Tuo, J. (2025). MI9 — Agent Intelligence Protocol: Runtime governance for agentic AI systems [Preprint]. arXiv. https://arxiv.org/abs/2508.03858

World Economic Forum. (2025). AI agents in action: Foundations for evaluation and governance. https://reports.weforum.org/docs/WEF_AI_Agents_in_Action_Foundations_for_Evaluation_and_Governance_2025.pdf