Governance Policies

Governance policies allow Enterprise organizations to control which MCP servers can be downloaded and used within their teams. Policies are defined by organization Admins and Owners, evaluated at download time, and enforced through the organization’s dedicated registry subdomain.

How Policies Work

Policies operate on an enforcement-by-download model. MCP Hub controls the download point – the registry – rather than the runtime execution environment. When a member of an organization requests an MCP from the organization’s registry subdomain, the platform evaluates all active policies before serving the artifact.

If the MCP passes all policies, it is served. If any policy blocks it, the download is denied with a clear explanation of which policy was violated.

Policy Types

Allow Policies

Allow policies explicitly permit specific MCPs or categories of MCPs. They are useful for creating approved lists:

{
  "name": "Approve Database Tools",
  "action": "ALLOW",
  "target_type": "MCP",
  "target_value": "mcp-database-tools",
  "priority": 10,
  "enabled": true
}

Deny Policies

Deny policies block MCPs that do not meet specified criteria. They are the primary mechanism for security governance:

{
  "name": "Block Critical Vulnerabilities",
  "action": "DENY",
  "target_type": "SCORE",
  "target_value": "critical",
  "conditions": {"critical_max": 0},
  "priority": 10,
  "enabled": true
}

Policy Target Types

Policies can target different aspects of an MCP:

Score-Based Policies

Score-based policies are the most common type. They enforce minimum quality and security standards:

Minimum Global Score:

{
  "action": "DENY",
  "target_type": "SCORE",
  "target_value": "min:70",
  "description": "Deny MCPs with global score below 70"
}

No Critical Findings:

{
  "action": "DENY",
  "target_type": "SCORE",
  "target_value": "critical",
  "conditions": {"critical_max": 0},
  "description": "Deny MCPs with any critical security findings"
}

MCP-Specific Policies

Allow or deny specific MCPs by name:

{
  "action": "ALLOW",
  "target_type": "MCP",
  "target_value": "mcp-approved-tool",
  "description": "Explicitly allow this MCP regardless of other policies"
}

License-Based Policies

Control which licenses are acceptable:

{
  "action": "DENY",
  "target_type": "LICENSE",
  "target_value": "GPL-3.0",
  "description": "Deny MCPs with GPL-3.0 license for compatibility reasons"
}

Policy Priority and Precedence

Priority

Each policy has a priority field (integer). Lower values indicate higher priority. When multiple policies apply to the same MCP, they are evaluated in priority order.

Evaluation Rules

1. Policies are sorted by priority (lowest number first).
2. For each policy, the MCP is checked against the conditions.
3. The first matching policy determines the outcome.
4. If no policy matches, the default behavior is to allow the download.

Precedence Hierarchy

In organizations with areas and multiple scopes, policies follow a hierarchy where the most specific scope wins:

Environment (most specific) > Project > Organization (least specific)

Policies defined at the environment level override those at the project level, which in turn override organization-level policies. This allows organizations to have strict production policies while maintaining more permissive development environments.

Policy Types by Behavior

Locked policies ensure that certain security baselines cannot be weakened by project or environment-level overrides.

Policy Exceptions

In real-world enterprise environments, exceptions to policies are sometimes necessary – for emergencies, migrations, or special cases. MCP Hub supports controlled exceptions with mandatory safeguards:

Exception Requirements

Every exception must include:

1. Expiration date: Maximum 90 days from creation. Exceptions cannot be permanent.
2. Justification: A written explanation of at least 20 characters explaining why the exception is needed.
3. Approver: An Admin or Owner must approve the exception.

Creating an Exception

{
  "policy_id": "policy-uuid",
  "scope_type": "env",
  "scope_id": "production-env-uuid",
  "exception_value": {"allowed": true},
  "justification": "Emergency hotfix requires this MCP until migration to approved alternative is complete",
  "expires_at": "2026-03-15T00:00:00Z"
}

Exception Lifecycle

• Exceptions are active from creation until their expiration date or until explicitly revoked.
• Expiration alerts are sent to the creator and approver at 30, 14, 7, 3, and 1 days before expiry.
• Revocation is possible at any time by an Admin or Owner, with a reason recorded in the audit log.
• Expired or revoked exceptions are preserved in the audit trail for compliance.

Enforcement by Download

MCP Hub enforces policies at the download point, not at runtime. This is a deliberate design decision based on the principle that MCP Hub controls the registry but not the user’s execution environment.

How Enforcement Works

1. The Enterprise organization receives a dedicated registry subdomain: acme.registry.mcp-hub.info.
2. All downloads from this subdomain require authentication (valid token).
3. Before serving any artifact, the platform evaluates all active policies against the requested MCP.
4. Allowed: The artifact is served and an audit event is logged.
5. Denied: A 403 response is returned with the policy violation details, and a denial event is logged.

Shared Responsibility Model

MCP Hub provides:

• Authenticated access via tokens
• Policy evaluation at download time
• Complete audit logging of all downloads (allowed and denied)
• Dedicated subdomain per organization

The organization is responsible for:

• Configuring network egress controls (proxy, firewall, DNS) to route traffic through the dedicated subdomain
• Blocking access to the public registry domain for managed endpoints
• Managing token distribution and rotation
• Defining and maintaining policies

Limitations

Enforcement is only effective when the organization controls the network path:

• Unmanaged devices (BYOD without MDM) may bypass controls
• Previously downloaded and cached MCPs are not affected
• MCPs obtained from alternative sources (direct GitHub download, npm) are not governed

These limitations are documented and communicated during Enterprise onboarding.

CI/CD Integration

Policies can be evaluated programmatically in CI/CD pipelines using the evaluate endpoint:

POST /api/v1/ci/evaluate

{
  "org_id": "org-uuid",
  "environment": "production",
  "mcps": [
    {"name": "mcp-database-tools", "version": "commit-a3f91c2-2026-01-12"},
    {"name": "mcp-file-system", "version": "commit-x9y8z7w-2026-01-10"}
  ]
}

The response indicates pass or fail for each MCP, with details about which policy was violated:

{
  "result": "FAIL",
  "mcps": [
    {
      "name": "mcp-database-tools",
      "result": "ALLOWED",
      "global_score": 85
    },
    {
      "name": "mcp-file-system",
      "result": "DENIED",
      "global_score": 35,
      "reason": "Policy 'Require Minimum Score' denied: global score 35 < 70",
      "matched_policy": {"name": "Require Minimum Score"}
    }
  ]
}

CI/CD evaluation requires a service token with ci:org:* scope. Every evaluation generates an audit event of type CI_EVALUATION.

Audit Trail

All policy-related actions are logged in the organization audit:

• policy.created – A new policy was created
• policy.updated – A policy was modified
• policy.deleted – A policy was deleted
• mcp.accessed – An MCP download was allowed by policy
• mcp.denied – An MCP download was denied by policy

Each audit event records the actor, timestamp, IP address, and detailed metadata about the evaluation result.