Multi-Tenant MCP Control Plane: Isolation, Quota, and Billing
I. From Single-Tenant to Multi-Tenant
In the early days of MCP adoption, the control plane typically served a single team or a single business line. One MCP gateway, one set of policies, and one audit log were sufficient to support dozens of Agents and hundreds of Skills. This single-tenant model was simple and had low operational overhead.
However, as MCP gained popularity within enterprises, the situation changed. Multiple business departments began using MCP: customer service, finance, operations, and research and development. Each department had its own Agents and Skills, different security requirements, different compliance standards, and different budget constraints. Deploying a separate control plane for each department would dramatically increase operational costs and make cross-department Skill sharing difficult.
This is precisely the problem that a multi-tenant MCP control plane solves. A single control plane infrastructure serves multiple tenants, with each tenant seeing an isolated view while sharing the same underlying gateway, policy engine, and audit system. This chapter will explore core design issues in multi-tenant architecture, including data isolation, quota management, and billing models.
II. Core Challenges of Multi-Tenancy
Designing a multi-tenant MCP control plane faces three core challenges.
The first challenge is data isolation. Tenant A’s audit logs cannot be seen by Tenant B. Policy rules configured by Tenant A cannot affect calls from Tenant B. Tenant A’s Skills cannot be called by Tenant B’s Agents unless explicitly authorized. Data isolation is the bottom line of multi-tenant architecture.
The second challenge is performance isolation. Burst traffic from one tenant should not affect normal calls from other tenants. Failures in one tenant should not spread to other tenants. Performance isolation requires resource quotas and rate limiting mechanisms.
The third challenge is billing. Multi-tenant operations need to be able to calculate costs per tenant. How many resources did each tenant use? How many calls did they generate? How much compute time did they consume? This data is the foundation for internal chargeback and cost optimization.
Peta’s multi-tenant architecture considered these three challenges from the very beginning, providing complete isolation, quota, and billing capabilities.
III. Data Isolation Design
Data isolation is the core of multi-tenant architecture. Peta adopts a multi-layer isolation strategy combining tenant identifiers and access control.
Tenant identifier
Each tenant is assigned a unique tenant identifier upon registration. This identifier permeates the entire system: Agents must declare their tenant when registering, Skills must declare their tenant when registering, and call requests must carry the tenant identifier in Context.
When the Peta gateway receives a request, it first verifies the validity of the tenant identifier. If the request does not carry a tenant identifier or the identifier is invalid, the request is rejected. This ensures that all requests are correctly attributed to a tenant.
Storage isolation
Audit logs are partitioned and stored by tenant. Each tenant can only query and export audit logs belonging to its own tenant. Peta uses the tenant identifier as a partition key, achieving physical or logical isolation at the storage layer.
Policy rules are also isolated by tenant. Policy rules configured by Tenant A only apply to Agents and Skills of Tenant A. Tenant B’s administrators cannot see Tenant A’s policy configuration.
The Skill registry is also isolated by tenant. Skills registered by Tenant A can only be called by Agents of Tenant A by default. If Tenant A wishes to share its Skills with Tenant B, this can be enabled through explicit cross-tenant authorization.
Access control
Peta’s management interface itself is also multi-tenant. Administrators of each tenant can only see their own tenant’s Agents, Skills, policies, and audit logs. Peta supports a super administrator role that can view all tenants’ data for platform operations and troubleshooting.
IV. Performance Isolation and Quota Management
Performance isolation ensures that one tenant’s load does not affect other tenants. Quota management is the primary means of achieving performance isolation.
Types of quotas
Peta supports multiple types of quotas. Call frequency quota limits the maximum number of calls per second or per minute for each tenant. Concurrency quota limits the number of simultaneous calls for each tenant. Resource quota limits the number of Agents, Skills, and policy rules each tenant can register. Storage quota limits the audit log storage space for each tenant.
Quota configuration
Administrators can configure quotas for each tenant in Peta Console. Quotas can have hard limits and soft limits. Hard limit: calls are directly rejected when the quota is exceeded. Soft limit: the system sends an alert when the quota is exceeded, but calls are still allowed.
Quotas can be set per tenant or per sub-entity within a tenant, such as setting stricter quotas for a specific Agent within a tenant.
Dynamic quota adjustment
Quotas are not static. The actual usage of a tenant changes over time. Peta supports dynamic quota adjustment. Administrators can automatically adjust quotas based on historical usage data. For example, if a tenant has used an average of 60 percent of its quota over the past month, the system can suggest lowering the quota to save costs.
Fair scheduling
When multiple tenants share the same gateway resources, a fair scheduling algorithm is needed. Peta’s gateway uses a weighted fair queue scheduling algorithm. Each tenant is assigned a weight, and tenants with higher weights receive a larger share when resources are contested. This ensures the quality of service for important tenants.
V. Billing Model Design
Operating a multi-tenant MCP control plane requires the ability to bill by tenant. Billing models can be usage-based or fixed-fee based.
Usage-based billing
Usage-based billing charges tenants based on the resources they actually consume. Billing factors include call count: each Skill call is billed once, with different Skills potentially having different unit prices. Call duration: for long-running Skills, billing is based on duration. Data transfer volume: billing is based on inbound and outbound data volume. Storage volume: billing is based on audit log storage space.
Usage-based billing is fair but requires precise metering and invoice generation.
Get Zhangshuang’s stories in your inbox
Join Medium for free to get updates from this writer.
Plan-based billing
Plan-based billing is a simpler model. Tenants pay a fixed monthly or annual fee and receive a certain amount of quota. Excess usage beyond the quota is billed additionally on a usage basis. The plan model is suitable for most enterprise scenarios, with predictable budgets.
Hybrid billing
Peta supports a hybrid billing model. Tenants can choose a base plan that includes a certain amount of call volume and storage space. Excess usage is billed on a usage basis. This model combines the advantages of both billing methods.
Invoice generation
Peta automatically extracts billing data from audit logs and generates monthly or weekly invoices. Invoices contain detailed usage for each tenant, which can be further broken down by Agent, Skill, and user. Tenant administrators can view invoices and download bills in Peta Console.
VI. Cross-Tenant Skill Sharing
The value of multi-tenancy lies not only in isolation but also in sharing. Skills developed by one tenant can be used by other tenants, avoiding duplicate development.
Peta supports a cross-tenant Skill sharing mechanism. Skill owners can publish their Skills to a shared catalog in Peta Console. Other tenants can discover and subscribe to these Skills from the shared catalog.
Calls to shared Skills are also subject to policy control. Owners can configure access policies for shared Skills, specifying which tenants can call them. The calling tenant also needs to allow its Agents to call the Skill in its own policies. Only when both sides’ policies are satisfied can the call succeed.
Cross-tenant calls are also recorded in audit logs, but the logs contain information about both the calling tenant and the Skill-owning tenant, facilitating cost allocation for both parties.
VII. Multi-Tenant Operations Practices
In actual operations, multi-tenant MCP control planes require attention to the following aspects.
Tenant lifecycle management
From tenant registration, configuration, activation, to suspension and deactivation, a complete lifecycle management process is needed. Peta provides tenant management APIs that can integrate with the enterprise’s identity management system. New tenants can register through a self-service portal and are activated after administrator approval.
Tenant monitoring
Peta provides independent monitoring dashboards for each tenant. Tenant administrators can see their own tenant’s call volume, error rate, latency distribution, and quota usage. Platform administrators can see an aggregated view of all tenants to identify anomalous tenants.
Tenant fault isolation
When a Skill in one tenant fails, it should not affect other tenants. Peta’s gateway maintains independent circuit breaker states for each tenant. Repeated failures of a Skill in Tenant A trigger circuit breaking, affecting only Tenant A’s calls, while Tenant B is unaffected.
Tenant upgrade strategy
Different tenants may wish to upgrade to newer versions of the MCP protocol or newer versions of the Peta control plane at different times. Peta supports per-tenant gradual upgrades. Platform administrators can select a subset of tenants to upgrade first, observe stability, and then upgrade other tenants.
VIII. Typical Scenario Examples
Scenario one: Intra-enterprise department isolation
A large enterprise uses Peta as a unified MCP control plane. The finance department, human resources department, and research and development department are each separate tenants. Each department has its own Agents and Skills without interfering with each other. The audit logs of the finance department can only be viewed by finance department administrators. Cross-department Skill sharing requires approval from both sides.
Scenario two: SaaS service provider
A SaaS company provides Agent services to multiple customers. Each customer is a tenant. The SaaS company deploys a single control plane on Peta to serve all customers. Each customer sees their own dedicated Agents and Skills, while sharing the same underlying infrastructure. The SaaS company bills each customer monthly based on usage.
Scenario three: Development, testing, and production environment isolation
A team uses different tenants to isolate development, testing, and production environments. The development tenant has smaller quotas and looser policies. The production tenant has larger quotas and stricter policies. The same Skill can be deployed to all three tenants with different configurations.
IX. Summary: Multi-Tenancy Is the Necessary Path for MCP Scaling
The core conclusions of this chapter can be summarized as follows.
First, as MCP becomes popular within enterprises, multi-tenant architecture becomes inevitable. A single control plane serving multiple tenants reduces operational costs and promotes Skill sharing.
Second, the core challenges of multi-tenancy include data isolation, performance isolation, and billing.
Third, data isolation is achieved through tenant identifiers, storage partitioning, and access control. Each tenant can only see its own data.
Fourth, performance isolation is achieved through quota management, including call frequency quotas, concurrency quotas, resource quotas, and storage quotas. Quotas can have hard and soft limits.
Fifth, billing models can be usage-based, plan-based, or hybrid. Peta automatically extracts billing data from audit logs and generates invoices.
Sixth, cross-tenant Skill sharing allows tenants to reuse Skills developed by other tenants, avoiding duplicate development. Sharing requires policy approval from both sides.
Seventh, multi-tenant operations require attention to tenant lifecycle management, monitoring, fault isolation, and upgrade strategies.
Multi-tenancy is the necessary path for MCP scaling. A well-designed multi-tenant architecture can maximize resource sharing and operational efficiency while ensuring isolation.
In the next chapter, we will discuss the MCP security model under zero-trust architecture, including mutual TLS and shortest path authorization.
