hermes - 💡(How to fix) Fix [Bug]: runs api accepts previous_response_id without auth when API_SERVER_KEY is unset [1 pull requests]

Bug Description

I found a security-sensitive inconsistency in the API server runs endpoint.

POST /v1/runs currently accepts previous_response_id even when API_SERVER_KEY is not configured.

That means an open API server can still attach a new run to server-stored conversation state without API key protection.

What I expected instead was for server-side continuation through previous_response_id to require API key auth, consistent with the other stateful continuation paths in the API server.

Steps to Reproduce

1. Start the API server without API_SERVER_KEY
2. Ensure the server has a stored response id available
3. Send POST /v1/runs with an input value and previous_response_id set to that stored response id
4. Observe that the run is accepted and started

Expected Behavior

POST /v1/runs should reject previous_response_id when API_SERVER_KEY is unset, because it relies on server-side stored conversation state.

Actual Behavior

When API_SERVER_KEY is unset, the Responses endpoint still accepts previous_response_id and conversation and proceeds with server-side continuation instead of rejecting the request.

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

No response

Debug Report

Report     https://paste.rs/jU8iN
agent.log  https://paste.rs/TShlG

Operating System

Ubuntu on WSL2 (Windows 11)

Python Version

Python 3.12.3

Hermes Version

Hermes Agent v0.15.1 (2026.5.29)

Additional Logs / Traceback (optional)

I reproduced this with a focused endpoint test against the current code.

Expected:
- unauthenticated `POST /v1/runs` with `previous_response_id` should be rejected with 403 when `API_SERVER_KEY` is unset

Actual:
- the request is accepted with HTTP 202 and the run starts

Root Cause Analysis (optional)

In gateway/platforms/api_server.py, _handle_runs accepts previous_response_id and resolves stored conversation history from the response store, but it does not apply a feature-specific auth gate before doing so.

That leaves a stateful server-side continuation path available on open servers even though this behavior depends on previously stored response state.

Proposed Fix (optional)

Reject previous_response_id on POST /v1/runs unless API_SERVER_KEY is configured.

I also prepared a focused regression test that expects the endpoint to return 403 instead of 202 for unauthenticated server-side chaining on an open server.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR