Skip to content

Security Risks of Integrating an MCP Server in Projects Published on GitHub

Security Risks of Integrating an MCP Server in Projects Published on GitHub

As AI-driven systems become more context-aware, the use of MCP (Model Context Protocol) servers is gaining traction for enabling real-time access to external data sources. While powerful, integrating an MCP server into a project, especially one hosted publicly on GitHub, introduces several security risks that must be proactively addressed.

An MCP Server acts as a bridge between the AI models and external data systems, but in this case the project itself. This could be pottentialy plug in our repositories to external actors.

MCP Servers Risks

Before bringing the checklist, Let's go to bring the potential risks they could create:

  • Credential Exposure: If the project includes hardcoded secrets, API keys, or access tokens for MCP capabilities, publishing it on GitHub could lead to immediate compromise. Even private repos are not immune to accidental leaks.

  • Unrestricted Capability Access: Without proper access controls, an MCP server may expose sensitive operations to any connected model or client.

  • Prompt Injection & Context Manipulation: If the MCP server blindly trusts model input, malicious prompts could trigger unintended actions or data exposure.

  • Lack of Audit Trails: Projects often omit logging and monitoring when prototyping. Without visibility into who accessed what and when, detecting misuse becomes nearly impossible.

  • Third-Party Dependencies: MCP servers often rely on external APIs or services. If these are unstable, deprecated, or vulnerable, they can compromise the entire system.

MCP Servers Mitigation

  • Credential Exposure: Use environment variables, secret managers, and .gitignore to exclude sensitive files.

  • Unrestricted Capability Access: Implement fine-grained authorization (e.g. RBAC, OAuth scopes) and validate caller identity.

  • Prompt Injection & Context Manipulation: If the MCP server blindly trusts model input, malicious prompts could trigger unintended actions or data exposure.

  • Lack of Audit Trails: Enable structured logging, traceability per capability, and anomaly detection.

  • Third-Party Dependencies: Monitor upstream dependencies, enforce version pinning, and isolate external calls via proxies.

Checklist

Secrets & Credentials
  • No hardcoded secrets in code or config files
  • Use environment variables or a secret manager (e.g. Azure Key Vault)
  • Add .env, .key, and credential files to .gitignore
  • Rotate credentials regularly and monitor for leaks
Access Control
  • Implement authentication for all MCP capabilities
  • Enforce authorization per capability (RBAC, scopes, or user context)
  • Restrict access to sensitive data sources (e.g. financial, personal)
  • Validate caller identity before executing any action
Input Validation & Prompt Safety
  • Sanitize all incoming prompts or context from models
  • Apply intent filtering to block unsafe or ambiguous requests
  • Enforce strict schemas for input/output formats
  • Log rejected or suspicious requests for review
Logging & Monitoring
  • Enable structured logging for all capability calls
  • Include timestamp, caller ID, capability name, and result status
  • Set up alerts for unusual access patterns or failed auth attempts
  • Store logs securely and retain them per compliance policy
Dependency & Surface Management
  • Review all third-party libraries for known vulnerabilities
  • Pin versions and monitor upstream changes
  • Isolate external API calls via proxies or wrappers
  • Avoid exposing internal endpoints in public repos
Documentation & Governance
  • Document all MCP capabilities and their intended use
  • Include a SECURITY.md file in your GitHub repo
  • Define a threat model and update it as the project evolves
  • Conduct regular code reviews
Refererences:
Back to top