Improvement Description
The MCP management endpoints exposed by backend/mcp_service.py currently accept an Authorization header but do not validate it before returning success.
This matters because the default Docker deployment publishes 5015:5015, so the management API is reachable as a network surface rather than only as an internal helper.
In local validation, both of the following succeeded without any authorization check:
GET /tools/outer_api
POST /tools/outer_api/refresh?tenant_id=<tenant>
This looks inconsistent with Nexent's existing MCP authorization direction from #2086 / #2558, where authorization support was added for MCP services.
Proposed Solution
A small hardening step would be:
- require validated authorization on the MCP management endpoints;
- forward the current request's authorization token from the tool-management call path when refreshing or deleting outer API tools;
- add regression tests covering both authorized and unauthorized access.
Additional Information
I already prepared and locally validated a minimal patch for the auth-hardening path only, without mixing in the larger API-to-MCP design questions.
Improvement Description
The MCP management endpoints exposed by
backend/mcp_service.pycurrently accept anAuthorizationheader but do not validate it before returning success.This matters because the default Docker deployment publishes
5015:5015, so the management API is reachable as a network surface rather than only as an internal helper.In local validation, both of the following succeeded without any authorization check:
GET /tools/outer_apiPOST /tools/outer_api/refresh?tenant_id=<tenant>This looks inconsistent with Nexent's existing MCP authorization direction from
#2086/#2558, where authorization support was added for MCP services.Proposed Solution
A small hardening step would be:
Additional Information
I already prepared and locally validated a minimal patch for the auth-hardening path only, without mixing in the larger API-to-MCP design questions.