MCP gateway security model

What INFRO stores

• Server credentials, sealed. Header values are encrypted at rest with AES-256-GCM, bound to the organization and the server. No API, console screen, log line, error or OpenTelemetry span returns them; the console and the management API show only the header names. Replacing a credential is a write-only action.
• Tool definitions as the server listed them, the approved definition and its hash, and the scan findings.
• One record per call, metadata only by default: time, server, tool, outcome, error code, latency, argument and result sizes, a SHA-256 of the arguments, guardrail counts (never the matched text), and the key, project, environment and attribution. It is kept for the longest plan history window.
• Contents only when you opt in. Owners and admins can turn on Capture tool call contents, which requires prompt capture on the plan. Arguments and results are then kept with the organization's prompt-logging retention, up to 256 KB per call (marked truncated past it). A request sent with X-INFRO-Log-Payloads: false is never captured. Reading captured contents takes the same access as reading captured prompts.

With capture off, INFRO still processes tool arguments and results in transit, to validate them, apply guardrails and pass them on. It keeps none of them.

Credentials never reach the agent, and the INFRO key never reaches the server

• The agent holds only its INFRO gateway key. INFRO adds the server's sealed headers to each call.
• The server never sees the INFRO key, the agent's Authorization header or any X-INFRO-* header. It sees its own credential headers and the MCP protocol headers INFRO builds.
• A credential header may not be one the gateway sets itself: Host, Content-Length, hop-by-hop headers, traceparent, or names beginning Mcp-, X-INFRO-, X-Forwarded-, CF-, Sec- or Proxy- are refused.
• Mcp-Name and Mcp-Param-* are rebuilt from the pinned definition, never copied from the agent's request.

Where INFRO connects

• Server URLs must be public HTTPS. URLs with a user name or password, localhost, literal private and link-local addresses, and INFRO's own hosts are refused when the server is registered and again on every call.
• Redirects are never followed: a server that answers a call with a redirect gets upstream_unavailable.
• INFRO runs on Cloudflare Workers, which have no fixed outbound IP addresses. A server that only accepts calls from allowlisted IPs cannot be used through the gateway.
• A JSON Schema $ref to the network is never fetched. A tool whose schema needs one is refused at call time with invalid_tool_arguments.

INFRO executes nothing

INFRO does not run tools, host MCP servers or host agents. It is a proxy with policy: it decides whether a call may proceed, checks it, passes it on and checks the answer. It does not rewrite results beyond what your guardrail policy redacts. The server's own isError results reach the agent unchanged, with credential-shaped text removed from the message.

The definition scan

Every new or changed definition is scanned in INFRO for shapes associated with tool poisoning and shadowing. The scan is deterministic and calls nothing. Its findings are shown to the admin who reviews the tool. It never approves or blocks a tool by itself: a clean scan does not make a tool safe, and a flagged tool may be fine. It looks for:

• invisible or bidirectional Unicode: zero-width characters, tag characters, direction overrides;
• instruction-like phrases aimed at the model rather than describing the tool, such as "ignore previous", "do not tell the user", "before using any other tool" or <IMPORTANT>;
• mentions of another server's slug or tools, which can signal an attempt to shadow them;
• URLs and email addresses in descriptions;
• descriptions over 2,000 characters;
• write tools whose schema accepts any extra property;
• a $ref to the network;
• header annotations (x-mcp-header) the MCP specification does not allow;
• upstream names over 64 characters.

Guardrails on tool calls

Your organization's guardrail policies apply to tool calls under the same scopes as model calls (organization, project and key; the strictest action wins). The input stage checks the arguments and the output stage checks every text block and every string in structuredContent of the result. block refuses the call with guardrail_blocked, redact rewrites inside string values, and flag records counts only. The pattern detectors apply: email, phone, card, iban, ssn, ip, secret and deny_terms. Classifier checks are not applied to tool contents yet.

A secret in a tool's arguments is a common sign of an agent being steered into sending a credential out. A secret rule with block on the input stage refuses those calls:

{ "detector": "secret", "stage": "input", "action": "block" }

What is not supported yet

• Servers that only take OAuth sign-in, such as Notion, Vercel and Asana. Only servers that accept no authentication or a static credential in headers can be registered: a GitHub personal access token, a Linear API key, a Sentry user auth token (Sentry-Bearer), a Supabase access token, a Stripe agent key, Datadog keys, an Atlassian API token, and most internal servers.
• Servers on private networks or behind IP allowlists.
• Approval by a person for each write call. Today an admin decides per tool and per grant, ahead of time.
• Resources, prompts and list-change subscriptions. The gateway serves tools only.
• Provider-hosted connectors, until keys that can only reach the MCP gateway exist. See Connect an agent.