Securing MCPs
MCP expands what agents can do, but it also expands the blast radius of a bad decision. Highflame treats MCP as a protected execution surface rather than a direct client-to-tool connection.
The Gateway As The Trust Boundary
The primary security boundary is the gateway itself. MCP clients connect to Firehog, not directly to the downstream server. That lets Highflame enforce a consistent flow:
authenticate the client
resolve tenant and project scope
route only to registered MCP servers
allow only enabled tools
run guardrails and policies where configured
capture the request, response, and decision metadata
This makes access explicit and revocable. If a server is removed from the registry or a tool is disabled, the client loses access through the control plane without needing changes on every endpoint.
Tool Exposure Is Explicit
Server registration does not mean every tool should be live immediately. The safer operating model is:
register the MCP server
discover the tools it exposes
enable only the tools your agents actually need
attach policies before broad rollout
That keeps availability separate from permission and reduces accidental overexposure.
Downstream Credentials Stay Off The Client
For third-party servers that require user-specific OAuth tokens, Highflame uses a token broker model. MCP registry retrieves the user's downstream token from the platform and injects it while forwarding the request.
This has two security benefits:
the MCP client only authenticates to Highflame
downstream provider credentials are stored and handled server-side rather than spread across developer workstations and agent runtimes
Guardrails On Tool Traffic
Shield can evaluate MCP requests and responses as part of the gateway flow. This gives you a place to catch issues such as:
prompt injection or hidden instructions coming back from a tool
sensitive data leaving a tool response
dangerous tool invocations based on arguments or context
policy violations tied to environment, project, or risk posture
Because the same Cedar policy model is used across the platform, tool security can be governed with the same policy language used for other runtime controls.
Observability And Auditability
Every MCP interaction should be visible after the fact. Highflame records the evidence needed to answer questions like:
which tool was invoked
which project and identity initiated it
whether the action was allowed, denied, or modified
which policies or signals influenced the outcome
how often a server or tool is used over time
Those records flow into Observatory, where teams can investigate the event, the surrounding session, and the related trace instead of relying on scattered client logs.
Last updated