Skip to main content

​
Golf Firewall

Enterprise security gateway for MCP servers Golf Firewall is the security layer that sits in front of your Model Context Protocol (MCP) servers. Instead of exposing each MCP server directly, you route traffic through Golf once and get:
  • A single secure front door for all MCP servers
  • Real-time protection against prompt injection and other MCP-specific attacks
  • Centralized policies, audit trails, and visibility for every request and response
This page explains what Golf Firewall does, when to use it, and how a typical team rolls it out.

​
1. What Golf Firewall solves

Traditional API gateways and WAFs were not built for MCP. They see HTTP and JSON, but they don’t understand:
  • MCP methods, tools, and resources
  • Multi-step agent flows and how tools are actually used
  • Prompt injection and tool poisoning attempts hiding inside “normal” data
Golf Firewall is protocol-aware: it understands MCP semantics and uses that to protect your agents and backend systems. But beyond security, it also helps you understand how people actually use your agents and tools, giving you visibility into:
  • Which tools are used most often
  • Where users or agents struggle or fail
  • Which prompts, flows, or tools generate the most errors
  • How usage patterns vary across teams, tenants, or environments
Teams use Golf Firewall when:
  • They expose MCP servers to customer agents (Apps, ChatGPT, custom agent stacks)
  • They handle sensitive data (PII, credentials, internal systems)
  • Security / compliance teams need clear controls and audit trails
  • Product and platform teams want insight into real-world MCP usage to improve tools and workflows
  • Multiple teams run separate MCP servers and you want one place to manage risk and understand behavior

​
2. High-level capabilities

Think of Golf Firewall as spanning both security and product insights:
  1. Protect – stop MCP-specific attacks and data leaks
  2. Observe – full audit trail and visibility into MCP traffic
  3. Control – central policy and access control for all MCP servers
  4. Understand – analytics and insights into how agents, users, and tools behave in the real world

​
2.1 Protect – Protocol-aware threat prevention

Golf Firewall inspects MCP traffic between agents and servers and can run in:
  • Monitor mode – log and score threats without blocking
  • Enforce mode – block or modify traffic based on policy
It is designed to catch threats that generic tools miss, including:
  • Prompt injection & tool poisoning Attempts to steer the agent away from your intent, override system instructions, or call tools in unsafe ways.
  • Token & credential abuse
    • Token hijacking and reuse in unintended contexts
    • Use of expired, malformed, or mis-scoped tokens
    • Abusing powerful tokens from one tool/server in another
  • Command & input abuse
    • Command injection patterns in tool parameters
    • Path traversal and unsafe file paths
    • Dangerous shell/database queries passed through tools
  • Tool spoofing & policy bypass
    • Impersonating tools or resources
    • Routing calls around your intended policy
    • Exploiting inconsistent configs across multiple MCP servers
You define what should be logged, warned, or blocked; Golf Firewall enforces it consistently across every server.

​
2.2 Observe – Audit trails and compliance

Golf Firewall creates an MCP-layer audit log, giving you a traceable story for every interaction:
  • Per-request details
    • MCP method, tool/resource, and parameters (with configurable redaction)
    • Which user / agent called it (from your IdP)
    • Which MCP server handled it
  • End-to-end flow
    • Correlated requests and responses
    • Timing and latency information
    • Policy decisions and threat scores attached to each event
  • Compliance-ready logging
    • Structured logs suitable for SIEM ingestion (Elastic, Splunk, Datadog, etc.)
    • OpenTelemetry integration where you already have observability pipelines
    • Configurable retention and data minimization for GDPR/CCPA-minded teams
Security and compliance teams get a single source of truth for “who did what, when, and with which tool” across all MCP servers.

​
2.3 Control – Central policy and access control

Golf Firewall gives you one place to define and enforce security rules for all MCP servers:
  • Role-Based Access Control (RBAC)
    • Restrict which users, groups, or client apps can access specific MCP servers or tools
    • Apply different policies for internal vs external tenants
  • Rate limiting & abuse protection
    • Per-user / per-tenant / per-server rate limits
    • Protects backend resources from runaway agents or misconfigured integrations
  • Centralized security hardening
    • CORS and security headers applied consistently at the edge
    • Strict token validation and MCP spec/resource indicator checks before traffic hits your servers
    • “Golden” defaults so new MCP servers inherit your existing security posture automatically
Result: shipping a new MCP server does not mean inventing a new security story – it plugs into Golf Firewall and inherits existing policies.

​
2.4 Understand – Usage analytics & behavioral insights

Golf Firewall doesn’t just secure MCP traffic—it helps you understand how agents, users, and tools behave in the real world. With built‑in analytics and patterns derived from the audit stream, you can answer questions such as:
  • Tool usage insights
    • Which tools are called most frequently?
    • Which tools are unused or under‑used?
    • Which tools generate the highest error or failure rates?
  • User & agent behavior
    • Who are the most active users or tenants?
    • Which workflows or prompts do agents repeatedly use?
    • How do usage patterns change over time or across teams?
  • Friction & failure analysis
    • Where do agents get stuck or repeatedly retry?
    • Which prompts or inputs correlate with errors or escalations?
    • How often do agents misuse or misunderstand certain tools?
  • Operational & product insights
    • What is the actual demand for each MCP server?
    • Where should you invest engineering time for reliability or performance?
    • Which tools need clearer documentation or safer defaults?
These insights help platform, product, and security teams:
  • Improve tool design and developer experience
  • Detect silent failures or confusing flows
  • Understand adoption across teams or customers
  • Make informed decisions about scaling, deprecations, or new features
Golf Firewall becomes the analytics and intelligence layer for your MCP ecosystem—not just the security boundary.

​
3. Where Golf Firewall sits in your stack

At a high level:
Agents / MCP Clients → Golf Firewall → Your MCP Servers
You continue to run your MCP servers as usual. Instead of pointing agents at those servers directly, you:
  1. Point them at Golf Firewall
  2. Tell Golf which MCP server(s) sit behind it
  3. Let Firewall handle authentication, inspection, and policy decisions on the way in and out
This gives you:
  • One entry point for all agent traffic
  • One place to plug in your identity provider and SIEM
  • One dashboard to see traffic, incidents, and policy violations
No changes are required in the agent code beyond switching the MCP endpoint to Golf.

​
4. Key product surfaces

​
4.1 Golf Firewall dashboard

The dashboard is your operational cockpit:
  • Traffic overview
    • Requests per MCP server, per tool, per user
  • Threat & incident feed
    • Real-time view of prompt injection attempts, token issues, and policy violations
    • Severity and confidence scores
    • Quick drill-down into the affected sessions, users and tools
  • Policy & configuration
    • Manage RBAC, rate limits, and DLP rules from one place
    • Configure which data is logged or redacted
    • Map IdP groups/claims to access rules

​
4.2 Identity and access integration

Golf Firewall connects to your existing identity provider (e.g. Okta, Auth0, Azure AD etc.).
  • Accepts tokens issued by your IdP
  • Validates them to MCP-specific rules (audience, scopes, resource indicators)
  • Enriches logs and dashboards with real user identity
  • Helps you enforce policies based on groups, app IDs, or claims
From a security team perspective, Golf becomes the place where “who is allowed to call which MCP tool” lives, instead of scattered per-server configs.

​
4.3 Logging & SIEM

Golf Firewall is built to plug into your existing monitoring stack:
  • Export security and audit events to:
    • Elasticsearch
    • Splunk
    • Datadog
    • Sumo Logic
    • Or any system that accepts structured logs
  • Choose what leaves the cluster:
    • Redact PII or secrets at the firewall
    • Control which fields are included for different environments (dev vs prod)
This gives SecOps the context they need without your app teams reinventing logging on each MCP server.

​
5. Typical rollout journey

This is the recommended rollout flow — designed to give you immediate visibility using Golf’s managed environment, then transition to full control on‑prem.

​
Step 1 – Connect your MCP servers in a managed deployment

  • Register your MCP servers with the managed Golf Firewall environment
  • No infrastructure changes needed — simply point Golf at your servers

​
Step 2 – Run in monitor mode (managed)

  • Start in monitor‑only mode:
    • Inspect requests and responses
    • Collect metrics
    • See threat scores and misconfigurations without blocking
Outcome: you build a understanding of how Golf Firewall works and identify issues early — without touching your infra.

​
Step 3 – Once confident, deploy Golf Firewall on‑prem

  • Install Golf Firewall in your own cloud or Kubernetes environment
  • Apply the same policies and identity mappings proven in the managed rollout
Outcome: you gain full control over traffic, data locality, and integration with internal systems.

​
Step 4 – Enable your teams to deploy, protect and observe MCP servers

  • Give platform, product, and security teams access to the dashboard
  • Let each team onboard their own MCP servers behind your on‑prem Golf Firewall
  • Provide standardized policies, RBAC, and DLP rules out of the box
  • Teams get:
    • Self‑serve onboarding
    • Real‑time insights
    • Consistent security by default
Outcome: every new MCP server is consistently protected, observable, and governed — without reinventing security each time.

​
6. Example workflows

​
6.1 Investigating a suspicious agent run

  1. Your SIEM or the Golf dashboard flags a spike in prompt injection alerts for a particular MCP server.
  2. In Golf, you filter incidents by that server and time range.
  3. You open an incident and see:
    • The original MCP request
    • The server response containing suspicious instructions
    • Which users were involved
  4. You review the context and:
    • Tighten DLP or threat rules for that server
    • Add RBAC or rate limits if needed
Result: full story of the attempted attack without digging through scattered logs.

​
6.2 Rolling out a new MCP server safely

  1. A team builds a new MCP server
  2. Before exposing it to customer agents:
    • They register it behind Golf Firewall
    • They select existing policies (e.g. “Customer-facing MCP with PII”) as a baseline
  3. Traffic goes live in monitor mode for a few days:
    • Security and platform teams watch the dashboard for unusual patterns
  4. Once confident, they:
    • Enable blocking for high-confidence threats
    • Add the server to compliance documentation as “protected by Golf”
Result: new MCP servers ship faster, with a consistent security story from day one.

​
7. Operating models

Golf Firewall supports:
  • Self-hosted deployments – run Golf in your own cloud for maximum control
  • Managed / cloud-hosted options – managed deployments always start in monitor‑only mode for the initial rollout, so you can evaluate traffic patterns, detect issues, and tune policies before enabling enforcement
In both cases you get the same core behavior:
  • Protocol-aware inspection of MCP traffic
  • Centralized policies and RBAC
  • Full audit logging and integrations