"We tested MCP and even deployed an internal server, but our internal approval for company-wide adoption is stalled." Inquiries like this from heads of IT and security departments have surged over the past two months. Behind this lies a major turning point: Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation in December 2025.
Co-founded by Anthropic, Block, and OpenAI—with Google, Microsoft, AWS, Cloudflare, and Bloomberg joining as supporting members—the AAIF elevated MCP from a single-company initiative to an industry standard. While this officially made MCP a viable candidate for enterprise projects, it also created an urgent need for comprehensive governance design.
Why governance design became the central issue
Previously, MCP was treated primarily as an extension of personal development run on Claude Desktop. Following its transition to the AAIF, however, the landscape changed:
- Proliferation of multi-vendor MCP servers: Official MCP servers from Salesforce, Zendesk, SAP, and others are launching in rapid succession
- Security concerns regarding rogue MCP servers: Some MCP servers published on GitHub go as far as allowing arbitrary shell execution
- Ambiguous permission boundaries: Cases where actions executed by AI agents via MCP cannot be audited to see whose authority was used or what was modified
The fact that we covered Cloudflare's bot defense using AI Labyrinth reflects growing industry-wide caution regarding AI agents crossing security boundaries. Ignoring this in enterprise projects will inevitably result in rejections from legal, the IT team, and frontline departments alike.
The five layers of MCP governance
Here, we share the framework our team uses when supporting clients with MCP governance design. We organize the key discussion points across the following five layers:
Layer 1: Vendor and source selection
We classify where MCP servers originate using three tiers:
| Classification | Examples | Approval process |
|---|---|---|
| Official (Tier 1) | Official releases from Salesforce, Slack, Notion, Google, etc. | Streamlined IT team review is sufficient |
| AAIF certified (Tier 2) | Listed in the AAIF catalog | Security team checklist applied |
| Rogue / internal implementation (Tier 3) | GitHub open source, custom internal development | Full review (code audit, vulnerability scan, PoC) |
The key is not to outright ban Tier 3, but rather to establish that it may be used as long as defined processes are followed. A blanket ban on external community tools stifles innovation on the front lines.
Layer 2: Authentication and permissions
MCP server invocations must manage permissions based on agents rather than human users.
- Issue a dedicated service account for each agent
- Restrict permissions through a two-tiered model using OAuth scopes and RBAC
- Mandate human approval (HITL) for access to sensitive data
Applying the same philosophy seen in Lyft's integration of HITL into AI coding to MCP invocations is the most practical approach.
Layer 3: Audit logging
Record who, what, when, and with what outcome at the MCP protocol level.
audit_log:
trace_id: <UUID>
agent_id: <agent>
user_id: <user_on_behalf>
mcp_server: <server_name>
tool_called: <tool>
arguments: <hash> # PII を含む場合はハッシュ化
result_summary: <truncated>
timestamp: <ISO 8601>
policy_evaluations: [<rule_id>: pass/fail]The crucial point is logging not just what was called, but also why it was authorized. This ensures auditors can later reconstruct whether a specific access request was legitimate.
Layer 4: Cost and usage limits
AI invocations routed through MCP servers are classic examples of unpredictable usage-based billing. Implementing the following standard guardrails is essential:
- Monthly token limits per agent
- Maximum token thresholds per request
- Anomaly detection (automatic shutdown if daily usage spikes over 5x compared to the previous day)
Layer 5: Sunset and replacement planning
Because the AAIF ecosystem evolves rapidly, incorporate a biannual review process to evaluate whether to continue using each server right from the start. Adopting tools without sunset schedules accumulates technical debt, leaving systems frozen in place three years down the line.
Seven questions you must ask during vendor selection
When client companies evaluate external MCP servers or MCP platforms (hub services such as homula), we always recommend running through this checklist:
- Has the vendor obtained AAIF Tier certification?
- Do they hold SOC 2 Type II or ISO 27001 certifications?
- Can data storage regions be restricted exclusively to Japan?
- Can logs be forwarded directly to the customer's tenant for incident response?
- What is the guaranteed support timeline for protocol backward compatibility?
- Are caps on pricing models (call volume, tokens, seats) explicitly clearly defined?
- Is there data export support in a reconstructible format in the event of vendor offboarding?
If a vendor cannot answer all seven questions promptly, it is safest to remove them from consideration for enterprise deployments.
Governance should not end once established
The most commonly overlooked aspect of MCP governance is ongoing operations after deployment. Because the AAIF moves quickly, governance is never finished once a policy is written. Establishing an operational cycle to periodically review vendor Tier certification status, support deadlines, and actual usage patterns from day one is the critical factor in preventing long-term operational breakdowns. To keep Layer 5 (sunset and replacement planning) from becoming a mere formality, formalize review schedules in contracts and internal procedures.
Summary — MCP shifts from "whether to use it" to "how to sustain it"
The transition to the AAIF has made MCP an essential consideration in enterprise technology selection. At the same time, adopting MCP without proper governance design will inevitably collapse within three years.
If you have experimented with MCP but cannot secure internal approval for company-wide rollout, or if you need to build a vendor comparison framework, please reach out through our inquiry form.
