An MCP server’s effective access depends on its backend credentials and process permissions as well as the tools it exposes.
A legitimate MCP server can return hostile instructions, so review what the whole assistant can read and send, not just the server.
An assistant’s refusal to perform an action doesn’t prove the underlying service would block it.
Chainguard provides a consistent, verifiable baseline for MCP server software and dependencies, so platform and AppSec teams can focus each review on the access and data flows specific to that job.
When you connect an AI assistant to engineering systems through the Model Context Protocol (MCP), each new connection becomes a security decision. A legitimate server can return hostile instructions, and its backend credentials may reach beyond the assistant’s assigned task.
MCP security means protecting the software, credentials, and data involved when an AI application connects to external tools through MCP. ****Evaluate it against the assistant’s assigned job: verify the server software, constrain its effective access, and test whether controls block out-of-scope actions prompted by hostile content across the assistant’s connections. A signed server can still return malicious instructions, so passing one check doesn't settle the others.
The goal is a bounded rollout decision: platform engineering and AppSec can approve the named server and connection set after evidence shows that permitted reads work and out-of-scope actions are blocked.
How MCP connects the assistant to your repository
In MCP architecture, the AI application acts as the host. It creates a separate MCP client connection for each MCP server it uses, and each server exposes capabilities to the host, such as tools that retrieve data or perform actions. The server itself may run as a local process on an engineer’s workstation, on remote infrastructure your team operates, or as a service hosted by a third party.
Consider an AI assistant that summarizes issues from one designated engineering repository for an authorized engineer, then returns its summary in the approved AI environment. In this workflow, the host (AI application) makes the repository server’s issue-retrieval tool available to the language model. When the model selects that tool, the host routes the call through the corresponding MCP client. The server uses its configured repository access to retrieve the issues and returns them to the host, which makes that content available to the model. The model can then use the content to write the summary or select another available tool.
That return path is where issue content can influence the assistant’s subsequent behavior. Text supplied by someone with permission to create or edit an issue enters the context the model uses to decide what to do next. Even when the server is legitimate and retrieves exactly what the host requested, malicious instructions embedded in that content may cause the model to attempt actions through other tools available to it.
In this example, the security review should follow the issue from the software that retrieves it to the actions the assistant can take after reading it:
What software actually runs, did it come from the expected source, and who operates it?
Do its backend credentials and process access match the issue-summary job?
What could a redirected assistant read, change, or send across its connections?
Which pilot tests provide evidence that the intended controls work?
The sections below address these questions in order.
Identify the server software and its operator
Start by identifying where the server runs, what software actually executes, and who controls its deployment and updates. A local process, a server your team operates, and a third-party hosted service all require different evidence.
Local servers: Review the launch configuration
A local MCP server executes code on the engineer’s workstation and may run with the same privileges as the MCP client unless additional restrictions are in place. Review the complete launch configuration, including the executable, package or image source, resolved version, arguments, and anything the command downloads or runs.
A connection to a remote server may also depend on a local bridge or proxy. Include that software and its launch configuration in the inventory rather than treating the remote endpoint as the only component under review.
Local and team-hosted servers: Check the artifact you'll run
For a local or team-hosted server, ask the implementing engineer to identify the publisher, distribution source, package or container image, exact version or digest, and update owner. Review dependency and security findings for the artifact you will actually deploy. A familiar project name does not establish that the downloaded package is the intended one.
When signatures are available, verify the artifact against the expected signer or key under your organization’s trust policy. A valid signature connects an artifact to a signing identity; it doesn’t establish that the signer should be trusted or that the code behaves safely.
Build provenance can provide evidence about an artifact’s source and build process, while a Software Bill of Materials (SBOM) identifies its declared components. Verify the relevant provenance claims and treat the SBOM as an inventory for further review, not proof that the artifact is complete or free of malicious or vulnerable code.
Finally, keep the reviewed artifact identifiable. Pinning an image digest preserves the exact artifact you evaluated, but it also prevents the deployment from receiving a newer release until you update the digest. Assign an owner to monitor new releases and security findings, evaluate the replacement artifact, and update the pin deliberately.
Third-party hosted servers: Evaluate the operator relationship
With a third-party hosted server, the provider controls the software, deployment, and runtime environment. Ask how it isolates customers, protects backend credentials, handles and retains tool data, deploys updates, reports security changes, and revokes access. Establish which audit records your team can obtain during an investigation.
Review the AI application and model provider separately if another company operates them. Confirm that they are approved to process the repository’s data and document where tool results are sent, stored, and retained. A narrowly scoped repository credential limits what the server can retrieve, but it can’t control what the AI application does with data after retrieval.
Limit MCP access at each layer
A server’s tool list describes the interface presented to the assistant, not everything the deployment can access. Review the authority at three separate layers: the server's access to the repository, the client's access to the server, and the server process's access to its surrounding environment. Then account for what the host's other connections add.
1. Restrict repository access to the assigned job
When creating an MCP pilot, use a dedicated, narrowly scoped credential where the repository supports one. Allow issue reads from the designated repository while denying issue changes and access to unrelated repositories. In the issue-summary example, the engineer receiving these summaries may personally have broader access, but the assistant does not need that authority to produce the summary.
If the server serves multiple users, it must also authorize the requested repository and operation for each caller before using its backend access. Otherwise, a less-privileged caller could induce a server with broad credentials to act on resources the caller should not be able to reach.
For a server your team operates, enforce that authorization before making the repository request. For a hosted service, ask the provider how it enforces the same boundary and test it with authorized test accounts. If the repository or server cannot enforce the required limits, keep the pilot on synthetic data until you can use a different identity or deployment.
2. Separate MCP authorization from repository access
For HTTP-based transports, MCP’s authorization specification defines an OAuth-based flow that can control the MCP client’s access to the server. The access token presented to the MCP server is intended for that server. It does not grant or describe the server’s access to the repository and must not be passed through as a repository credential.
The server still needs a separate downstream credential or delegated identity for the repository. Review the scope and lifecycle of that access independently from the client-to-server authorization.
Local standard input/output connections (commonly called stdio) do not use the MCP OAuth flow. The specification instead directs these implementations to obtain credentials from the environment. Your team must still decide which credentials the process receives and scope them to the assigned job.
3. Restrict the server process and the host’s other connections
Repository permissions do not limit what the server process can read from the operating system or reach over the network. The MCP security guidance recommends restricted execution for local servers, including limits on filesystem and network access.
In our example, the issue server has no reason to read an engineer’s SSH keys, inherit unrelated cloud credentials, or connect to arbitrary network destinations. Run the server with only the environment variables, directories, and network access the job requires. Apply equivalent workload and network restrictions to a server running on infrastructure your team operates.
Finally, record the effective access available through the AI host’s other connections. An outbound messaging or web-request tool adds a capability that the issue-summary job does not require. Removing unneeded connections from the pilot makes its permitted data flow easier to inspect and test.
Assess the potential impact of hostile instructions
A trustworthy server can still deliver hostile instructions, and the potential consequences of those instructions will depend on the assistant’s combined permissions, connected tools, network reach, and the policies that govern their use. Assess those permissions and connections, and put controls in place that limit what hostile instructions can accomplish, whether they arrive in retrieved data or in tool definitions.
Treat retrieved content as untrusted
Suppose an issue in the designated repository contains instructions to retrieve a private issue from another repository and send its contents to an external service. The repository server can faithfully return that issue without any compromise of its own code.
This is indirect prompt injection: an attacker places instructions in external content that the model processes during a legitimate task. If the model treats those instructions as authoritative, it may generate tool calls or propose actions outside the engineer’s request.
The attempted read from the unrelated repository should fail at the repository’s access controls, but even with that read blocked, the assistant already holds data from the permitted repository. If it can call a separate messaging or web-request tool, that connection may provide another route for leaking the data. Review what the whole assistant can read and send, instead of only evaluating the repository server.
Review tool definitions and changes
Retrieved records are not the only source of instructions available to the model. MCP hosts also provide tool descriptions to help the model decide when and how to use each tool. A malicious server can place instructions in those descriptions, an attack commonly called tool poisoning.
In research published on April 1, 2025, Invariant Labs demonstrated poisoned tool descriptions that induced Cursor, a coding agent, to access sensitive local files. Invariant Labs also ran experiments that showed a malicious server’s description influencing how an AI assistant used a tool from another server.
These experiments demonstrate attacks against particular configurations, not identical behavior across every current MCP host. In the research's "rug pull" scenario, a server changed a tool description after the user had already approved it, which shows why an initial approval isn't enough.
Record the tool definitions the host actually loads, detect changes where the platform supports it, and require another review when approved definitions or available capabilities change.
Enforce the assignment outside the model
Keep retrieved issue text separate from trusted instructions, and screen retrieved content and proposed tool calls for suspicious behavior. These measures can reduce exposure, but prompt wording and content filters do not reliably prevent every injection. Enforce the pilot’s boundaries through least-privilege permissions and data-flow policies outside the model.
Start by disabling outbound tools the pilot doesn't require. Restrict network access for the repository server and any local bridge, while recognizing that those rules do not constrain a separate messaging or web-request service available through the host.
If the pilot retains an outbound capability, identify the host policy or gateway that can reject requests to unapproved destinations before execution. Ask the implementing engineer to show you which calls the policy covers and demonstrate a denied request. If the host can bypass that enforcement, remove the capability or use a more restricted deployment.
For later workflows that require sensitive actions, an approval prompt should identify the actual operation, destination, and material arguments or data before execution. A dialog that displays only a vague tool name does not give the engineer enough information to assess the action.
Human approval can reduce risk, but an approver can still misunderstand or mistakenly authorize a malicious action. Use approval alongside least-privilege permissions and independently enforced access controls.
Make the pilot produce evidence
Before the limited rollout, test the configuration in a controlled environment with synthetic issues, a designated test repository, and a separate private test repository that the server’s downstream identity must not access. Have the implementing engineer reproduce the configuration intended for the limited rollout, then have AppSec review the resulting evidence.
Start with a successful read so you know the system works, then test prohibited operations directly at the service or policy layer that’s responsible for denying them. An assistant's refusal provides evidence about that interaction, but it doesn't prove that the backend would reject the same operation.
The checks below apply to the issue-summary example. They're illustrative, not exhaustive: adapt the identities, enforcement points, and expected results to your own implementation.
Pilot check | Evidence to collect | Result needed before a limited rollout |
|---|---|---|
Summarize permitted issues | Expected synthetic issue contents, the resulting summary, and correlated tool-call and repository access records | The assistant retrieves the designated issues and produces a useful summary |
Read the unrelated private test repository | A direct read request at the repository or other enforcing layer, using the same downstream identity or credential the server will use, along with the response and audit record | Access is denied and no issue contents are returned |
Change a test issue | A direct write attempt using the server’s downstream identity or credential, the service’s response, and the issue’s state afterward | The write is denied and the issue remains unchanged |
Respond to hostile issue text | A synthetic issue containing out-of-scope instructions, the model’s response, any resulting tool requests, and the decisions recorded by enforcing services | The assistant completes the permitted task without carrying out a prohibited action; any prohibited request it makes is blocked by an identifiable control |
Confirm unnecessary outbound tools are disabled | The host’s loaded tool inventory for the tested configuration and an attempt to request or invoke an unapproved outbound tool | The tool is unavailable to the assistant or the host rejects its invocation |
Test any retained outbound capability | An attempt through the applicable tool, host policy, or gateway to send synthetic issue data to an unapproved test destination your team controls | The enforcing policy denies the transmission and the test destination receives no issue data |
Test outbound access from the isolated environment | A request from each applicable server or local-bridge environment to an unapproved test destination your team controls, along with network-policy and receiver records | Each applicable network policy denies the request and the destination receives no issue data |
Revoke pilot access | Revocation records and subsequent access attempts against both the MCP endpoint and repository, as applicable, including attempts to refresh or renew the old authorization | Access ends within the documented period, and revoked credentials or grants cannot be renewed |
Review redacted logs that connect the caller, tool, target repository or destination, policy decision, and outcome. Keep tokens and unnecessary issue contents out of those records, and assign an owner to investigate unexpected calls and disable access when needed.
Passing these checks supports a limited rollout of the tested configuration; it is not a security certification. If a prohibited operation succeeds, keep the workflow in the test environment until the responsible control changes and the test passes.
The platform team should own the deployed configuration and software updates, with AppSec reviewing changes that expand authority or data movement. Repeat the relevant checks whenever the software, tools, permissions, credentials, or connections change. Adding a capability, such as issue editing or another connected service, is a new decision with its own permitted actions and evidence to collect. Those reviews multiply as more teams request MCP connections, each with its own server, credentials, and runtime setup.
Scale MCP without scaling the security burden
For platform leaders, the larger MCP risk is the fragmented estate that emerges when every team assembles its own combination of server software, dependency sources, credentials, and runtime controls.
Chainguard helps you turn MCP adoption into a repeatable platform capability, with a consistent software and execution baseline that developers can use and security teams can evaluate.
Chainguard Containers reduces the work of packaging and maintaining MCP server software through minimal, regularly updated images such as
mcp-grafana, accompanied by signatures, provenance, and SBOMs.For teams building their own servers, Chainguard Libraries blocks known-malicious versions of supported Java, JavaScript, and Python dependencies retrieved through Chainguard Repository, with Go and .NET available in beta. Chainguard-built packages include provenance and SBOMs. Optional fallback packages remain upstream-built but are screened for malicious behavior and subject to configured cooldowns.
Chainguard Workspaces, currently in beta, adds isolated microVM environments for coding agents and third-party MCP integrations, supporting the process restrictions described earlier.
With Chainguard, there are fewer one-off components to vet, less work managing dependencies and applying patches, and clearer evidence about the software and execution environment behind each workflow.
Chainguard does not determine repository permissions or prevent hostile content from redirecting an assistant. It reduces uncertainty around the software supply chain and execution environment. This lets your platform and AppSec teams focus on the access and data flows specific to each job. Each new MCP workflow can build on an approved foundation instead of becoming a separate security exception.
Related articles