optml

Posted on Mar 4

Why You Need an MCP Gateway for Enterprise AI Agents

#security #ai #mcp #opensource

MCP adoption is accelerating — but so are the risks. Every AI agent with direct API access is a potential data leak, permission escalation, or compliance violation waiting to happen.

What if you could govern every AI agent tool call through a single layer?

This is Part 1 of a 3-part series on ContextForge, an open-source MCP gateway that brings enterprise-grade security, observability, and 42 built-in plugins to AI agent infrastructure.

The Problem: AI Agents Without Guard Rails

Imagine your company adopts an AI agent platform. Different teams spin up agents:

                          ┌→ SAP ERP (REST)
HR Agent ─────────────────┼→ Employee DB (SQL)
                          └→ Slack API

                          ┌→ Salesforce (REST)
Sales Agent ──────────────┼→ Internal CRM (gRPC)
                          └→ Email Service

                          ┌→ Jenkins (REST)
DevOps Agent ─────────────┼→ GitHub API
                          └→ Cloud Infrastructure

Each agent connects directly to each API. What could go wrong?

Problem	Real-World Scenario
Data Leaks	HR agent accidentally sends employee SSNs to the LLM
Permission Chaos	An intern's agent runs `DROP TABLE` on production
No Audit Trail	"Who called what API when?" — nobody knows
Connection Sprawl	100 APIs x 50 agents = 5,000 individual connections
Cost Blindness	No idea which team is burning through LLM tokens

These aren't hypothetical risks. They're the inevitable result of letting AI agents access enterprise systems without centralized governance.

The Solution: Put a Gateway in the Middle

ContextForge sits between your AI agents and your backend systems:

                                                ┌→ SAP ERP
HR Agent ─────────┐                             ├→ Employee DB
                  │    ┌────────────────────┐   ├→ Salesforce
Sales Agent ──────┼───→│   ContextForge     │──→├→ CRM (gRPC→MCP auto-convert)
                  │    │                    │   ├→ Jenkins
DevOps Agent ─────┘    │  Security · Audit  │   ├→ GitHub
                       │  Plugin Pipeline   │   └→ Cloud APIs
AI Platform ──────────→│                    │
(Claude Code, etc.)    └────────────────────┘

Every request flows through the gateway. Every response gets filtered. Everything gets logged.

What ContextForge Actually Does

1. Turns Your Existing APIs into AI Tools — Automatically

Enterprises already have hundreds of REST and gRPC APIs. ContextForge converts them into MCP tools without modifying the original services:

Existing SAP REST API  → Register in ContextForge → Agents use it as a "tool"
Existing gRPC service  → Auto-discovery via Reflection → MCP tool, no schema needed

No code changes to existing systems. Your investment is protected.

2. Prevents Data Leaks at the Gateway Level

Every tool call and response passes through a plugin pipeline:

Agent Request: "Look up John's employee record"
     ↓
[ContextForge Plugin Pipeline]
     ├─ PII Filter        → SSN 123-45-6789 → ***-**-****
     ├─ Secrets Detection  → DB password detected → masked
     ├─ SQL Sanitizer      → SQL injection attempt → blocked
     └─ DenyList           → Prohibited keywords → blocked
     ↓
Only safe results reach the agent

GDPR, HIPAA, SOC 2 — compliance is enforced at the infrastructure layer, not in application code.

3. Isolates Teams with Multi-Tenancy

Different teams see different tools, enforced by a two-layer security model:

Layer 1 — Token Scoping: Controls what you can see (data filtering)
Layer 2 — RBAC: Controls what you can do (permission checks)

HR Team Agent     → Can only access HR servers (payroll, employee DB)
Sales Team Agent  → Can only access CRM, Salesforce
Intern's Agent    → Read-only (viewer role), write/delete returns 403

Role	Can See (Token Scoping)	Can Do (RBAC)
platform_admin	Everything	Everything
team_admin	Team tools	Team management + tool execution
developer	Team tools	Tool execution
viewer	Team tools	Read only

4. Tracks Costs and Usage

ContextForge Observability:
├─ Prometheus Metrics   → Per-team, per-agent API call counts
├─ TOON Compression     → 30-70% LLM token reduction (= cost savings)
├─ Rate Limiter         → Per-team, per-user call limits
├─ Token Catalog        → Per-token quotas, expiry, usage tracking
└─ Audit Logs           → Full record of who did what, when

Finally, you can answer: "How much did AI agent operations cost this month?"

5. Deploys Like Enterprise Software

AI Platform (Cloud)
       ↓
ContextForge (OCP / K8s / Docker)
├─ Helm Charts       → Auto-scaling (HPA)
├─ PostgreSQL        → Persistent storage
├─ Redis             → Caching / sessions
├─ TLS 1.3           → End-to-end encryption
├─ NetworkPolicy     → Network isolation
└─ OAuth / SSO       → Enterprise identity (Entra, Okta, Keycloak)

By the Numbers

Metric	Value
Built-in plugins	42
Unit tests	13,755+
Code coverage	99%
Supported protocols	MCP, A2A, REST→MCP, gRPC→MCP
API endpoints	344 (OpenAPI 3.1.0)
Supported databases	SQLite, PostgreSQL, MySQL, MariaDB
Deployment options	Docker, K8s Helm, OpenShift, AWS/Azure/GCP/IBM Cloud

A Real-World Scenario

1. Employee asks AI platform:
   "Analyze last week's production incident logs"

2. AI agent calls tools through ContextForge:
   ├─ Splunk API (REST→MCP auto-convert) → Fetch logs
   ├─ Jira API → Search related issues
   └─ PagerDuty API → Retrieve incident history

3. ContextForge plugin pipeline:
   ├─ PII Filter → Mask customer PII in logs
   ├─ TOON Compression → Reduce token usage on large log data
   └─ Audit Log → Record "who accessed production logs"

4. Agent delivers safe, filtered analysis

Without vs. With

	Without ContextForge	With ContextForge
API connections	Each agent implements its own	Register once, share everywhere
Security	Handled in each agent's code	Applied uniformly at the gateway
Auditing	Build it yourself	Built-in (Prometheus + logging)
Permissions	Configure per API	Unified RBAC + token scoping
Cost tracking	Not possible	Per-team, per-token usage tracking
Adding new APIs	Modify agent code	Just register the REST/gRPC endpoint

What's Next

In Part 2, we'll get hands-on: clone the repo, start a dev server, register an MCP server, and execute tool calls — all in under 15 minutes.

In Part 3, we'll deep-dive into the 42-plugin pipeline: PII filtering, rate limiting, circuit breakers, LLM summarization, and the unique TOON compression that saves 30-70% on LLM tokens.

ContextForge is open source under Apache 2.0.

IBM / mcp-context-forge

An AI Gateway, registry, and proxy that sits in front of any MCP, A2A, or REST/gRPC APIs, exposing a unified endpoint with centralized discovery, guardrails and management. Optimizes Agent & Tool calling, and supports plugins.

ContextForge

An open source registry and proxy that federates MCP, A2A, and REST/gRPC APIs with centralized governance, discovery, and observability. Optimizes Agent & Tool calling, and supports plugins.

ContextForge is an open source registry and proxy that federates tools, agents, and APIs into one clean endpoint for your AI clients. It provides centralized governance, discovery, and observability across your AI infrastructure:

Tools Gateway — MCP, REST, gRPC-to-MCP translation, and TOON compression
Agent Gateway — A2A protocol, OpenAI-compatible and Anthropic agent routing
API Gateway — Rate limiting, auth, retries, and reverse proxy for REST services
Plugin Extensibility — 40+ plugins for additional transports, protocols, and integrations
Observability — OpenTelemetry tracing with Phoenix, Jaeger, Zipkin, and other OTLP backends

It runs as a fully compliant MCP server, deployable via PyPI or Docker, and scales to multi-cluster environments on Kubernetes with Redis-backed federation and caching.