How does Enforgate address MCP-specific security risks?

The security community has converged on a set of risk categories specific to the Model Context Protocol — efforts like SAFE-MCP and various community 'MCP Top 10' write-ups all cover similar ground. This page maps Enforgate's actual shipped controls to those categories. It is not a certification against any specific named framework — treat it as an honest engineering statement, and verify anything load-bearing for your own risk assessment.

See also the OWASP Agentic AI Top 10 page, which covers a broader set of agent-behavior risks (ASI01–ASI10); this page is scoped specifically to risks that come from the MCP protocol and the server-connection model.

Tool poisoning & rug-pull updates

Covered

A previously-trusted MCP server's tool definitions change after the fact — silently swapping in a different (malicious) behavior behind a name you already approved.

Manifest pinning: a SHA-256 hash of a server's tool list is captured on first connect; any change triggers an upstream_tools_changed alert.
Ed25519 identity challenge on connect for registry entries with a published public key.

Supply-chain trust of MCP servers

Covered

Connecting to a malicious or unverified MCP server in the first place.

A per-org trusted registry (publisher, version, optional public key) — connections outside it are flagged.
Connected Tool configuration is org-scoped and developer-role-gated; an agent can't add its own connections.

Confused deputy / tool name collisions

Covered

Two connected servers exposing a same-named tool, or a policy rule accidentally matching the wrong server's tool.

Every tool is namespaced <name>__<tool> at the proxy layer — policies match the specific server and tool, never an ambiguous bare name.

Excessive permission scope

Covered

An agent (or a leaked credential) ending up with broader tool access than the task in front of it needs.

Short-lived bws_ session tokens scoped to a glob subset of tools, minted from a long-lived key.
Argument-level policy conditions (e.g. allow db.query SELECT, deny DROP/TRUNCATE/DELETE) — not just tool-name allow/deny.

Indirect prompt injection via tool responses

Partial

Instructions hidden inside a tool's RESPONSE (a fetched webpage, a document, an email) that try to redirect the agent's next actions.

Deterministic pattern scanner on tool-call ARGUMENTS at the gateway (opt-in).
Response-side DLP catches secrets/PII in responses, but full taint-tracking that follows untrusted response content into subsequent tool calls is not yet built.

Session & credential hijacking

Covered

A leaked API key or session token granting indefinite, full access.

Keys are stored as a SHA-256 hash, never in the clear; a leaked database can't be used to authenticate.
Session tokens expire (default 1h) independent of the parent key, and can be scoped and revoked individually.

Sandboxing & execution isolation

Roadmap

Whether a tool call actually executes inside an isolated environment (a container, a VM) once it leaves the gateway.

Deliberately out of scope to build: Enforgate exports the allow/deny/approval decision at the action boundary; your runtime is responsible for the isolation it executes within.