Most MCP server tutorials start the same way: install the server, connect Claude, and start talking to your game engine. That works perfectly for a solo developer on their own machine. It stops working the moment you add a second person.

MCP server security in 2026 is a topic that matters because the Model Context Protocol has moved from experimental curiosity to production infrastructure. Studios with 5, 10, 20+ developers are using MCP servers to accelerate their Unreal Engine and Blender workflows. Our Unreal MCP Server and Blender MCP Server are running in team environments every day. And the security questions that seemed academic a year ago are now operational concerns.

This guide covers everything you need to deploy MCP servers securely for a team-based game development studio: authentication, authorization, network architecture, scaling, monitoring, and the practical details that security documentation usually glosses over.

Why MCP Server Security Matters for Game Studios

Before diving into implementation, let's establish why this matters specifically for game development teams.

The Stakes Are Real

An MCP server connected to Unreal Engine or Blender has the ability to:

• Read and modify any project file the engine has access to. This includes source code, assets, configuration files, and build outputs.
• Execute editor commands that can delete, overwrite, or corrupt project data. A misconfigured tool call can undo hours of work.
• Access file system paths beyond the project directory if permissions aren't properly scoped.
• Expose intellectual property if the server communicates over unsecured networks. Game concepts, proprietary systems, and pre-announcement content are valuable targets.

In a solo environment, these risks are mitigated by the fact that the only person who can issue commands is you, and your undo history is immediately available. In a team environment, multiple people are issuing commands, potentially simultaneously, against shared or interconnected project instances.

The NeighborJack Vulnerability: A Wake-Up Call

In late 2025, security researchers demonstrated the "NeighborJack" vulnerability class affecting MCP servers. The core issue: many MCP servers bind to 0.0.0.0 (all network interfaces) by default, rather than 127.0.0.1 (localhost only). This means any device on the same network can connect to the MCP server without authentication.

In a home office, this might mean your phone or smart TV could theoretically send commands to your Unreal Engine instance. Annoying but low-risk.

In a studio environment with shared WiFi, this means any machine on the network — including a compromised machine, a visitor's laptop, or a device on an adjacent network if subnetting is poor — could send commands to any exposed MCP server. Given that MCP servers can modify project files and execute editor commands, the impact of unauthorized access is significant.

The NeighborJack disclosure was a catalyst for the security improvements in MCP 1.0, and it's a concrete example of why "it works on my machine" security posture doesn't survive contact with team deployment.

What Goes Wrong Without Proper Security

Based on what we've seen in studios deploying our tools, the most common problems without security measures are:

Accidental cross-project interference. Developer A connects to Developer B's MCP server instance by mistake and modifies the wrong project. In a small studio sharing a network, this happens more often than you'd expect.

Unrestricted tool access. An environment artist accidentally executes a Blueprint modification command that breaks gameplay logic. Or a programmer modifies material settings that an artist has been carefully tuning. Without role-based permissions, every connected user has access to every tool.

No audit trail. When something breaks, nobody knows who issued the command that caused it. Without logging, debugging team issues becomes "ask everyone what they did in the last hour."

Credential exposure. API keys for AI services (Claude API keys, OpenAI keys) are shared via Slack or email because there's no centralized credential management. One compromised key affects the entire team's budget.

MCP 1.0 Security Features

The MCP 1.0 specification, finalized in early 2026, includes security features specifically designed for team and production deployments. Let's understand what's available before implementing it.

OAuth 2.1 Authentication

MCP 1.0 supports OAuth 2.1 as its authentication framework. This is a significant upgrade from the pre-1.0 approach of "trust anything that connects to the socket."

What OAuth 2.1 provides:

• User identity verification. Each developer authenticates with their own credentials before accessing the MCP server. The server knows who is issuing each command.
• Token-based access. After authentication, the client receives a time-limited access token. If a token is compromised, it expires automatically. Tokens can be revoked without changing passwords.
• PKCE (Proof Key for Code Exchange). Prevents authorization code interception attacks, which is particularly relevant when MCP clients run on developer workstations that may have other software monitoring network traffic.
• Refresh token rotation. Long-lived sessions use rotating refresh tokens, so a stolen refresh token can only be used once before it's invalidated.

What this means in practice: Each developer on your team has their own MCP credentials. When they connect Claude (or another AI assistant) to the MCP server, they authenticate first. The server logs which user issued each command. If someone leaves the team, you revoke their credentials without affecting anyone else.

Per-Tool Scopes

MCP 1.0 introduces scope-based authorization for individual tools. This means you can grant different users access to different subsets of the server's capabilities.

For our Unreal MCP Server with its 207 tools across 34 categories, this enables role-based access control:

Environment Artist scope: Access to tools in the Materials, Lighting, Landscape, Foliage, and Scene Management categories. No access to Blueprint tools, Build tools, or Project Settings tools.

Level Designer scope: Access to tools in the Actor Placement, Scene Management, Landscape, and PCG (Procedural Content Generation) categories. Read access to Materials (for previewing) but no write access to material instances.

Gameplay Programmer scope: Full access to Blueprint tools, Actor Components, Gameplay Framework tools, and Debug tools. Read access to scene tools but limited write access to prevent accidental scene modifications.

Technical Director scope: Full access to all tools. This is the "admin" role for someone who needs to configure project settings, build configurations, and platform-specific features.

QA scope: Access to Debug tools, Scene Inspection tools, and Build tools (for packaging test builds). No write access to any content creation tools.

The granularity is at the tool category level by default, with the ability to define custom scopes that include or exclude specific individual tools.

Session Management

MCP 1.0 sessions are tracked server-side, providing:

• Concurrent session limits. Prevent a single user from opening excessive connections.
• Session timeout. Inactive sessions expire after a configurable period (default: 30 minutes for our servers).
• Forced disconnect. Administrators can terminate any active session.
• Session metadata. Each session records the connected user, client type, connection time, and last activity timestamp.

Deploying StraySpark MCP Servers for a Team

Let's get practical. Here's how to deploy our MCP servers for a team of 5-20 developers, step by step.

Architecture Overview

The recommended architecture for a team deployment has these components:

[Developer Workstations]
    |
    | (HTTPS/WSS, authenticated)
    |
[MCP Gateway / Reverse Proxy]
    |
    ├── [Unreal MCP Server Instance Pool]
    |       ├── Instance 1 (Project A - Dev Environment)
    |       ├── Instance 2 (Project A - Staging Environment)
    |       └── Instance 3 (Project B - Dev Environment)
    |
    ├── [Blender MCP Server Instance Pool]
    |       ├── Instance 1 (shared render farm node)
    |       └── Instance 2 (shared render farm node)
    |
    ├── [Auth Service (OAuth 2.1)]
    |
    └── [Audit Log Collector]

Each component serves a specific purpose:

Developer workstations run the AI assistant (Claude, Cursor, etc.) with MCP client configuration pointing to the gateway, not directly to individual server instances.

The MCP Gateway is a reverse proxy that handles TLS termination, authentication, routing to the correct server instance, and load balancing. This is the only component exposed to the studio network.

MCP Server instances run on dedicated machines or VMs, each connected to a specific Unreal Engine or Blender instance. They bind to localhost only and are only accessible through the gateway.

The Auth Service manages user credentials, issues OAuth tokens, and enforces scope-based permissions.

The Audit Log Collector receives structured logs from all MCP server instances and stores them for review.

Step 1: Network Architecture

Rule #1: Never expose MCP servers to the public internet.

This sounds obvious, but it needs to be stated explicitly because default configurations and quick-start tutorials often result in services being more exposed than intended.

Your MCP servers should be on an isolated network segment, accessible only from within your studio network (or VPN for remote workers). The specific implementation depends on your network infrastructure:

Small studio (5-10 people, single office):

1. Create a dedicated VLAN for development infrastructure.
2. MCP servers and the gateway run on this VLAN.
3. Developer workstations are routed to this VLAN through the office switch/router.
4. The VLAN has no route to the public internet. MCP servers don't need internet access to function — they communicate with local Unreal/Blender instances.
5. If developers need remote access (work from home), use a VPN that provides access to the development VLAN.

Medium studio (10-20 people, possibly multiple offices or remote workers):

1. Deploy the MCP gateway behind your existing corporate VPN or zero-trust network.
2. Use your identity provider (Okta, Azure AD, Google Workspace) as the OAuth identity source.
3. MCP server instances run on your internal infrastructure (physical servers, internal VMs, or private cloud instances).
4. All traffic between the gateway and MCP servers is encrypted and authenticated.

Fully remote team:

1. Deploy the MCP gateway on a private cloud instance (AWS, GCP, Azure) within a private VPC.
2. No public IP on the MCP servers or gateway. Access exclusively through VPN or cloud-provider's zero-trust connectivity (AWS Client VPN, Google BeyondCorp, etc.).
3. Each developer connects to the VPN, which provides access to the MCP gateway.
4. The gateway authenticates each connection and routes to the appropriate MCP server instance.

Regardless of your setup, verify with a port scan that MCP server ports are not reachable from outside your intended network boundary.

Step 2: Authentication Setup

Configuring OAuth 2.1 for StraySpark MCP Servers:

Our MCP servers support OAuth 2.1 authentication out of the box. The configuration requires setting up an authorization server (which can be a lightweight standalone service or integration with your existing identity provider).

Option A: Standalone auth with our built-in provider

For teams without an existing identity provider, our MCP servers include a lightweight OAuth provider that manages users locally:

Configuration file (mcp-auth-config.json):

{
  "auth": {
    "enabled": true,
    "provider": "local",
    "token_expiry_minutes": 60,
    "refresh_token_expiry_days": 7,
    "pkce_required": true,
    "max_concurrent_sessions_per_user": 3
  },
  "users": [
    {
      "username": "alex.env_artist",
      "role": "environment_artist",
      "scopes": ["materials:read", "materials:write", "lighting:read", "lighting:write", "landscape:read", "landscape:write", "foliage:read", "foliage:write", "scene:read", "scene:write"]
    },
    {
      "username": "jordan.programmer",
      "role": "gameplay_programmer",
      "scopes": ["blueprints:read", "blueprints:write", "actor_components:read", "actor_components:write", "gameplay:read", "gameplay:write", "debug:read", "debug:write", "scene:read"]
    },
    {
      "username": "sam.lead",
      "role": "tech_director",
      "scopes": ["*"]
    }
  ]
}

Each user gets a unique password (generated and distributed securely — never via Slack or email). When they connect their MCP client, they authenticate with their credentials and receive a scoped token.

Option B: Integration with existing identity provider

For teams using Okta, Azure AD, Google Workspace, or another OAuth 2.1-compatible identity provider:

{
  "auth": {
    "enabled": true,
    "provider": "external",
    "issuer_url": "https://your-org.okta.com/oauth2/default",
    "client_id": "your-mcp-client-id",
    "audience": "mcp-server",
    "pkce_required": true,
    "scope_mapping": {
      "group:env-artists": ["materials:*", "lighting:*", "landscape:*", "foliage:*", "scene:*"],
      "group:programmers": ["blueprints:*", "actor_components:*", "gameplay:*", "debug:*", "scene:read"],
      "group:leads": ["*"]
    }
  }
}

This approach maps your existing organizational groups to MCP scopes. When a developer authenticates, their group membership determines which tools they can access. No separate user management needed — when someone joins or leaves the team, updating their group membership in your identity provider automatically updates their MCP access.

Step 3: Per-Tool Permission Configuration

With authentication in place, let's configure granular permissions for each role. This is where the security model directly addresses the practical problems we described earlier.

Understanding tool categories in our servers:

The Unreal MCP Server organizes its 207 tools into 34 categories. Each category represents a functional area of the engine:

• Actor Management: Spawn, delete, move, transform actors
• Blueprints: Create, modify, compile Blueprint assets
• Materials: Create and edit materials and material instances
• Lighting: Place and configure lights, adjust global illumination settings
• Landscape: Terrain tools, sculpting, painting
• Foliage: Foliage instance management (integrates with our Procedural Placement Tool)
• Build: Package, cook, build lighting
• Project Settings: Engine configuration, platform settings
• Debug: Logging, performance stats, console commands
• Scene Management: Level loading, streaming, World Partition configuration

Similarly, the Blender MCP Server organizes its 212 tools into 22 categories covering modeling, sculpting, materials, animation, rendering, and scene management.

Defining role-based permission sets:

Here's a complete role configuration for a 10-person studio with three distinct roles:

Environment Artists (4 people):

Allowed categories (Unreal MCP Server):
  - Materials (read/write)
  - Lighting (read/write)
  - Landscape (read/write)
  - Foliage (read/write)
  - Actor Management (read/write, restricted to Static Mesh and Foliage actor types)
  - Scene Management (read only)
  - Rendering (read/write for viewport settings)

Allowed categories (Blender MCP Server):
  - Modeling (read/write)
  - Sculpting (read/write)
  - Materials (read/write)
  - UV Mapping (read/write)
  - Export (read/write, restricted to FBX and glTF formats)
  - Scene Management (read/write)

Denied categories:
  - Blueprints (Unreal)
  - Project Settings (Unreal)
  - Build (Unreal)
  - Scripting (Blender)

Gameplay Programmers (3 people):

Allowed categories (Unreal MCP Server):
  - Blueprints (read/write)
  - Actor Components (read/write)
  - Gameplay Framework (read/write)
  - Debug (read/write)
  - Actor Management (read/write, all actor types)
  - Scene Management (read/write)
  - Build (read/write for development builds only)

Denied categories:
  - Materials (write) — can read to inspect but not modify
  - Lighting (write)
  - Landscape (write)
  - Project Settings (write) — read only

Tech Lead / Director (1 person):

Allowed categories:
  - All categories (read/write)
  - Project Settings (read/write)
  - Build (read/write, all configurations)
  - Admin tools (user session management, audit log access)

QA (2 people):

Allowed categories (Unreal MCP Server):
  - Debug (read/write)
  - Scene Management (read only)
  - Build (read only — can view build status, cannot initiate builds)
  - Actor Management (read only — inspect scenes without modifying)

Denied categories:
  - All write operations on content creation tools

This configuration ensures that:

• Artists can't accidentally break gameplay logic
• Programmers can't override carefully tuned material settings
• QA can inspect everything but modify nothing
• Only the tech lead can change project-wide settings
• Everyone has the tools they need for their actual work

Step 4: Audit Logging

Every MCP tool invocation should be logged with sufficient detail to understand what happened, who did it, and when.

What to log for each tool call:

{
  "timestamp": "2026-03-24T14:32:07.445Z",
  "session_id": "sess_a1b2c3d4",
  "user": "alex.env_artist",
  "client_ip": "10.0.1.45",
  "tool": "create_material_instance",
  "category": "materials",
  "parameters": {
    "parent_material": "/Game/Materials/M_Stone_Base",
    "instance_name": "MI_Stone_Weathered_03",
    "parameter_overrides": {
      "roughness": 0.85,
      "color_tint": [0.72, 0.68, 0.62, 1.0]
    }
  },
  "result": "success",
  "execution_time_ms": 127,
  "undo_action_id": "undo_x7y8z9"
}

Why the undo_action_id matters: In Unreal Engine, operations go through the transaction system and can be undone. Linking each logged action to its undo ID means that if something goes wrong, you can identify the exact command to undo without rolling back everything that happened after it.

Log retention and storage:

For a 10-person studio with moderate MCP usage (each person averaging 50-100 tool calls per day), you'll generate approximately 500-1,000 log entries per day. At roughly 1KB per entry, that's about 1MB per day or 365MB per year. This is trivially small — store everything.

For larger studios or heavier usage, consider:

• Rolling 90-day retention for detailed logs
• Permanent retention for summary statistics (who used which tools, daily counts, error rates)
• Immediate alerting for specific events (failed authentication attempts, denied permission requests, tool calls that produce errors)

Practical log review:

You won't read every log entry. But you should review logs when:

• Something breaks and you need to find out what changed
• A new team member's first week (ensure they're using the right tools and not hitting permission walls unnecessarily)
• After a sprint or milestone (understand usage patterns to adjust permissions)
• When you see unusual patterns (sudden spike in tool calls, calls at unusual hours, repeated failed authentications)

Step 5: Session Management

Active sessions should be visible and manageable by administrators.

Session dashboard capabilities:

A proper session management setup provides:

• Active session list: Who is connected, from where, since when, last activity time.
• Force disconnect: Terminate a specific session immediately (useful when someone leaves their workstation unlocked or a session appears compromised).
• Session limits: Maximum concurrent sessions per user (we recommend 2-3; more than that usually indicates misconfiguration rather than legitimate use).
• Idle timeout: Automatic disconnection after inactivity (30 minutes is a reasonable default; adjust based on your team's workflow — artists may have long pauses between commands while evaluating visual results).

Handling departing team members:

When someone leaves the team:

1. Revoke their credentials in the auth provider (immediate effect for new sessions).
2. Terminate all active sessions associated with their account.
3. If using API keys that they may have had access to, rotate those keys.
4. Review their recent audit logs for any unusual activity.

This should be part of your standard offboarding checklist, alongside revoking VPN access, source control access, and other system credentials.

Scaling MCP Servers for Larger Teams

As your team grows beyond 5-10 people, you'll encounter scaling challenges specific to MCP servers in game development.

The Core Scaling Challenge

MCP servers for game development are different from typical web services in a critical way: they maintain stateful connections to running application instances (Unreal Editor, Blender). You can't just spin up more server instances behind a load balancer the way you would with a stateless REST API, because each server instance is bound to a specific editor instance.

This means scaling is primarily about:

1. Routing — ensuring each developer's requests reach the correct server instance connected to their editor instance.
2. Resource isolation — preventing one developer's heavy operations from affecting another's responsiveness.
3. Instance management — starting, stopping, and monitoring multiple server instances efficiently.

Architecture for 10-20 Developers

Dedicated instances per developer:

The simplest scaling model: each developer has their own MCP server instance connected to their own Unreal/Blender instance, running on their own workstation.

Developer A's workstation:
  - Unreal Editor (their project instance)
  - MCP Server (localhost, port 8001)
  - AI client connects to gateway → routes to their MCP server

Developer B's workstation:
  - Unreal Editor (their project instance)
  - MCP Server (localhost, port 8001)
  - AI client connects to gateway → routes to their MCP server

The MCP gateway maintains a routing table mapping authenticated users to their workstation's MCP server. When Developer A sends a command through Claude, the gateway:

1. Authenticates the request (OAuth token validation)
2. Checks permissions (scope validation)
3. Routes to Developer A's MCP server instance
4. Logs the operation
5. Returns the response

This model scales linearly with team size and provides natural resource isolation (each developer's operations only affect their own machine).

Shared instances for shared resources:

Some resources are shared across the team:

• Build servers running Unreal's build pipeline (cooking, packaging, lighting builds). An MCP server connected to this instance allows authorized users to trigger and monitor builds.
• Render farm nodes running Blender for batch rendering. The Blender MCP Server on these nodes allows artists to submit and manage render jobs via AI commands.
• Staging environments running a "golden" copy of the project for QA and review.

Shared instances need stricter permission controls because multiple users interact with the same state. Write operations should be serialized (one person modifying the staging environment at a time), and the audit log becomes essential for tracking who changed what.

Load Balancing Considerations

For shared MCP server instances that receive requests from multiple users, you need a load balancing strategy that respects the stateful nature of MCP connections.

Sticky sessions are required. Once a user establishes a connection to a specific MCP server instance, all subsequent requests in that session must route to the same instance. The server maintains state (conversation context, undo history, pending operations) that is not shared between instances.

Connection-based routing rather than request-based routing. MCP uses persistent connections (typically WebSocket). The load balancer establishes the connection to a backend instance and maintains it for the session duration.

Health checking should verify not just that the MCP server process is running, but that its connection to the underlying application (Unreal/Blender) is healthy. An MCP server that has lost its connection to Unreal is not useful even if the process is responsive.

Implementation with common reverse proxies:

Nginx configuration example:

upstream mcp_servers {
    ip_hash;  # Sticky sessions based on client IP
    server 10.0.1.101:8001;  # Dev instance 1
    server 10.0.1.102:8001;  # Dev instance 2
    server 10.0.1.103:8001;  # Shared staging
}

server {
    listen 443 ssl;
    server_name mcp.internal.studio.com;

    ssl_certificate /etc/ssl/mcp-server.crt;
    ssl_certificate_key /etc/ssl/mcp-server.key;

    location /mcp/ {
        proxy_pass http://mcp_servers;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 3600s;  # Long timeout for persistent connections
        proxy_send_timeout 3600s;
    }
}

Caddy configuration (simpler for small teams):

mcp.internal.studio.com {
    tls internal
    reverse_proxy /mcp/* 10.0.1.101:8001 10.0.1.102:8001 {
        lb_policy cookie
        health_uri /health
        health_interval 10s
    }
}

Resource Monitoring

Monitor each MCP server instance for:

Memory usage. MCP servers maintain context windows that grow with conversation length. Long sessions with extensive back-and-forth can consume significant memory. Alert at 80% of allocated memory; forcefully terminate sessions at 95%.

Connection count. Track active connections per instance. Unusual spikes indicate either legitimate heavy usage or potential issues (connection leak, runaway client).

Response latency. MCP tool calls that take longer than expected may indicate Unreal/Blender is under heavy load. Log latency per tool call and alert on sustained increases.

Error rate. A sudden increase in tool call failures often indicates that the connected application has crashed, become unresponsive, or had a project-level error. Automated health checks should catch this, but error rate monitoring provides earlier warning.

Disk I/O. Some MCP operations involve significant file operations (importing assets, saving levels, packaging builds). Monitor disk I/O to ensure operations aren't being throttled by storage performance.

CI/CD Integration

MCP servers aren't just interactive tools — they can be integrated into your continuous integration and deployment pipeline.

Automated Build Verification

When a developer pushes changes to source control, your CI pipeline can:

1. Launch a headless Unreal Engine instance with the updated project.
2. Connect an MCP server to the headless instance.
3. Execute a predefined set of verification commands:
   • Open each level and verify no missing references
   • Compile all Blueprints and report errors
   • Run a scene audit checking for out-of-bounds actors, invalid references, and performance red flags
   • Generate screenshots at predefined camera positions for visual regression comparison
4. Report results back to the CI system.

This provides automated quality gates that catch common issues before they reach other team members.

Example CI verification script using MCP:

import mcp_client

async def verify_build():
    client = mcp_client.connect(
        server="mcp://ci-server:8001",
        auth_token=os.environ["MCP_CI_TOKEN"]
    )

    # Compile all Blueprints
    result = await client.call_tool("compile_all_blueprints", {})
    if result.errors:
        report_failure("Blueprint compilation errors", result.errors)
        return False

    # Check each level for missing references
    levels = await client.call_tool("list_levels", {})
    for level in levels:
        await client.call_tool("load_level", {"level_path": level})
        audit = await client.call_tool("audit_scene", {
            "checks": ["missing_references", "invalid_transforms", "bounds_check"]
        })
        if audit.warnings:
            report_warnings(level, audit.warnings)

    # Performance baseline check
    for test_scene in PERFORMANCE_TEST_SCENES:
        await client.call_tool("load_level", {"level_path": test_scene})
        stats = await client.call_tool("get_performance_stats", {"duration_seconds": 10})
        if stats.avg_frame_time_ms > FRAME_TIME_THRESHOLD:
            report_failure(f"Performance regression in {test_scene}", stats)
            return False

    return True

Automated Asset Processing

The Blender MCP Server can be integrated into asset pipelines:

1. Artist commits a new 3D model to the asset repository.
2. CI pipeline launches Blender with the MCP server.
3. MCP commands automatically:
   • Validate mesh quality (triangle count, UV coverage, normal consistency)
   • Generate LOD meshes at predefined reduction levels
   • Apply standard material conventions
   • Export to engine-ready formats (FBX for Unreal, glTF for other targets)
   • Generate thumbnail previews for the asset catalog
4. Processed assets are committed to the engine project's asset directory.

This automates the mechanical parts of the art pipeline while preserving artist control over creative decisions.

Nightly Build Pipeline

For larger projects, a nightly build pipeline can use MCP servers to:

1. Pull latest from source control.
2. Launch Unreal Editor headless.
3. Rebuild lighting for all levels (via MCP Build tools).
4. Package development, staging, and shipping builds.
5. Run automated gameplay tests using MCP Debug tools to simulate input and verify game state.
6. Deploy test builds to QA distribution (Steam Internal, TestFlight, or internal servers).
7. Generate a build report with any warnings, errors, or performance regressions.

The MCP server acts as the interface between your CI system and the game engine, allowing automated operations that previously required a human clicking through the editor UI.

Practical Example: Setting Up a 10-Person Studio

Let's walk through a complete setup for a realistic studio configuration.

The Team

• 2 Environment Artists — work primarily in Blender and Unreal, creating and placing environment assets
• 1 Character Artist — works in Blender for modeling and Unreal for integration
• 2 Gameplay Programmers — work in Unreal's Blueprint and C++ systems
• 1 Level Designer — works in Unreal, using PCG and manual placement
• 1 Technical Director — oversees everything, handles builds and deployment
• 1 Audio Designer — limited MCP usage, primarily for setting up audio components
• 2 QA Testers — need to inspect and report but not modify

Infrastructure Requirements

Hardware:

• Each developer's workstation runs their own Unreal/Blender instances and local MCP server
• 1 build server (for CI/CD and nightly builds)
• 1 staging server (for QA builds)
• 1 small server or VM for the MCP gateway and auth service (this can be lightweight — a 2-core, 4GB RAM VM is sufficient)

Network:

• All machines on the same VLAN or VPN
• MCP gateway accessible at a fixed internal hostname (e.g., mcp.studio.internal)
• No MCP ports exposed outside the VLAN

Step-by-Step Setup

1. Deploy the MCP gateway

Install the gateway service on your infrastructure VM. Configure TLS with an internal certificate authority (or Let's Encrypt if you have a domain):

# gateway-config.yaml
listen:
  address: "0.0.0.0"
  port: 443
  tls:
    cert: "/etc/ssl/mcp-gateway.crt"
    key: "/etc/ssl/mcp-gateway.key"

auth:
  provider: "local"  # or "okta", "azure_ad", "google"
  token_expiry_minutes: 120
  pkce_required: true

routing:
  mode: "user_mapping"
  # Each user is mapped to their workstation's MCP server

logging:
  destination: "file"
  path: "/var/log/mcp-gateway/audit.jsonl"
  level: "info"

2. Configure user accounts and roles

Create accounts for each team member with appropriate roles:

# users.yaml
users:
  - username: "artist_01"
    display_name: "Alex Rivera"
    role: "environment_artist"
    workstation: "ws-alex.studio.internal:8001"

  - username: "artist_02"
    display_name: "Jordan Kim"
    role: "environment_artist"
    workstation: "ws-jordan.studio.internal:8001"

  - username: "char_artist"
    display_name: "Morgan Chen"
    role: "character_artist"
    workstation: "ws-morgan.studio.internal:8001"

  - username: "prog_01"
    display_name: "Casey Taylor"
    role: "gameplay_programmer"
    workstation: "ws-casey.studio.internal:8001"

  - username: "prog_02"
    display_name: "Riley Johnson"
    role: "gameplay_programmer"
    workstation: "ws-riley.studio.internal:8001"

  - username: "level_design"
    display_name: "Avery Williams"
    role: "level_designer"
    workstation: "ws-avery.studio.internal:8001"

  - username: "tech_lead"
    display_name: "Sam Nakamura"
    role: "tech_director"
    workstation: "ws-sam.studio.internal:8001"

  - username: "audio"
    display_name: "Drew Patel"
    role: "audio_designer"
    workstation: "ws-drew.studio.internal:8001"

  - username: "qa_01"
    display_name: "Jamie Lee"
    role: "qa_tester"
    workstation: "staging-server.studio.internal:8001"

  - username: "qa_02"
    display_name: "Pat Garcia"
    role: "qa_tester"
    workstation: "staging-server.studio.internal:8001"

3. Define role permissions

# roles.yaml
roles:
  environment_artist:
    unreal_mcp:
      allowed:
        - "materials:*"
        - "lighting:*"
        - "landscape:*"
        - "foliage:*"
        - "actor_management:read"
        - "actor_management:spawn_static_mesh"
        - "actor_management:transform"
        - "scene:*"
        - "rendering:viewport"
      denied:
        - "blueprints:*"
        - "project_settings:*"
        - "build:*"
    blender_mcp:
      allowed:
        - "modeling:*"
        - "sculpting:*"
        - "materials:*"
        - "uv:*"
        - "export:*"
        - "scene:*"
        - "modifiers:*"

  gameplay_programmer:
    unreal_mcp:
      allowed:
        - "blueprints:*"
        - "actor_components:*"
        - "gameplay:*"
        - "debug:*"
        - "actor_management:*"
        - "scene:*"
        - "build:development"
      denied:
        - "materials:write"
        - "lighting:write"
        - "project_settings:write"

  level_designer:
    unreal_mcp:
      allowed:
        - "actor_management:*"
        - "scene:*"
        - "landscape:*"
        - "foliage:*"
        - "pcg:*"
        - "lighting:read"
        - "materials:read"

  tech_director:
    unreal_mcp:
      allowed: ["*"]
    blender_mcp:
      allowed: ["*"]
    admin:
      allowed: ["*"]

  audio_designer:
    unreal_mcp:
      allowed:
        - "audio:*"
        - "actor_components:audio_*"
        - "scene:read"
        - "actor_management:read"

  qa_tester:
    unreal_mcp:
      allowed:
        - "debug:*"
        - "scene:read"
        - "actor_management:read"
        - "build:read"
      denied:
        - "*:write"
        - "*:delete"
        - "*:create"

  character_artist:
    unreal_mcp:
      allowed:
        - "materials:*"
        - "actor_management:read"
        - "actor_management:spawn_skeletal_mesh"
        - "animation:*"
        - "scene:read"
    blender_mcp:
      allowed:
        - "modeling:*"
        - "sculpting:*"
        - "materials:*"
        - "uv:*"
        - "rigging:*"
        - "animation:*"
        - "export:*"
        - "scene:*"

4. Install MCP servers on each workstation

On each developer's machine:

1. Install the appropriate MCP server(s) — Unreal MCP Server for UE5 users, Blender MCP Server for Blender users, both for artists who work in both tools.
2. Configure the server to bind to the machine's internal network address (not localhost, since the gateway needs to reach it):

{
  "server": {
    "bind_address": "0.0.0.0",
    "port": 8001,
    "allowed_origins": ["mcp-gateway.studio.internal"],
    "require_gateway_auth": true,
    "gateway_public_key": "/etc/mcp/gateway-public-key.pem"
  }
}

The require_gateway_auth setting ensures the MCP server only accepts connections that have been authenticated and authorized by the gateway. Direct connections to the server port are rejected.

5. Configure developer MCP clients

Each developer configures their AI assistant (Claude Desktop, Claude Code, Cursor, etc.) to connect through the gateway:

{
  "mcpServers": {
    "unreal": {
      "url": "wss://mcp-gateway.studio.internal/mcp/unreal",
      "auth": {
        "type": "oauth2",
        "authorization_url": "https://mcp-gateway.studio.internal/oauth/authorize",
        "token_url": "https://mcp-gateway.studio.internal/oauth/token",
        "client_id": "claude-desktop",
        "scopes": ["mcp:access"]
      }
    },
    "blender": {
      "url": "wss://mcp-gateway.studio.internal/mcp/blender",
      "auth": {
        "type": "oauth2",
        "authorization_url": "https://mcp-gateway.studio.internal/oauth/authorize",
        "token_url": "https://mcp-gateway.studio.internal/oauth/token",
        "client_id": "claude-desktop",
        "scopes": ["mcp:access"]
      }
    }
  }
}

When the developer first connects, they'll be prompted to authenticate with their credentials. The gateway issues a token scoped to their role, and subsequent tool calls are authorized against that token.

6. Set up the CI/CD integration

On the build server, configure a dedicated MCP server instance connected to a headless Unreal Editor:

# ci-mcp-config.yaml
server:
  bind_address: "127.0.0.1"
  port: 8001

engine:
  type: "unreal"
  headless: true
  project_path: "/opt/builds/current_project"

auth:
  type: "service_account"
  token: "${CI_MCP_SERVICE_TOKEN}"
  scopes: ["build:*", "debug:*", "scene:read", "blueprints:compile"]

The CI service account has specific scopes limited to build and verification operations. It can compile Blueprints, run audits, and trigger builds, but cannot modify content.

7. Verify the deployment

After setup, verify each aspect:

• Each developer can authenticate and connect through the gateway
• Role permissions are enforced (artists cannot access Blueprint tools, programmers cannot modify materials)
• Audit logs capture all tool calls with correct user attribution
• Sessions time out after the configured inactivity period
• The CI pipeline can execute build verification commands
• Port scanning from outside the VLAN shows no MCP ports accessible
• Disconnecting a user from the admin panel immediately terminates their session

Common Security Mistakes and How to Avoid Them

Based on our experience supporting team deployments, these are the mistakes we see most often.

Mistake 1: Running MCP Servers on 0.0.0.0 Without a Gateway

The problem: Developers follow the quick-start guide, which binds to all interfaces for convenience. In a team environment, this means every MCP server is accessible to every machine on the network without authentication.

The fix: Either bind to 127.0.0.1 (localhost only) and use a gateway for remote access, or bind to the specific internal IP and configure allowed_origins to restrict connections to the gateway.

Mistake 2: Sharing API Keys

The problem: The team has one Claude API key that everyone uses. It's shared via Slack. Everyone knows the key. When someone leaves, the key isn't rotated because "it's too much hassle."

The fix: Each developer should have their own API key, or better yet, the gateway should manage API key distribution. When a developer authenticates via OAuth, the gateway attaches the appropriate API key to their requests. Individual developers never see or manage the key directly.

Mistake 3: No Permission Boundaries

The problem: Everyone has full access to everything because "we trust our team." Then someone's AI assistant misinterprets a command and modifies something unintended.

The fix: Permissions aren't about trust — they're about preventing accidents. Even trusted team members make mistakes, and AI assistants can misinterpret ambiguous commands. Role-based permissions ensure that a misinterpreted command can only affect the tools within that user's domain.

Mistake 4: No Audit Logging

The problem: Something broke, and nobody knows what changed. The team spends an hour asking everyone what they did. Eventually someone remembers a command they ran three hours ago that might have been related.

The fix: Enable audit logging from day one. The storage cost is negligible, and the time savings when troubleshooting are substantial. Even if you never look at the logs under normal circumstances, they're invaluable when something goes wrong.

Mistake 5: Forgetting About Source Control Interaction

The problem: Two developers use MCP to modify the same level simultaneously. Both save their changes. Source control shows conflicts in binary assets that can't be merged.

The fix: MCP operations should respect your source control workflow. Before modifying a shared asset, lock it in Perforce (or your equivalent). Some teams add a pre-flight check to their MCP server that verifies the target asset isn't locked by another user before allowing modifications. This doesn't prevent all conflicts, but it catches the most common case.

Mistake 6: Overly Permissive Network ACLs

The problem: The MCP VLAN has routing to the internet because "we might need to update the servers." An MCP server with internet access can potentially exfiltrate project data if compromised.

The fix: MCP servers don't need internet access. They communicate with local editor instances and local clients. Internet access for updates should be gated — download updates on a separate machine and transfer to the VLAN, or use a controlled proxy that only allows access to specific update URLs.

Mistake 7: Not Planning for Credential Rotation

The problem: The same OAuth client secrets, gateway certificates, and service account tokens have been in use since initial setup. Nobody knows the process for rotating them.

The fix: Document and practice credential rotation before you need it. Set calendar reminders for regular rotation (quarterly for secrets, annually for certificates). Use automated certificate management (cert-manager, ACME) where possible. Ensure at least two people know the rotation process.

Mistake 8: Ignoring the Development Machine

The problem: The studio has great server-side security, but developer workstations have MCP servers running with default configurations, no disk encryption, and auto-login enabled.

The fix: Workstation security is part of MCP security. Require disk encryption on development machines. Require screen lock after inactivity. Configure MCP servers on workstations to require gateway authentication even for local connections when in a team environment. A stolen or compromised workstation with a running, unsecured MCP server is a vector for project compromise.

Future: MCP Gateway Patterns and Enterprise Readiness

The MCP ecosystem is evolving rapidly. Several patterns are emerging for enterprise and team use that will likely become standardized.

Centralized MCP Gateways

The gateway pattern we described — a centralized proxy handling auth, routing, and logging — is becoming a common architectural pattern. Dedicated MCP gateway products are emerging that provide:

• Multi-server management from a single dashboard
• Automated health monitoring and failover
• Usage analytics and cost tracking (for AI API consumption)
• Policy enforcement (rate limiting, content filtering)
• Integration with enterprise identity providers

We expect this to be the standard deployment model for teams within the next 12-18 months.

MCP Server Registries

Imagine a studio running 15+ different MCP servers (Unreal, Blender, Maya, Houdini, custom internal tools). A registry service allows AI clients to discover available servers, their capabilities, and the user's permissions across all of them, from a single configuration endpoint.

This simplifies client configuration (one URL instead of one per server) and enables cross-tool workflows where the AI assistant orchestrates operations across multiple applications.

Compliance and Data Governance

As MCP servers handle more sensitive operations, compliance requirements increase:

• Data residency: Ensuring AI API calls (which may include project data in prompts) comply with data residency requirements.
• Content filtering: Preventing AI assistants from exposing copyrighted reference materials or NDA-protected information.
• Audit compliance: Meeting SOC 2, ISO 27001, or other certification requirements for the MCP infrastructure.

These are primarily relevant for larger studios or studios working with major publishers who impose compliance requirements. But even small studios benefit from establishing good practices early.

Rate Limiting and Cost Control

AI API calls cost money. Without controls, a runaway script or enthusiastic developer can generate significant API costs in a short time. Gateway-level rate limiting protects your budget:

• Per-user daily limits (e.g., 500 tool calls per day)
• Per-tool rate limits (e.g., no more than 10 "rebuild lighting" commands per hour)
• Budget alerts when cumulative AI API spend approaches thresholds
• Automatic degradation (reducing AI model tier) when approaching limits rather than hard-blocking developers

Conclusion

MCP server security for team game development isn't about paranoia — it's about operational reliability. The same principles that make any team infrastructure work (authentication, authorization, logging, monitoring) apply to MCP servers, with the added consideration that these servers have direct access to your project's data and your game engine's operations.

The setup described in this guide — gateway-based routing, OAuth authentication, role-based permissions, audit logging, and proper network isolation — takes about a day to implement for a 10-person studio. The ongoing maintenance is minimal: user management as the team changes, occasional credential rotation, and log review when troubleshooting.

Our Unreal MCP Server and Blender MCP Server support the MCP 1.0 security features described here. If you're currently running these servers in a team environment without security measures, the most impactful first step is binding to localhost and deploying a gateway with authentication. Everything else (role-based permissions, logging, CI/CD integration) builds on that foundation.

Start with authentication. Add permissions. Enable logging. Then iterate based on your team's specific needs. Security doesn't have to be all-or-nothing — incremental improvement is far better than waiting for a perfect setup.

Further Reading

• Setting Up Your First MCP Server with Claude and Unreal in 15 Minutes — start here if you haven't deployed an MCP server yet
• MCP Server vs. Manual Editor Scripting — understanding what MCP servers can do
• Building Multi-Agent Game Dev Pipelines with MCP — advanced multi-server orchestration
• MCP Ecosystem 2026 — broader context on the MCP landscape
• Claude Code for Game Developers Setup Guide — client-side configuration for Claude Code with MCP