Enhancing MCP Server Security (Project Filtering & User-Specific Authentication)

[kenichiroMori]

Please correct me if my understanding or analysis is incorrect.

I strongly support the ongoing discussion in Issue #17 and PR #23 regarding the implementation of a project-level filter. This is a crucial "guardrail" to limit the overly broad permissions granted by the single BACKLOG_API_KEY.

However, as correctly pointed out in the comments of Issue #17, this filtering approach has a fundamental limitation.

This filter will not work for the 17+ tools (like getIssue, deleteIssue, etc.) that do not take a projectId as an argument. If a malicious (or mistaken) prompt specifies an issue key (e.g., SECRET-123) from a disallowed project, the server cannot prevent the operation.

---

[Long-Term Suggestion: Reconsidering the Authentication Model]

To solve this problem at its root and achieve enterprise-grade security, I propose a long-term migration from the current "single static API key" model to a "dynamic, per-user authentication" model.

The current architecture (a fixed BACKLOG_API_KEY in env) requires unconditional trust in the MCP server (and its operator). If the server is compromised, a powerful API key affecting all users is exposed.

If the core Backlog API could support a mechanism like OAuth 2.0 to issue temporary access tokens (※ I understand this is a very significant architectural change), the MCP server could operate as follows:

1. The AI agent (client) passes a "user's temporary token" with each request.
2. The MCP server uses that temporary token to execute the Backlog API call (inheriting the user's actual permissions).

This model would eliminate the need for the MCP server to hold a powerful "raw" API key and would fundamentally solve the permission issues discussed in Issue #17 (i.e., "User A can see it, but User B cannot").

---

[Summary]

1. Short-Term: The project filtering proposed in PR Implement project access guards #23 is necessary for immediate risk mitigation.
2. Long-Term: For truly secure, enterprise-level operation, could you please consider a future migration towards a per-user authentication model like OAuth 2.0?