Security
View SourceTidewave is a development tool and it must not be enabled in production. In a nutshell, you must treat it as any other developer tool, such as web console, REPLs, and similar that you may enable during development.
The installation steps for each framework will guide you towards the best security practices. This guide covers the overall security checks performed by Tidewave and risks you must consider when using it through an editor/AI assistant.
Server exposure
The Tidewave runs over the same host and port as your web application,
such as http://localhost:4000/tidewave/mcp
. Theoretically, someone in
the same network as you would be able to access Tidewave and its abilities
to evaluate code. Luckily, there are best practices put in place to prevent
that:
Localhost binding - most web frameworks restrict your web application in development to only be accessible from your own machine, to restrict unwanted access to your application and development tools like Tidewave.
Remote IP checks - Tidewave verifies that requests coming to the MCP belongs to the current machine by verifying the connection's remote IP.
Origin checks - For browser requests, Tidewave also verifies that the request's "origin" header matches your development URL.
Here is a summary of how these measures are enabled across different Tidewave implementations. The values below represent the default settings used by Tidewave and the underlying frameworks:
Security measure | Tidewave for Phoenix | Tidewave for Rails |
---|---|---|
Localhost binding | ✅ | ✅ |
Remote IP checks | ✅ | ✅ |
Origin checks | ✅ | ✅ |
MCP tool execution
The goal of Tidewave is to allow editors and AI assistants to perform the same project tasks as you, such as reading, writing, and executing code. Most editors and AI assistants require you to explicitly allow a tool to run before they do anything (unless you enable features such as "YOLO mode"). Commands that execute code may perform any action on your machine and therefore must be assessed with care.
Here are some best practices put in place by Tidewave which you could also employ:
Tidewave MCP is open source, which means you can navigate its source code and verify its tools and prompts, avoiding attacks such as prompt injection
If the file system tools are enabled, they are restricted to your application's root directory
Because Tidewave runs within your web application, you may also run your web application with Docker, guaranteeing all tools execute within the Docker container rather than your system