DEV Community

mgbec for AWS Community Builders

Posted on • Originally published at Medium on

MCP Security: Tr-tr-tr-tricky, tricky, tricky

The GitHub MCP Server looked like the perfect fit for a project I am working on. Connecting to the GitHub MCP from VSCode was actually not super tricky, but I do see some risks that will make securing MCP systems less than easy. I’ll walk through the process of adding this MCP server and some of the risks we will want to think about.

Setup

Here are the official instructions from GitHub- https://github.com/github/github-mcp-server.

I ended up using the manual install option and choosing to run it in Docker. You’ll go into user preferences and add this into Preferences: Open User Settings (JSON), replacing the personal access token with your own.

{ "mcp": { "inputs": [ { "type": "promptString", "id": "github_token", "description": "GitHub Personal Access Token", "password": true } ], "servers": { "github": { "command": "docker", "args": [ "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server" ], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}" } } } } } 
Enter fullscreen mode Exit fullscreen mode

These are the toolsets available at this point in time:

You could install it with limited toolsets, but I chose to install them all.

Once installed you can select certain ones to use.

Testing

I had a deliberately vulnerable test repository from StackHawk: https://github.com/kaakaww and ran some of the GitHub MCP tools against it. It gave me the code scanning alerts for the repo I wanted in a nicely formatted list.

It correctly determined that this particular repo had no Secret Scanning alerts and was able to list all of my repositories.

I asked which vulnerability I should fix first and was given a recommendation:

I asked for specific code fixes and received suggestions:

Fixing the code automatically seemed to require that the code was stored locally.

All cool stuff, right? But there is no way that this is the end of the story….

Let’s talk about security. In this particular scenario, I am running this MCP server locally in Docker and using a fairly tightly scoped GitHub personal access token. That could help with some risk reduction but there is much more I need to consider before I take this out for a ride in an enterprise.

In general, some MCP threats include:

-Prompt injection

-MCP server compromise

-Tool poisoning

-Data leakage

-Unauthorized access

-Potential for DDoS, excessive resource utilization and costs

-Lack of humans in the loop, for consent, feedback, and transparency

-Lack of observability

MCP is still new enough to have plenty of security kinks to work out but efforts are being made by multiple sources. The MCP specification https://modelcontextprotocol.io/specification/2025-03-26 has a specific section for “Security and Trust & Safety”. User consent and privacy is a key piece of this. The protocol roadmap also includes features that will increase security.

I can’t write an article without mentioning OWASP and yes, they do have MCP security advice- https://genai.owasp.org/2025/04/22/securing-ais-new-frontier-the-power-of-open-collaboration-on-mcp-security/.

AWS has guidance for secure deployment on their platform- https://aws.amazon.com/solutions/guidance/deploying-model-context-protocol-servers-on-aws/. There is an included architectural diagram that shows a layered security approach toward MCP server interactions, including OAuth 2.0 authentication using Cognito and token storage with DynamoDB.

The centerpiece of the authentication and authorization is an MCP Auth Service, which runs in a secure virtual private cloud (VPC) on AWS Fargate. MCP Auth Service works with DynamoDB and Cognito to send tokens to the MCP client, routing through the AWS Application Load Balancer and CloudFront.

Some of the other factors accounted for are observability using CloudWatch, rate limiting, web attacks, isolation with security groups, and through containerization. In-transit encryption is provided through CloudFront and throughout the AWS environment.

The CDK code for this project is included here: https://github.com/aws-solutions-library-samples/guidance-for-deploying-model-context-protocol-servers-on-aws?tab=readme-ov-file#overview

Finally, If you would like to experiment with some of the threats you might encounter with an MCP deployment, there is a deliberately vulnerable MCP server to try to exploit at https://github.com/harishsg993010/damn-vulnerable-MCP-server.

Some of the vulnerabilities you can try to exploit are:

  1. Prompt Injection: Manipulating LLM behavior through malicious inputs
  2. Tool Poisoning: Hiding malicious instructions in tool descriptions
  3. Excessive Permissions: Exploiting overly permissive tool access
  4. Rug Pull Attacks: Exploiting tool definition mutations
  5. Tool Shadowing: Overriding legitimate tools with malicious ones
  6. Indirect Prompt Injection: Injecting instructions through data sources
  7. Token Theft: Exploiting insecure token storage
  8. Malicious Code Execution: Executing arbitrary code through vulnerable tools
  9. Remote Access Control: Gaining unauthorized system access
  10. Multi-Vector Attacks: Combining multiple vulnerabilities

It is safe to say that threats to MCP servers and our associated resources will continue to evolve as fast as the AI landscape has been changing. Hold on to your hats and thanks for reading!

Top comments (1)

Collapse
 
youngfra profile image
Fraser Young

Could you explain more about how token storage works when running the MCP server locally versus on AWS, and what extra steps you'd recommend to secure tokens in each case?