The MCP server cannot serve security-restricted bugs to users who already have access to them

[joewalker]

Context: I asked Claude to get me the details of a security bug. It proposed some bad-for-us suggestions without any good ones. I have access to some security bugs, so I think I should be able to do this in an official way rather than be steered to a hacky and dangerous way.

(Aside: It discovered that it could actually find out a lot about a security bug using moz-phab. It also suggested I install https://github.com/python-bugzilla/python-bugzilla or putting an API key in ~/.config/bugzilla/curlrc)

It seems to me that the best option would be to allow the user to configure an API key or use OAuth or similar to allow the MCP to act as me.

[joewalker]

For what it's worth Claude wrote me this bug report. Pasting here in case it's useful.

---

Summary

The hosted Firefox Development MCP server (https://mcp-dev.moz.tools/mcp) refuses every Bugzilla bug that has a non-empty groups list. For anyone working on security bugs this makes get_bugzilla_bug unusable — an engineer with full access to a restricted bug still gets told it does not exist.

The blocker is not a missing Bugzilla credential. bugbug already supports one, and the Bug.get() API already has an allow_private switch. What is missing is a way for the hosted server to know who is asking, which is the only thing that would make enabling that switch safe.

Steps to reproduce

1. Point an MCP client at https://mcp-dev.moz.tools/mcp (e.g. the .mcp.json shipped in mozilla-firefox/firefox).
2. Call get_bugzilla_bug with the ID of any bug in a security group — one you have full access to in the Bugzilla web UI.

Expected: the bug, since the caller is authorised to read it.

Actual:

Error calling tool 'get_bugzilla_bug': Bug <id> not found

The same happens via the bugzilla://bug/{bug_id} resource. Public bugs work fine, so this is specifically the restricted-bug path.

Root cause

Pinned to 311aa75f18754bfca3757fc467c06fd7c61219c8:

• bugbug/tools/core/platforms/bugzilla.py#L419-L429 — Bug.get() takes allow_private: bool = False and raises when the flag is off and the bug has groups:

  if not bugs or (not allow_private and bugs[0]["groups"]):
      raise ValueError(f"Bug {bug_id} not found")

• services/mcp/src/bugbug_mcp/server.py#L72-L75 — the tool calls SanitizedBug.get(bug_id) and never passes allow_private, so it is hardwired off. Same for the resource handler at #L62-L69.

• bugbug/tools/core/platforms/bugzilla.py#L51 — BugzillaBase.TOKEN = os.getenv("BUGZILLA_API_KEY"), i.e. the deployment already has a slot for a server-side key.

The current behaviour looks deliberate and correct for the deployment as it stands: mcp-dev.moz.tools is unauthenticated, so if a server-side BUGZILLA_API_KEY were allowed to reach private bugs, every caller would inherit that key's access. Refusing outright is the safe default. The gap is that there is no per-user identity, so the safe default is the only option.

Impact

Anyone doing security work has to drop out of the MCP tooling entirely and fall back to the Bugzilla REST API with a personal API key, or read the bug in a browser. That splits the workflow: the MCP server remains the nicest reader available for public bugs (change history interleaved with comments, the untrusted-author sanitisation, markdown output), and none of that is available exactly where the context is hardest to reconstruct by hand.

Design constraint: the credential must never reach the model's context

Whatever mechanism is chosen, the caller here is an LLM agent, so there is a constraint that does not apply to an ordinary web service: any secret the model has to emit is a disclosed secret. It lands in the model's context, in the conversation transcript, and in anything that logs tool calls — all of which typically outlive the session and are not credential stores.

Concretely, this rules out the most obvious implementation:

# DO NOT do this - forces the model to emit the key on every call
@mcp.tool()
def get_bugzilla_bug(bug_id: int, api_key: str | None = None) -> str: ...

Safe designs keep the credential at the transport layer, where the MCP client attaches it and the model never observes it. Two supporting details:

• Configuration should not require pasting the key into a file an agent then reads. Clients that support environment-variable interpolation in MCP config (Claude Code does) let the config hold ${BUGZILLA_API_KEY} while the value stays in the environment or a keychain.
• Errors must never echo the credential. Tool errors are returned to the model, so a "bad key: <value>" message discloses it just as effectively as a parameter would.

Possible approaches

Ordered by how well they satisfy the constraint above:

1. OAuth against BMO. Best on both counts: the client runs the flow and holds the token, so it never enters model context, and access is scoped and revocable per user. mcp-dev.moz.tools currently serves 404 on both /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server, so there is no discovery today; MCP clients broadly support the flow now.
2. Caller-supplied Bugzilla API key, as an X-BUGZILLA-API-KEY request header passed through to libmozdata for that request only, with allow_private=True. Access is then exactly the caller's own Bugzilla access, with no shared-credential problem. Safe only in the transport-header form — see the constraint above. Also worth noting a Bugzilla API key carries full write authority for the account, so the server should only ever use it for reads; OAuth avoids that over-provisioning too.
3. Keep the hosted deployment public-only, and document a self-hosted mode. If per-user auth is out of scope, it would help to say so explicitly and describe running the server locally with your own BUGZILLA_API_KEY plus allow_private=True. No disclosure risk, since the key stays in the server process's environment, but it gives up the convenience of the hosted endpoint.

Option 1 seems worth it given how much of the value is on restricted bugs.

Separable smaller fix: the error message is misleading

Independent of any auth work, raise ValueError(f"Bug {bug_id} not found") reports a permission refusal as a non-existent bug. That sends people off checking whether they typo'd the bug number. Distinguishing the two cases — something like "Bug <id> is access-restricted and this server is unauthenticated" — would be a small change that saves real debugging time, and it leaks nothing beyond what the caller supplied.

Related

• Support authentication through service accounts #6472 (Support authentication through service accounts) — related but pointed the other way: services authenticating outward, rather than authenticating an inbound caller. Worth deciding whether they share a mechanism.
• Sanitize the Bugzilla search results #5890 — the reason bugzilla_quick_search is disabled at server.py#L26. Not this issue, but it compounds it: no search and no private bugs.

Environment

• Server: https://mcp-dev.moz.tools/mcp, serverInfo.name "Firefox Development MCP Server", FastMCP 3.4.2
• Client: Claude Code via the .mcp.json in mozilla-firefox/firefox
• Public bugs read correctly through the same client and endpoint