# Delphi Panel: Endpoint Allowlist

**Date:** 2026-02-27
**Panel ID:** panel-970cf404
**Panelists:** Systems Architect, Skeptic, Pragmatist (timed out), Security Engineer, UX Advocate

## Systems Architect

Framed as a shift from execution-time filtering to schema-level gating. Current model:
the LLM sees everything but certain operations are blocked at call time. Target model:
filter sits between schema acquisition and agent construction.

Key recommendations:
- Config file as base, headers as session override, intersection semantics
- Headers can only narrow, never widen
- Glob patterns (fnmatch-style) — regex overkill, exact match too rigid
- Filter at schema level to prevent token waste and hallucination

Called out the architectural difference: `X-Allow-Unsafe-Paths` is execution-time
(LLM sees but can't call), while the allowlist should be schema-time (LLM never sees).

## Skeptic

Challenged the premise with three pointed questions:

1. **"Large APIs where users only need a subset"** — Schema truncation at 32k chars
   already handles this. Is the real problem that truncation is *dumb* (alphabetical)?
2. **"Security-conscious deployments"** — What's the threat model? The LLM is read-only.
   If someone can set X-Target-URL, they already have API access.
3. **"Reducing LLM confusion"** — This is the real value. But is an allowlist the right
   fix, or should we improve schema ranking/prioritization?

Flagged a **showstopper**: `search_schema` searches `_raw_schema` ContextVar which
stores the full unfiltered schema. If we filter the DSL but leave `_raw_schema` intact,
the LLM can discover blocked endpoints through search. The raw schema MUST be filtered
too.

Concluded: the feature is worth building if we commit to schema-level filtering. But
if motivation is primarily LLM quality (not security), smarter schema ranking could be
a cheaper first step.

## Security Engineer

Did a deep codebase audit and flagged 7 pre-existing vulnerabilities, rating SSRF via
`X-Target-URL` as critical. Positioned the allowlist as defense-in-depth that partially
mitigates several existing risks.

Key security recommendations:
- Config-file PRIMARY, headers as opt-in override — headers are client-controlled, so
  a header-only allowlist can be bypassed by the same attacker who can set X-Target-URL
- The allowlist should be treated as a security boundary, not just a UX feature
- Recipe filtering is mandatory — cross-session recipe store could leak blocked endpoints
- No gRPC mutation blocking exists today; allowlist partially compensates

## UX Advocate

Mapped four user personas: MCP client developer, end user, ops engineer, API owner.
Framed the allowlist as primarily a **quality-of-experience feature**: fewer endpoints =
more focused agent = better answers.

Key UX recommendations:
- Config file = "deploy-time guardrail" (ops), header = "request-time focus lens" (dev)
- Intersection semantics = principle of least surprise for security-conscious users
- Error messages should clearly explain when an endpoint was filtered vs not found
- Consider a "discovery mode" where the LLM can list what's allowed

## Pragmatist

Timed out at 301s. No output recovered.

## Panel Consensus

Strong agreement on: allowlist (not blocklist), glob patterns, config + header with
intersection semantics, schema-level filtering (not tool-level).

Main tension: Security Engineer wants this treated as a security boundary; Skeptic
questions whether the complexity is justified if the primary goal is LLM quality.
Resolution: build it as a security boundary (schema-level filtering) because the
marginal cost over tool-level filtering is small and the security properties are
significantly better.
