Request Guard Defense Setup Assistant

Recorded acceptance-run output from Codex CLI 0.168.0 on Linux, November 13, 2026, using package 0.1.1 and released Rust server v1.0.0. All request fixtures were synthetic. Local filesystem paths are redacted; this is recorded output, not a live demo.

Request Guard connection review

Captured: 2026-11-13T07:13:58Z. Client: Codex CLI 0.168.0, Linux.
Skill: Defense Setup Assistant draft 0.1.1; target server: Rust v1.0.0.

Observed evidence

The configured request_guard MCP connection successfully completed actual health({}) and model_info({}) calls, both with isError: false.

• Health: overall healthy; server and cache healthy; GeoIP, PostgreSQL and Redis disabled. Reported uptime: 16 seconds.
• Identity: server/model version 1.0.0; reported commit 22a199a8cd0f7faf5f3e4493dc770e79d859680b; build date 2026-10-27T22:39:01Z.
• Metadata advertised 23 tools, including enabled classification and explanation tools. Those tools were not invoked in this connection-only review.

Result: the configured MCP client can communicate with the released server. Reported identity is server-provided metadata, not an independent binary attestation. The owner supplied a trusted, verified Rust v1.0.0 executable path; the separate packaged doctor helper was unnecessary and was not run.

Configuration review and limitations

No matching Request Guard server entry was found in the selected workspace/home .codex/config.toml locations. Effective endpoint host, transport, timeout and credential-presence settings therefore remain unverified. Successful tool calls alone do not establish those settings. No credential values were displayed or recorded.

No defense implementation, deployment configuration or adapter trace was supplied. No defense repositories were inspected, deployments started, integration probes performed, or configuration changed. The skill's compatibility record explicitly excludes live integrations; historical compatibility claims are not evidence from this run.

No AI Scraping Defense integration pass is claimed.

Evidence needed for a future setup review

1. Identify the actual implementation (Python/Nginx, .NET/IIS or Rust), exact release/commit, adapter/provider and whether optional MCP routing is enabled. Supply matching release-specific public adapter/configuration documentation before proposing field names; parity between implementations must not be assumed.
2. Supply selected sanitized configuration: endpoint host, transport, timeout, authentication presence only, and applicable proxy requirements. Distinguish local stdio from HTTP POST/custom WebSocket; do not assume SSE. Server and defense stack are separately installed.
3. Supply a sanitized adapter invocation/response trace showing method, path and user-agent mapping, classifier invocation, returned verdict and correlation with the adapter call. Demonstrate data minimization for bodies, cookies and authorization headers.
4. Supply evidence of timeout, partial-response, missing-tool, protocol-error and backend-failure handling. These represent unavailable outcomes, never implicit allow; document any explicit operator fallback policy.
5. Identify the separate enforcement decision and show how a verdict affects the request. Request Guard assesses metadata; it does not intercept traffic or enforce policy. Allow is not a safety finding, block is not proof of malicious intent, and user agents are self-declared.

Any future bounded integration probe requires authorization for that deployment. This report and all work remain private and unpublished; no skill or script was modified.