Problem
The MCP gateway processes tools/call requests for tools that are not in the agent's --allowed-tools list. The --allowed-tools filtering only happens client-side (in the AI engine client), not at the gateway layer. An agent with bash access can bypass this by calling the gateway directly via curl with the bearer token from the plaintext MCP config.
Evidence
From pentest finding githubnext/gh-aw-security#1706:
- Tools like
get_teams and get_team_members are absent from the --allowed-tools list but are returned by tools/list and successfully executed when called directly via HTTP.
- The gateway returns a GitHub API-level response (e.g., 403 from GitHub's own scope limits), not an MCP-layer rejection.
- This contradicts the architecture docs which state tool filtering "occurs before the AI engine receives tool information, operating at the MCP gateway level" and that "unlisted tools [are] blocked."
Reproduction
- Run a
github-readonly workflow with bash tool access
- Read the bearer token from
/tmp/gh-aw/mcp-config/mcp-servers.json
- Send a direct
tools/call JSON-RPC request to the gateway for a tool not in --allowed-tools
- Observe: gateway executes the call instead of rejecting it
Expected: Gateway rejects with MCP-level error (HTTP 403 or JSON-RPC permission denied)
Observed: Gateway executes the call and returns the upstream API response
Suggested Mitigations
- Enforce
--allowed-tools at the gateway layer — reject tools/call for tools not in the per-session allowlist
- Per-session scoped tokens — bind bearer tokens to allowed tool sets so direct HTTP calls can't invoke out-of-scope tools
- Restrict MCP config file permissions —
/tmp/gh-aw/mcp-config/mcp-servers.json is currently world-readable; restrict to agent process user only
References
- Pentest finding: githubnext/gh-aw-security#1706
- Prior finding (same issue, older versions): githubnext/gh-aw-security#1519
- Tested on: awmg v0.2.11, gh-aw v0.65.6
Problem
The MCP gateway processes
tools/callrequests for tools that are not in the agent's--allowed-toolslist. The--allowed-toolsfiltering only happens client-side (in the AI engine client), not at the gateway layer. An agent withbashaccess can bypass this by calling the gateway directly viacurlwith the bearer token from the plaintext MCP config.Evidence
From pentest finding githubnext/gh-aw-security#1706:
get_teamsandget_team_membersare absent from the--allowed-toolslist but are returned bytools/listand successfully executed when called directly via HTTP.Reproduction
github-readonlyworkflow withbashtool access/tmp/gh-aw/mcp-config/mcp-servers.jsontools/callJSON-RPC request to the gateway for a tool not in--allowed-toolsExpected: Gateway rejects with MCP-level error (HTTP 403 or JSON-RPC permission denied)
Observed: Gateway executes the call and returns the upstream API response
Suggested Mitigations
--allowed-toolsat the gateway layer — rejecttools/callfor tools not in the per-session allowlist/tmp/gh-aw/mcp-config/mcp-servers.jsonis currently world-readable; restrict to agent process user onlyReferences