Golf Gateway

Golf is the enterprise MCP platform. Get centralized control and visibility over all your MCPs, enforce access policies, and integrate with your SIEM.

Broker upstream credentials - Agents authenticate once; Golf injects API keys and OAuth tokens for upstream MCP servers
Enforce strict role-based access - Control which agents can access which servers, tools, and resources
Continuous governance through logging - Every interaction is logged with tamper-proof audit trails
Ringfence sensitive data - Automatically redact PII to prevent leakage to model providers and downstream systems

The Problem

Traditional API gateways and WAFs were not built for MCP. They see HTTP and JSON, but they don’t understand:

MCP methods, tools, resources, prompts, elicitation, sampling, and other protocol primitives
Multi-step agent flows and how tools are actually used
Authorization decisions that require MCP-aware context (tools, resources, and capabilities)

Whether you’ve blocked AI agents entirely (but employees use them anyway on personal devices) or approved them (but now have fragmented control points across Claude, Cursor, ChatGPT, etc.) - you need a governance layer.

What Golf Gateway Does

Govern

Single control point regardless of which agent (Claude, Cursor, ChatGPT, Copilot) employees use.

Audit

Full audit trail for every interaction. Export to your SIEM (Elasticsearch, Sentinel, OTLP).

Control

Centralized RBAC for non-human identities. One policy layer across all your agents and MCP servers.

Protect

Redact PII automatically and enforce rate limits and replay protection.

Golf Gateway is protocol-aware: it understands MCP semantics and uses that to protect your agents and backend systems. The gateway operates as a transparent proxy—neither MCP clients nor servers need modifications:

Without Gateway
With Gateway

Direct connection. No visibility. No control.

To route through the gateway, configure your MCP client to connect to the gateway’s URL instead of the MCP server directly:

{
  "mcpServers": {
    "github": {
      "url": "https://gateway.company.com/github/mcp"
    }
  }
}

Security

Golf Gateway applies multiple security controls on every MCP request.

Rate Limiting

Protect against abuse with sliding-window rate limiting at three layers:

Layer	Scope
Per-User	Individual user
Per-Server	Single MCP server
Global	Entire gateway

The most restrictive limit applies.

Replay Protection

Prevent session token theft and reuse:

When a session is first used, it’s bound to the authenticated user
If the same session ID appears with a different user, it’s flagged as replay
Replay attempts are blocked and logged

Audit & Visibility

Every request is logged with cryptographic integrity:

HMAC-SHA256 hash chain - Tamper-evident logging
Sequence numbers - Detect missing or reordered entries
Rich metadata - User, server, tool, latency, authorization result

This gives you incident response capability and the audit trail compliance teams need.

Policy Engine

The Policy Engine is the centralized governance system that manages and enforces access control and data protection across Golf Gateway. It operates on a 3-layer hierarchy where policies at each level can restrict (but never expand) permissions:

Organization → Gateway → Server/Capability

The Policy Engine manages four policy types:

Policy	Purpose	Hierarchy
Server RBAC	Control which groups can access MCP servers	All 3 layers
Capability RBAC	Control access to tools, prompts, and resources	All 3 layers + annotations
PII Scrubbing	Detect and mask sensitive data	All 3 layers
Capability Versioning	Require approval for capability changes	Server only

How Policies Merge

Policies follow a “most restrictive wins” doctrine. As you move down the hierarchy, policies can only become more restrictive, never less:

Field	Merge Rule	Behavior
Enabled flags	OR	True if ANY layer enables
Allowed groups (allow mode)	Intersection	User must be in ALL layers’ groups
Denied groups (deny mode)	Union	Blocked if in ANY layer’s deny list
Sensitive fields	Union	All fields from all layers are scrubbed
Custom rules & entities	Union	Combined from all layers

Example: Three-Layer RBAC Merge

Organization: allowed_groups = ["admins", "devs", "viewers"]
Gateway:      allowed_groups = ["admins", "devs"]
Server:       allowed_groups = ["admins"]

Result: Only "admins" can access (intersection of all layers)

Server RBAC

Server RBAC controls which user groups can connect to each MCP server. Configure at any layer to set defaults or restrictions:

Mode	Behavior
Allow (default)	Only users in `allowed_groups` can access
Deny	Users in `denied_groups` are blocked, others allowed

When both modes are configured across layers, deny lists are checked first and take precedence.

Capability RBAC

Capability RBAC provides fine-grained access control for individual tools, prompts, and resources. It uses a 4-layer merge that incorporates MCP tool annotations:

Organization Policy

Set default groups for each annotation category (read-only, destructive, unspecified)

Gateway Policy

Override or restrict org defaults (merged via intersection)

Annotation Selection

Tool annotations determine which policy category applies

Capability Override

Per-tool group restrictions (intersected with policy)

Tool Annotations

Annotations are metadata hints that MCP servers provide about their tools. They’re part of the MCP specification and describe the nature of each tool’s behavior—whether it only reads data, makes destructive changes, or falls somewhere in between. Golf Gateway discovers these annotations automatically when it connects to an MCP server and uses them to apply the appropriate access policy:

Annotation	Meaning	Policy Category
`readOnlyHint: true`	Tool only reads data, no side effects	Read-only
`destructiveHint: true`	Tool may perform destructive operations (delete, overwrite)	Destructive
Neither annotation	Tool behavior is unspecified or mixed	Unspecified

Example: Annotation-Based Policy

You configure these defaults at the organization level:

read_only.allowed_groups = ["all-users"]
destructive.allowed_groups = ["admins"]
unspecified.allowed_groups = ["developers", "admins"]

When a user invokes a tool:

list_files (readOnlyHint: true) → Allowed for all users
delete_file (destructiveHint: true) → Requires admin group
send_message (no annotations) → Requires developers or admins

This allows you to set broad policies like “all destructive tools require admin access” at the org level, while still allowing per-tool overrides at the capability level when needed.

PII Scrubbing Policy

PII scrubbing configuration follows the same 3-layer merge. At each layer you can configure:

Sensitive fields: Field names to always mask
Pre-built recognizers: Toggle built-in entity detection (21 types)
Custom rules: Regex patterns with mask/remove/hash/replace methods
Custom entities: AI-powered detection for custom data types

All configurations are merged using union—if any layer adds a field or rule, it applies.

Capability Versioning

Unlike RBAC and scrubbing policies, versioning is configured per-server only and is not part of the 3-layer policy hierarchy.

When enabled on a server, new or modified capabilities require admin approval before becoming active:

Gateway discovers new/changed capabilities during refresh
Changes are marked as “pending approval”
Capabilities are blocked until an admin approves them
All changes are recorded in the capability history for audit

For step-by-step setup, see Configure Server RBAC, Configure Capability RBAC, and Configure PII Scrubbing.

Authentication

Golf Gateway implements a proxy authentication model: users authenticate to the gateway once, and the gateway manages credentials for upstream MCP servers.

How It Works

User authenticates to Gateway via your identity provider (Auth0, Entra ID, Descope)
Gateway issues a session token (HS256 JWT) for subsequent requests
Gateway injects upstream credentials for each MCP server the user accesses
Users never see upstream credentials - they’re managed entirely by the gateway

Credential Types Golf supports two types of upstream credentials:

API Keys
OAuth Tokens

For MCP servers that accept static API keys:

User provides their API key once in the Dev Portal
Key is encrypted and stored securely
Gateway injects the key into requests automatically

Use case: Internal APIs, services with static authentication

Security Benefits Golf Gateway’s credential management provides several important security benefits. First, credential isolation ensures that users never see or handle raw API keys or OAuth tokens; all sensitive credentials are stored and managed by the gateway itself. The system also supports automatic refresh of OAuth tokens, so users maintain access without manual intervention or interruptions. Centralized revocation gives administrators the ability to disable access instantly by removing credentials from the gateway, eliminating the risk of lingering permissions. Additionally, Golf Gateway maintains a complete audit trail—every time credentials are used, that activity is securely logged, enabling compliance, oversight, and incident response.

Configuration Modes

Golf Gateway supports two primary configuration modes that determine where configuration and policies are loaded from:

Centralized Mode
Distributed Mode

All configuration from Control Plane

MCP servers, policies, and exporters defined in Control Plane UI
Gateway fetches configuration bundles on startup and heartbeat
Hot reload on configuration changes (no restart needed)

Best for: Teams wanting full UI-based management, multi-gateway deployments

What Comes From Where

Configuration	Centralized	Distributed
MCP server definitions	Control Plane	YAML file
Server-level RBAC	Control Plane	YAML file
Gateway-level policy	Control Plane	YAML file
Security engine settings	Control Plane	YAML file
Exporters	Control Plane	YAML file
Org-wide policies	Control Plane	Control Plane

These modes are not mutually exclusive. You can run some gateways in centralized mode and others in distributed mode within the same organization. All gateways share organization-wide policies from the Control Plane.

Mode Detection Golf Gateway automatically detects which mode to use:

YAML file with control_plane section → Distributed mode
Control Plane environment variables only (no YAML) → Centralized mode

No explicit mode configuration is required. Hot Reload Both modes support hot reload without gateway restart:

Mode	Trigger	Latency
Centralized	Config version change on heartbeat	~30 seconds
Distributed	File system change detected	~1 second

For deployment guides, see Deploy Centralized and Deploy Distributed.

When to Deploy Multiple Gateways

Just as organizations deploy multiple API gateways for different domains and audiences, Golf Gateway supports multi-gateway architectures. Each gateway can serve a specific purpose while reporting to the same Control Plane for unified visibility.

Per-Domain
Per-Audience
Per-Environment

Separate gateways for different business domainsEach team or department gets its own gateway with tailored policies:

Engineering Gateway - Company-built agents accessing internal APIs
HR Gateway - Employee-facing agents with strict PII controls
Finance Gateway - Agents accessing financial systems with enhanced audit requirements

Benefits: Teams manage their own configurations. Domain-specific security policies. Clear ownership boundaries.

Benefits

Benefit	Description
Blast Radius Isolation	Issues in one gateway don’t affect others
Tailored Policies	Different security requirements per domain or audience
Independent Scaling	Scale high-traffic gateways without over-provisioning others
Team Autonomy	Teams can manage their own gateway configuration (in Distributed mode)
Unified Visibility	Single Control Plane for cross-gateway analytics and audit

Start with a single gateway and add more as your requirements grow. The Control Plane makes it easy to manage any number of gateways from one place.

Deployment

Golf Gateway is available as a Docker image for Kubernetes and container deployments.

Image

Variant	Tag	Size	Use Case
Default	`v1.0.0`	~1.5 GB	Production gateway runtime

Hardware Requirements

Recommended:

4 vCPU
8 GB RAM

AWS example: c7a.xlarge

Required Dependencies

Golf Gateway requires the following external services:

Service	Purpose	Notes
Redis	Session management, rate limiting, replay protection, auth token caching	Required. Redis 7.x recommended.

Redis is essential for Golf Gateway operation.

Container Orchestration

Golf can provide example Helm charts for Kubernetes deployments. Contact the Golf team for access to deployment templates and configuration examples tailored to your infrastructure.

For production deployment configuration, see Environment Variables Reference and YAML Schema.

Overview

Guides

Reference

Support

The Problem

What Golf Gateway Does

Govern

Audit

Control

Protect

Security

Rate Limiting

Replay Protection

Audit & Visibility

Policy Engine

How Policies Merge

Server RBAC

Capability RBAC

Tool Annotations

PII Scrubbing Policy

Capability Versioning

Authentication

Configuration Modes

When to Deploy Multiple Gateways

Benefits

Deployment

Image

Hardware Requirements

Required Dependencies

Container Orchestration

​The Problem

​What Golf Gateway Does

Govern

Audit

Control

Protect

​Security

​Rate Limiting

​Replay Protection

​Audit & Visibility

​Policy Engine

​How Policies Merge

​Server RBAC

​Capability RBAC

​Tool Annotations

​PII Scrubbing Policy

​Capability Versioning

​Authentication

​Configuration Modes

​When to Deploy Multiple Gateways

​Benefits

​Deployment

​Image

​Hardware Requirements

​Required Dependencies

​Container Orchestration

The Problem

What Golf Gateway Does

Security

Rate Limiting

Replay Protection

Audit & Visibility

Policy Engine

How Policies Merge

Server RBAC

Capability RBAC

Tool Annotations

PII Scrubbing Policy

Capability Versioning

Authentication

Configuration Modes

When to Deploy Multiple Gateways

Benefits

Deployment

Image

Hardware Requirements

Required Dependencies

Container Orchestration