Your organization runs a GitHub Actions-based multi-agent pipeline that serves three different tenant teams, each with their own GitHub organization. Agents use GitHub's remote MCP server to perform repository operations. During a pipeline run for Tenant A, you discover that an agent successfully called a GitHub MCP tool using Tenant B's repository context. What is the most likely root cause?
Select an answer to reveal the explanation.
Short Explanation
This is like handing one master key to every tenant in an apartment building — of course someone ends up in the wrong unit. In multi-tenant CI, you must give each tenant's agent run its own scoped credential. Shared tokens are the most common cause of cross-tenant access in GitHub remote MCP configurations.
Full Explanation
The GitHub remote MCP server authenticates and authorizes tool calls based on the credential provided during the MCP session. If a single shared GitHub token with broad repository access is configured at the runner level and reused across all tenant pipeline runs, then any agent invocation in any tenant's pipeline will operate under that token's full permission scope — including access to repositories owned by other tenant organizations. The exam tests whether you know to isolate credentials per tenant, not per run.
The claim that the GitHub remote MCP server does not enforce organization-level boundaries is wrong. GitHub's remote MCP server absolutely enforces organization and repository boundaries based on the authenticated token. It does not inherently allow cross-tenant access; the token must have explicit access. If cross-tenant access is happening, the token was granted it — intentionally or accidentally.
The rate-limiter session-merge explanation is wrong. MCP sessions are not merged by rate limiters. Rate limiting controls request frequency, not session state. While MCP session management is important, a rate limit timeout does not cause tenant context to bleed between sessions. This is not a documented failure mode of the GitHub remote MCP server.
The response-caching explanation is wrong. The GitHub remote MCP server is a stateless API proxy; it does not cache tool responses and replay them to different sessions. Each tool call is a discrete authenticated API request. Response caching that crosses session boundaries is not a known behavior of this server.