Golf

What do they actually do

Golf makes two linked products for teams building and securing Model Context Protocol (MCP) servers.

GolfMCP is an open‑source framework you install locally to build an MCP server. Developers write tools, resources, and prompts as simple Python files; the Golf CLI discovers them, compiles a runnable server, and wires up authentication, tracing, and telemetry so teams don’t have to build that plumbing themselves (docs, GitHub).

Golf Gateway (also called Golf Firewall) is a production gateway/proxy that runs in the customer’s environment and sits in front of MCP servers. It inspects requests and responses, validates tokens, enforces RBAC and rate limits, provides audit logs and traces, and detects prompt‑injection/PII‑leak style issues before agent‑facing outputs reach an agent. It’s offered to run inside customer clouds/on‑prem with integrations to export logs/telemetry to common observability tools (homepage, Firewall blog). The team says they’re already routing real MCP traffic for early enterprise customers and onboarding early teams (YC profile, Firewall blog).

Who are their target customer(s)

• Enterprise platform/backend engineers building agent‑facing servers: They need a repeatable way to ship MCP functionality without re‑implementing auth, tracing, and local‑to‑prod flows for every endpoint. Manual plumbing slows delivery and introduces security gaps.
• Security and compliance teams at larger companies: They must prove who did what and stop data leaks. They worry MCPs can leak PII or credentials or be manipulated by prompt injections, and they need audit trails and policy enforcement tied to existing identity and SIEM tools.
• SRE/ops teams running MCP workloads in corporate cloud or on‑prem: They need a low‑latency, auditable gateway that plugs into current identity/observability stacks. New agent endpoints shouldn’t create blind spots or bypass rate limits, RBAC, and incident response workflows.
• Product teams adding agent tools (search, code execution, connectors): They fear tool‑level exploitation or malformed outputs reaching users/agents. They want a way to inspect and block risky responses and maintain an audit trail without custom middleware.
• Internal AI/infra teams standardizing agent features across many teams: They need a consistent developer workflow and guardrails to onboard other groups quickly, without bespoke integrations for auth, tracing, and security controls each time.

How would they acquire their first 10, 50, and 100 customers

• First 10: Founder‑led pilots with open‑source users and YC contacts: reach out to active GolfMCP users, install the gateway in their environment, connect identity/observability, and run a live security test to demonstrate blocking/alerting; provide hands‑on integration and a named engineer on call.
• First 50: Package a repeatable “security assessment + pilot” with scripts/connectors and a demo that reproduces prompt‑injection/PII‑leak scenarios; use early customers as references in targeted outbound to platform/SRE/security teams and run workshops with identity/observability partners.
• First 100: Productize integrations and deployment templates, list on partner marketplaces, build channel relationships with MSSPs/consultancies, and publish security/compliance artifacts (runbooks, audit log formats, SOC2‑like report) while scaling sales and customer success for longer enterprise cycles.

What is the rough total addressable market

Top-down context:

In the narrowest definition, Golf competes in API/gateway security, a market estimated around $1.25B in 2025 with fast growth thereafter (Mordor Intelligence). If Golf expands into adjacent application and cloud security budgets, the relevant spend rises into the low‑to‑mid tens of billions over the next few years (Statista appsec, content/security gateways, cloud security).

Bottom-up calculation:

If 10,000 mid‑to‑large enterprises globally adopt agent‑facing gateways over time and pay $100k–$200k per year for security, governance, and observability, that implies a $1.0–$2.0B TAM for a focused gateway product. Early SAM could be a subset (e.g., 1,500–3,000 early adopters in U.S./EU/ANZ regulated/tech sectors at similar ACVs => ~$150M–$600M).

Assumptions:

• Roughly 10k enterprises worldwide both build agent‑facing features and require on‑prem/controlled data flows (subset of tens of thousands of mid‑large firms; see NAICS/BLS counts: NAICS, BLS).
• Enterprise ACVs for security gateways cluster around $100k–$200k annually for core features and support, excluding large usage overages.
• Adoption curves start with regulated/tech-forward buyers (1.5k–3k orgs) before broadening globally.

Who are some of their notable competitors

• LangChain / LangSmith: LangChain is a popular SDK for building agents and tools; LangSmith provides tracing/observability for LLM apps. Teams could use LangChain + LangSmith for dev workflow and agent tracing instead of GolfMCP + Golf Gateway (LangSmith observability, tracing tutorial).
• Arize AI: Arize offers model and LLM monitoring (drift, performance, anomaly detection) for enterprises. It overlaps with Golf’s roadmap to add analytics and anomaly detection on agent/MCP traffic (model monitoring, LLM monitors).
• Fiddler AI: Fiddler provides AI observability, LLM monitoring, and guardrails (explainability, anomaly detection). It’s an alternative for organizations prioritizing analytics and guardrails around agent behavior and tool responses (product, LLM monitoring).
• Cerbos: Cerbos is an open‑source authorization engine (RBAC/ABAC/PBAC) that can be embedded in services or gateways. It overlaps with Golf’s access‑control use cases for token validation and fine‑grained policy enforcement (product notes, securing AI agents).
• Splunk: Splunk’s SIEM and observability suite is widely used for log collection, auditing, and detections. Some enterprises may route MCP logs to Splunk for auditing/alerts instead of adopting Golf’s gateway analytics (observability & security, Enterprise Security).