NLWeb Security: A Route-by-Route Deployment Guide

NLWeb turns structured website data into a conversational interface for people and agents. Its request path crosses several control planes: the public application route, optional account services, retrieval, response generation, memory and outbound model providers. A secure deployment assigns each boundary separately. Calling the whole stack an "MCP security problem" hides the route that made the decision.

TL;DR

• Protect /ask and /mcp as application endpoints with authentication, authorization, rate limits and request validation.
• Treat site selection, retrieval access, memory and MCP tool calls as separate policy decisions owned by NLWeb and its connected services.
• Route outbound LLM HTTP calls through an identity-aware policy point only when you need prompt and response controls there.
• Replay each model route and verify the decision record before declaring the deployment covered.

Draw the NLWeb request path first

The NLWeb project describes a conversational interface for websites that uses structured data such as Schema.org and RSS. Each NLWeb instance can also act as an MCP server, giving people and agents access to the same natural-language interface. The repository supports multiple retrieval backends and LLM providers. Those choices create several boundaries rather than one security perimeter. Start with a sheet of paper. Draw the browser or agent on the left, /ask and /mcp in the middle, and retrieval plus the selected LLM provider on the right. Add memory, OAuth and tools only when the deployment enables them. I prefer this plain diagram to a glossy architecture deck because an unlabeled arrow becomes obvious when it ends at a real hostname.

For every arrow, record the protocol, credential, caller identity, resource, data class, policy owner, log destination and bypass route. The result should align with the AI gateway security model: each inspected HTTP route has a defined caller and destination. Traffic outside that route needs another control.

Secure /ask and /mcp as application endpoints

The NLWeb REST API documentation defines two endpoints, /ask and /mcp. Both endpoints share most arguments. /mcp formats answers for MCP clients and supports core methods including list_tools, list_prompts, call_tool, and get_prompt. The documented request can carry a natural-language query, a site token, previous queries, previous answers, a streaming flag, a query ID, and a mode. These endpoints need ordinary application controls. Authenticate the caller where the deployment requires private access. Authorize access to the selected site and method. Validate payload size and accepted fields. Rate-limit by identity and route, then set timeouts for streaming connections. Log the authenticated principal, route, method, selected site, query ID, outcome and latency without copying sensitive prompt text into an unrestricted access log.

Keep /ask and /mcp authorization in the NLWeb application or its API edge. An outbound LLM gateway sees a later request to a model endpoint. It cannot decide who may call list_tools unless that exact action is represented in the routed model request, which would be a brittle substitute for endpoint authorization.

Site selection and retrieval need resource authorization

The site argument can restrict a query to a subset of backend data. That makes the site token a resource selector, not proof of permission. Resolve it against the authenticated caller before retrieval starts. A caller allowed to search a public catalog may still lack access to an employee handbook or customer-support archive hosted by the same NLWeb deployment.

Apply the same rule inside the retrieval adapter. Scope search credentials to the smallest index or collection the NLWeb service needs. Filter documents using the caller's entitlements when private content is mixed in one store. Record the result identifiers or stable hashes returned to response generation, subject to data-retention rules. A later model policy decision cannot repair a retrieval layer that already returned an unauthorized document.

Test with two visually similar records, one permitted and one denied. Put them next to each other in the index and query for their shared phrase. The permitted principal should receive only the first record. The denied principal should get no content fragment, title, metadata or existence hint from the second.

Conversation context and memory have separate custody

NLWeb can receive previous queries and answers as request arguments, and its system map includes conversation-management services in deployments that use them. Treat client-supplied context as untrusted input. Bind server-side conversation records to the authenticated account, reject cross-account identifiers and cap the amount of history included in a new request.

Memory needs a written retention and deletion policy. Record where a remembered item is stored, which identity can read it, and how it is removed. If memory is used in retrieval or generation, mark its provenance so an incident reviewer can distinguish a current query from saved context. The LLM data leakage guide is relevant here because old context can place sensitive data into a later prompt even when the new query looks harmless. Avoid treating a model provider's no-training term as a memory control. Provider handling governs the destination after transmission. NLWeb still owns what it retrieves, saves and attaches before that call.

Modes change the outbound model-call surface

The REST documentation lists list, summarize, and generate modes. List mode returns top backend matches. Summarize adds a summary, while generate behaves more like a chatbot and may make one or more LLM calls. The NLWeb system map separates primary HTTP endpoints from query processing, retrieval and response generation. That separation should appear in the security worksheet.

Inventory every model call by mode and component. Capture the provider hostname and model, credential source, timeout, retry behavior, streaming behavior, prompt template, input data classes and response consumer. Include every configured fallback provider. A deployment can route its main generation call through a policy gateway while a summarizer or query rewriter still calls a provider directly. My opinion is blunt: coverage claimed at the SDK level is weak evidence. Prove it at the network destination. Deny direct egress to approved model hosts, allow the gateway route, and replay each mode. The test should show which call passed, which policy version evaluated it, and which direct path failed.

MCP methods and tool calls stay outside the model boundary

/mcp exposes MCP-facing behavior, including tool-related methods. Authorize tool discovery and invocation in the MCP server or tool broker. Validate tool arguments against a schema, constrain credentials used by the tool, and apply destination-specific controls. A tool that writes to a ticketing system or queries a private database acts on a different resource than an LLM completion.

DeepInspect covers an authenticated HTTP request sent to an LLM when NLWeb deliberately routes that request through the proxy. Local execution, STDIO traffic, retrieval calls and downstream tool actions remain outside that boundary. The MCP security best-practices guide covers controls at the MCP and tool layers. Keep its evidence separate from the model-request record so an investigator can reconstruct both decisions. Use correlation IDs across the chain. One NLWeb query can produce retrieval events, several model calls, and a tool event. A shared trace key helps join them without pretending they share one authorization decision.

Deployment acceptance tests

Build a replay set before production. Include an anonymous /ask call if public access is supported, plus an authenticated call to a private site. Add a denied site selection, an oversized payload, a cross-account conversation identifier, and a streaming request that exceeds its time budget. Exercise list, summarize, and generate separately.

For /mcp, test method discovery and one allowed tool call. Add one denied method and one malformed argument set. For outbound model traffic, test the primary provider, every configured fallback and each component that can generate or summarize. Block direct provider egress during the test and confirm that approved traffic still works through the intended route. Save expected outcomes beside actual events. The acceptance packet should identify the NLWeb log, retrieval record, model-policy decision and tool audit event for each case. Missing evidence is a failed test, even when the user received the expected answer.

DeepInspect

DeepInspect can enforce identity-aware policy on NLWeb's outbound HTTP model calls when those calls are deliberately routed through its stateless proxy. It evaluates the supplied caller context, route, destination, prompt data and policy before forwarding an allowed request. Each evaluation produces a per-decision record for the model boundary.

Authentication for /ask and /mcp, site permissions, retrieval filtering, memory and tool execution remain with NLWeb and the connected services. Keep those controls in place, then join their logs to the model decision with a correlation identifier. Book a technical deep dive at deepinspect.ai.