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 and Infographic
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, each tenant's agent run must use its own scoped credential. Shared tokens are the most common cause of cross-tenant access in GitHub remote MCP configurations. The exam tests whether you know to isolate credentials per tenant, not per run.
Full explanation below image
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 repo 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.
Option A 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.
Option B 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.
Option C is correct. The most common misconfiguration in multi-tenant CI pipelines is using a shared organization-level GitHub App token or PAT across all tenant runs. The correct approach is to provision per-tenant tokens — ideally via GitHub App installation tokens scoped to each tenant's organization — and inject them at runtime so each agent session authenticates as that specific tenant.
Option D 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.