Your MCP Server Can Reach Everything Its Token Can

Consider one ordinary request: an employee connects an AI assistant to a private GitHub repository, then asks it to summarize open security-review issues and identify the pull requests that address them.

A common setup runs GitHub’s MCP server locally in a container and passes it a personal access token through an environment variable. The assistant’s host application launches that server, reads its advertised tools, and lets the model request selected calls. The server uses the token to query GitHub, returns issue and pull-request data, and the host places some or all of that result into the model’s working context.

The important boundary is the token. MCP, or Model Context Protocol, standardizes how an AI application discovers and calls tools; it does not reduce the authority of a credential handed to a server. If that GitHub token can read every private repository in an organization, the server process can attempt to read every private repository in that organization, even when the employee intended to discuss only one.

Follow the credential, not the chat window

The connection starts before the prompt reaches the model. In the local GitHub example, the host launches a server process over standard input and output, a transport commonly called stdio, and supplies configuration that may include the personal access token. That secret is available to the server process. It is not ordinarily included in the natural-language prompt or returned as a tool result, but the code running inside the server can use it within the limits GitHub enforces.

The server then advertises capabilities. MCP tools are callable operations with names, descriptions, and structured arguments, such as retrieving an issue or searching repository content. The host shows those definitions to the model or otherwise uses them to route a request. GitHub’s server supports toolsets that can reduce which groups of operations are loaded, which matters because a server that advertises write operations creates a larger action surface than one limited to repository reading.

For the security-review request, the model might select a search tool and supply an organization name, repository name, query terms, and pagination settings. The host sends those arguments to the MCP server. The server sends an authenticated request to GitHub, receives the matching records, and returns structured output to the host.

At that point, two systems have handled sensitive data. The MCP server saw the query and GitHub’s response. The AI host received the tool result and may place it in model context, meaning the text and structured data available to the model for that turn. MCP does not dictate whether the host retains prompts, logs tool results, sends them to a cloud model provider, or removes them after the session.

Those are product and deployment choices outside the protocol.

Return to the settings screen. A green “connected” label says almost nothing about this path. It does not show whether the token covers one repository or the whole organization, whether write tools are active, which server binary received the secret, or where the host sends retrieved issue text.

The server sees more than the model may show

Three views of access can diverge: the credential’s authority, the server’s advertised operations, and the tools the host permits the model to call. The narrowest view limits the immediate workflow, but it does not erase the broader ones.

Suppose the GitHub token can read several repositories, while the host enables only issue-search and pull-request tools. The model cannot directly call a file-reading tool that was never exposed. The server process still possesses the token, however, and a compromised or malicious implementation could make other GitHub API requests without waiting for a model tool call. Tool filtering controls the model-facing interface; it is not a sandbox around the server code.

The reverse problem also matters. A server may expose a write tool, but GitHub will reject its request if the assigned token and user lack the required permission. The external service remains the final authorization point. Host approval prompts can add friction before a call, yet they cannot make a broad token narrow, and people often approve vague actions without seeing the exact API request that follows.

Remote MCP servers move the credential path rather than eliminating it. For HTTP-based connections, the MCP authorization specification uses OAuth mechanisms so a client can obtain an access token intended for the MCP server. The remote server may then use its own delegated connection to an upstream workplace service. A well-designed deployment restricts token audience, requests limited scopes, and keeps upstream credentials at the server, but readers still need to inspect what account was authorized and what data the remote operator can log.

Inspect the connection in four passes

Start with identity. Record the server publisher, source repository or service domain, transport, and exact command the host runs. A local MCP server is executable code on the workstation; installing it deserves the same scrutiny as installing another developer tool. A container limits some host access, but mounted directories, forwarded sockets, environment variables, and unrestricted network access can reopen the boundary.

Next, inspect the credential at its source. In GitHub, that means checking whether the connection uses a classic personal access token, a fine-grained token, an OAuth grant, or another organization-approved credential, then reviewing its repository selection, scopes, expiration, and owner. The useful test is direct: if someone copied this credential out of the MCP configuration, what could that person read or change through GitHub’s own API?

Then inspect capabilities separately. The open-source MCP Inspector can connect to a server and display its tools, resources, and prompts; a resource is server-provided context that a client can read, rather than an action it invokes. Reviewing this inventory reveals write operations and broad search functions that a friendly connection dialog may collapse into a generic permission label. Do this in an isolated environment, because launching an unknown local server still runs its code.

Finally, execute the security-review workflow against a test repository. Watch the host’s tool-call display and logs, the MCP server’s logs where available, and GitHub’s audit or access records. Confirm that the repository argument remains fixed, that results do not cross into another project, and that a denied write fails at GitHub rather than merely disappearing from the interface. Delete or rotate the test credential afterward if it was exposed in command history, configuration output, or verbose logs.

This inspection costs time. It also adds operational work: token rotation, server updates, log handling, and repeated checks when tool definitions change. Tool schemas and returned records consume model context, which can raise inference cost and crowd out relevant instructions, while each remote call adds an authentication and network round trip. Large search results may be truncated or summarized, so the assistant can miss an issue even though the server retrieved it.

Isolation has to match the data

For the private repository, the strongest practical control is a dedicated credential tied to a service account or approved user, limited to the named repository and read-only operations needed for review. Run the server in a separate container or restricted account, mount no unrelated directories, and limit outbound network access to required endpoints where the environment supports it. Keep write tools disabled until the workflow proves it needs them.

Prompt injection remains outside the token discussion but inside the same failure path. An issue body can contain instructions aimed at the assistant, and the model may treat that untrusted repository text as guidance rather than evidence. Approval gates should display the proposed action and target, especially before comments, merges, or edits. A generic “allow tool” prompt is weak protection when the retrieved content helped choose the tool.

Revocation is the fallback. If the local server behaves unexpectedly, stop the process and revoke its GitHub credential at the source; removing the connection from the assistant may leave a token valid. For a remote server, revoke both the MCP authorization and any upstream workplace grant if they are separate.

Direct integrations can be the narrower choice

A direct GitHub integration may be safer for this workflow when it offers an administratively managed OAuth application, fixed repository selection, limited actions, and centralized audit records. Its narrower product surface can be an advantage: the assistant gets the few operations the vendor implemented rather than a general server whose tool inventory can expand.

That conclusion is conditional. A direct integration with broad organization access and opaque retention can be worse than an internally operated MCP server using a repository-specific credential. MCP’s value is portability and inspectability, particularly when a team can review server code and put its own gateway between the assistant and GitHub. The protocol alone settles none of the permission questions.

For the security-review summary, use MCP when the team needs a reusable tool interface and can own its credential, runtime, and logs. Prefer the fixed integration when the workflow is stable, the data is sensitive, and the managed connector exposes fewer actions with clearer administrative controls. If neither option can prove repository-level isolation, export the relevant issues into a controlled workspace and let the assistant read that copy instead.

Questions people ask

Can an

MCP server see my password or access token?

A local server can see secrets passed to its process through environment variables, command arguments, configuration, or mounted files. A remote server may receive an OAuth access token intended for it. The model does not need to see the raw token for the server to use its authority against a workplace service.

Does disabling a tool remove the server’s underlying access?

No. Disabling a tool can prevent the model from requesting that operation through the host, but a local server process may still hold a broader credential. Reduce access at the workplace service by narrowing repository selection and scopes; treat host-side tool controls as an additional boundary, not the primary one.

Are remote MCP servers safer than local servers?

They avoid running third-party code directly on the workstation and can support managed OAuth, but they add an operator that may receive queries, tool arguments, and returned workplace data. Safety depends on token scope, audience restrictions, retention, logging, isolation, and whether the remote server needs a separate upstream grant.

When should I keep a direct workplace integration?

Keep it when it offers narrower actions, managed repository selection, reliable revocation, and audit records that your MCP deployment cannot match. For the GitHub review workflow, a fixed read-only connector is preferable if the alternative is a general MCP server holding a broad personal token.