ContextForge MCP Gateway

Every tool call on both the /rpc and /mcp paths is authenticated and checked against the caller's RBAC permission and team-scoped visibility before any upstream credential is attached, which is a genuine per-principal authorization layer. The credentials themselves are mostly static per upstream server and shared by every user who can see that server, and by default a newly registered server is public and every team role, including viewer, may execute tools. The gateway also always forwards a client-supplied X-Upstream-Authorization header as the upstream Authorization, which is MCP token passthrough and caps this criterion. A compromise exposes write access to every registered upstream system.

As a gateway, ContextForge leaves approval to the MCP host and only relays whatever readOnly/destructive hints the upstream server or the registering user supplied; it never derives them, so REST-wrapped tools that POST or DELETE usually carry no risk signal. It does offer a dry-run preview endpoint that validates arguments and resolves the target without calling it, but nothing forces a host to use it. Annotations can be set or changed by whoever registers or updates the tool, including the upstream server itself. Once a call is approved by the host, the gateway executes it against the upstream system with no undo.

Every tool invocation, whatever the backend, is validated against the tool's JSON input schema in a killable worker before anything is sent, and REST tool URLs are re-validated against SSRF rules and pinned to the resolved IP after argument substitution, blocking cloud metadata, localhost and private ranges by default. Validation is only as tight as each tool's schema, and URL construction for upstream requests is not strictly constrained. The gateway ships no tools of its own, but anything registered is immediately callable by every user who can see it, and virtual servers are the only way to narrow the set.

The gateway never launches MCP servers or shell commands itself; the code it interprets is prompt templates (rendered with Jinja2's in-process SandboxedEnvironment) and jq filters on tool output, which run in forked worker processes with the environment cleared and a 2-second kill timer. Both are restriction layers inside the gateway's own user account rather than an OS boundary, and on non-Linux hosts or with one config switch jq runs in-process with no timeout. A template-sandbox escape lands inside the gateway process, which holds the JWT signing key, the credential encryption key and every stored upstream credential.

Tool results, upstream tool descriptions and A2A agent replies are relayed to clients exactly as received, with no provenance marking or untrusted-content flag the host could act on. The guardrail plugins that could filter content (deny lists, PII, moderation) are all disabled by default and are detection filters even when on. A client steered by malicious upstream content can use the same gateway session to read through one registered server and write or exfiltrate through another with stored credentials, and the gateway does nothing to stop that combination.

What persists is the shared catalog of tools, prompts and resources, including tool descriptions copied from upstream servers when they are registered, plus per-user LLM chat history in Redis that expires after an hour. Writes to the catalog require an authenticated user with create permission, and upstream changes are not pulled in automatically, but stored descriptions carry no provenance and newly registered servers default to public visibility, so one user's registration is served to every user's model. Configuration comes from operator files (.env in the working directory, plugins/config.yaml), not from untrusted workspaces.

The extensions ContextForge loads are remote MCP servers and A2A agents that users register, plus optional Python plugins that are disabled by default. Remote servers run elsewhere and receive only their own configured credentials, so a malicious one cannot read the gateway's secrets, but nothing pins or verifies what a server serves, and any user who owns a personal team can register one that is public to everyone. Tool definitions are snapshotted at registration and only refreshed on request, which limits silent changes to the tool list but not to the server's behaviour.

Upstream credentials are encrypted at rest with an Argon2id-derived Fernet key, attached server-side at call time and never placed in model context; logs default to ERROR level, payload logging and tracing are opt-in, and trace exports redact token, password and authorization fields. The weak points are the credentials themselves: they are long-lived, broadly scoped upstream keys, and the client-supplied X-Upstream-Authorization header is forwarded to the upstream server.

Out of the box the gateway records only per-tool metrics rows (tool, timestamp, latency, success) with no caller identity or arguments, buffered and flushed once a minute; the audit trail, security event log and permission audit are all off, and the default ERROR log level drops the INFO lines that name each invocation. After an incident you could see that a tool ran, but not who ran it or with what input, unless the operator had turned the audit features on.

Every tool call has a server-enforced timeout (60 seconds by default, overridable per tool), the MCP and tools endpoints are rate-limited per user at 100 requests a minute with lockout, and on the JSON-RPC path a cancellation request actually cancels the in-flight task. The advertised tool_rate_limit and tool_concurrent_limit settings are not enforced anywhere, there is no response-size cap on JSON tool results, and the embedded LLM chat agent sets no step limit of its own and registers a no-op cancel handler.