#23814: Gateway: block unauthenticated tool-invocation HTTP surfaces

## Summary Describe the problem and fix in 2–5 bullets: - Problem: - Why it matters: - What changed: - What did NOT change (scope boundary): ## Change Type (select all) - [ ] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes List user-visible changes (including defaults/config). If none, write `None`. ## Security Impact (required) - New permissions/capabilities? (`Yes/No`) - Secrets/tokens handling changed? (`Yes/No`) - New/changed network calls? (`Yes/No`) - Command/tool execution surface changed? (`Yes/No`) - Data access scope changed? (`Yes/No`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: - Runtime/container: - Model/provider: - Integration/channel (if any): - Relevant config (redacted): ### Steps 1. 2. 3. ### Expected - ### Actual - ## Evidence Attach at least one: - [ ] Failing test/log before + passing after - [ ] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - Edge cases checked: - What you did **not** verify: ## Compatibility / Migration - Backward compatible? (`Yes/No`) - Config/env changes? (`Yes/No`) - Migration needed? (`Yes/No`) - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Files/config to restore: - Known bad symptoms reviewers should watch for: ## Risks and Mitigations List only real risks for this PR. Add/remove entries as needed. If none, write `None`. - Risk: - Mitigation: <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds security hardening to block unauthenticated access to tool-invocation and model HTTP endpoints when the gateway runs with `auth.mode=none`. - **Runtime guards**: Adds 403 "forbidden" responses in `tools-invoke-http.ts`, `openai-http.ts`, and `openresponses-http.ts` when `auth.mode === "none"`, preventing tool execution and model access without authentication. - **Startup validation**: Adds a fail-fast check in `server-runtime-config.ts` that prevents the gateway from starting if `auth.mode=none` is combined with enabled HTTP model endpoints (`/v1/chat/completions` or `/v1/responses`). - **Defense-in-depth**: The runtime 403 checks in the OpenAI and OpenResponses handlers serve as safety nets — in normal operation, `server-http.ts` already gates these handlers behind `openAiChatCompletionsEnabled`/`openResponsesEnabled` flags, and the startup validation prevents those flags from being enabled when auth is none. The runtime checks protect against future refactoring or direct handler invocations. - **Test coverage**: Adds tests for the `/tools/invoke` auth-mode-none rejection and the startup validation for both model endpoints. No tests were added for the runtime 403 paths in `openai-http.ts` and `openresponses-http.ts` (these are covered indirectly through the startup validation tests). - **Note**: The PR description template is unfilled — no summary, change type, security impact, or verification steps are documented. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge — it only adds restrictive checks that block access, with no risk of breaking authenticated flows. - The changes are straightforward security guards that reject requests early when auth is disabled. The logic is simple (mode equality checks), consistently applied across all three HTTP surfaces, and backed by test coverage. The startup validation provides fail-fast protection. Score is 4 rather than 5 due to the completely empty PR description and missing tests for the runtime 403 paths in openai-http.ts and openresponses-http.ts. - No files require special attention — all changes are additive guards with no modifications to existing logic paths. _{Last reviewed commit: 260de77} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->