fix: correct field name to allowed_mcp_servers

PR #118 finding F1 (low): The deployed LiteLLM on CT 116 uses allowed_mcp_servers (193 occurrences in installed package), not bare allowed_mcp. One-word doc fix.
fix: consolidate PR #117 Rule 15 wording fix
2026-09-18 18:49:20 +00:00 · 2026-09-18 18:38:38 +00:00 · 2026-09-18 18:34:31 +00:00
3 changed files with 13 additions and 10 deletions
@@ -278,7 +278,10 @@ def audit(path):
            # Check endpoint validity
            if server_name in VALID_MCP_ENDPOINTS:
                expected = VALID_MCP_ENDPOINTS[server_name]
-                check(url == expected, 'Rule 15', f'MCP server "{server_name}" URL is correct: {url}')
+                if url == expected:
+                    check(True, 'Rule 15', f'MCP server "{server_name}" URL is correct: {url}')
+                else:
+                    check(False, 'Rule 15', f'MCP server "{server_name}" URL is incorrect: {url} (expected: {expected})')
            else:
                warn('Rule 15', f'MCP server "{server_name}" URL may need validation (not in known list): {url}')
            
@@ -243,8 +243,8 @@ MCP server entries in `mcp_servers:` must follow the format shown in the Templat
 - Tested MCP initialize handshake against litellm.sysloggh.net/mcp with agent virtual key
 - Confirmed: 200 response with `serverInfo.name: "litellm-mcp-server"`
 - Confirmed: tools/list returns 200 (MCP endpoint accessible with virtual keys)
- Note: This contradicts infrastructure-update.prose.md:214 ("only master key has access") —
-  the LiteLLM version may have been upgraded since that contract was written
+- Note: Per-key MCP grants are now supported (verified 2026-09-18), resolving the earlier
+  contradiction with infrastructure-update.prose.md (which now reflects the update)
 - Key requirement: must be a valid LiteLLM virtual key (HTTP 200 on /v1/models)

 **Key rotation note:**
@@ -208,19 +208,19 @@ mcp_servers:
 | Key | MCP Access |
 |-----|-----------|
 | Master key | ✅ Full — 90 tools (vault-injected) |
-| Agent keys (mumuni, tanko, etc.) | ❌ Per-key grants not supported in v1.99.1 |
+| Agent keys (mumuni, tanko, etc.) | ✅ Per-key grants supported (as of 2026-09-18 verification) |

 ### Known Limitations
- Per-key MCP server grants not functional — only master key has access
+- ~~Per-key MCP server grants not functional — only master key has access~~ (resolved 2026-09-18: per-key grants now work)
 - Responses API (`/v1/responses`) with MCP tools broken on llama.cpp backends
 - HTTP 307 redirect on `/mcp` → use `/mcp/` (trailing slash) or `/mcp-rest/` endpoints
 - `api_mode: responses` in Hermes appends `/v1/responses` to base_url → **base_url must end at `/v1`, never `/responses`** (double-path bug)

-### Migration Path
-When LiteLLM is upgraded to a version supporting per-key MCP grants:
-1. Grant agent keys `mcp_servers: ["ra_h_os"]`
-2. Update Hermes `mcp_servers.ra-h-os.url` from `http://192.168.68.65:3100/mcp` → `http://192.168.68.116:4000/mcp/`
-3. Add `headers: {x-litellm-api-key: "Bearer $LITELLM_API_KEY"}` to MCP config
+### Migration Path (COMPLETED 2026-09-18)
+Per-key MCP grants are now supported:
+1. ✅ Agent keys granted MCP access via `allowed_mcp_servers` field
+2. ✅ Hermes `mcp_servers.litellm.url` set to `https://litellm.sysloggh.net/mcp`
+3. ✅ `headers: {x-litellm-api-key: "Bearer <literal_key>"}` added to MCP config

 ## Security-Specific Updates
Author	SHA1	Message	Date
root	f77d6ca1d1	fix: correct field name to allowed_mcp_servers PR Pipeline — Authorize → Validate → Review → Merge / auth (pull_request) Successful in 2s Details PR Pipeline — Authorize → Validate → Review → Merge / validate (pull_request) Successful in 8s Details PR Pipeline — Authorize → Validate → Review → Merge / ai-review (pull_request) Successful in 5s Details PR Pipeline — Authorize → Validate → Review → Merge / lint (pull_request) Successful in 5s Details PR Pipeline — Authorize → Validate → Review → Merge / gate (pull_request) Successful in 2s Details PR #118 finding F1 (low): The deployed LiteLLM on CT 116 uses allowed_mcp_servers (193 occurrences in installed package), not bare allowed_mcp. One-word doc fix.	2026-09-18 18:49:20 +00:00
root	f4f8a4cab8	fix: consolidate PR #117 Rule 15 wording fix PR Pipeline — Authorize → Validate → Review → Merge / auth (pull_request) Successful in 12s Details PR Pipeline — Authorize → Validate → Review → Merge / validate (pull_request) Successful in 3s Details PR Pipeline — Authorize → Validate → Review → Merge / lint (pull_request) Successful in 3s Details PR Pipeline — Authorize → Validate → Review → Merge / ai-review (pull_request) Successful in 3s Details PR Pipeline — Authorize → Validate → Review → Merge / gate (pull_request) Successful in 1s Details Add the audit-hermes-config.py Rule 15 wording fix from PR #117: - Violation message now reads 'URL is incorrect: <url> (expected: <expected>)' - Detection logic unchanged - Matches URL and not-in-known-list branches remain byte-identical This consolidates relay #779 into a single PR (#118).	2026-09-18 18:38:38 +00:00
root	c0454811bb	fix: update MCP access docs to reflect per-key grants support PR Pipeline — Authorize → Validate → Review → Merge / auth (pull_request) Successful in 5s Details PR Pipeline — Authorize → Validate → Review → Merge / validate (pull_request) Successful in 9s Details PR Pipeline — Authorize → Validate → Review → Merge / lint (pull_request) Successful in 6s Details PR Pipeline — Authorize → Validate → Review → Merge / ai-review (pull_request) Successful in 6s Details PR Pipeline — Authorize → Validate → Review → Merge / gate (pull_request) Successful in 1s Details PR #117 follow-up (verify PASS-WITH-FINDINGS): 1. infrastructure-update.prose.md: - Update access table: agent keys now have per-key MCP grants (2026-09-18) - Strike-through old limitation: per-key grants now work - Mark Migration Path as COMPLETED 2026-09-18 2. hermes-config-template.prose.md: - Remove hedge ('may have been upgraded') - State fact: per-key MCP grants verified 2026-09-18 This resolves the contradiction where one file asserted per-key MCP access and the other denied it.	2026-09-18 18:34:31 +00:00