Do NOT report security vulnerabilities via public GitHub Issues.

If you discover a security vulnerability in MindRouter, please report it responsibly by emailing:

sheneman@uidaho.edu

Please include the following information in your report:

• A clear description of the vulnerability
• Steps to reproduce the issue
• An assessment of the potential impact (e.g., data exposure, privilege escalation, denial of service)
• The affected version(s) and component(s), if known
• A suggested fix or mitigation, if you have one

Response Timeline:

We take all security reports seriously and will keep you informed of our progress throughout the process.

MindRouter follows a responsible disclosure model:

• 90-day disclosure timeline: After a vulnerability is reported, the maintainers have 90 days to develop and release a fix before the reporter may publicly disclose the issue.
• Coordinated disclosure: We will work with the reporter to coordinate the timing and content of any public disclosure. If a fix is released before the 90-day deadline, disclosure may happen sooner by mutual agreement.
• Credit: Reporters will be credited in the release notes and this security policy unless they request anonymity.
• Extensions: If a fix requires more than 90 days (e.g., due to upstream dependencies), we will communicate this and negotiate a revised timeline with the reporter.

MindRouter implements several layers of authentication and access control:

• API keys are hashed using Argon2 with SHA-256 normalization before storage in the database.
• Raw API keys are never stored; only the hashed representation is persisted.
• Each API request is authenticated by hashing the provided key and comparing it against stored hashes.

• The web dashboard uses HMAC-signed session cookies for authentication.
• Session cookies are configured with SameSite and optional Secure attributes.
• Session tokens use a static salt per token type for HMAC signing.

• Optional Azure Active Directory single sign-on is supported for institutional deployments.
• When enabled, user identity is established via the Azure AD OAuth2 flow before a local session is created.

• Users are assigned to groups that determine their access level and resource quotas.
• Group membership controls which models and features are available.

• Admin endpoints (node/backend registration, configuration changes, system management) are protected by role-based access control.
• Users whose group has the is_admin flag set are granted access to admin API endpoints.
• Admin authorization is checked on each request using the same API key authentication as regular users, with an additional group-level permission check.

When deploying MindRouter in production, follow these recommendations:

1. Change all default credentials. Generate a strong, random SECRET_KEY and set unique database passwords. Never use the defaults shipped in example configuration files.

2. Enable secure cookies. Set SESSION_COOKIE_SECURE=True for any deployment served over HTTPS (which should be all production deployments).

3. Restrict CORS origins. Set CORS_ORIGINS to your actual domain(s) rather than using a wildcard. For example: CORS_ORIGINS=https://mindrouter.example.edu.

4. Add security headers at the reverse proxy layer. Configure your reverse proxy (nginx, Caddy, etc.) to set:

   • Strict-Transport-Security (HSTS)
   • X-Frame-Options: DENY or SAMEORIGIN
   • X-Content-Type-Options: nosniff
   • Content-Security-Policy appropriate to your deployment
   • Referrer-Policy: strict-origin-when-cross-origin

5. Keep Docker images updated. Regularly rebuild and redeploy to pick up base image security patches.

6. Use TLS for all sidecar communication. Sidecar agents on cluster nodes should communicate with the MindRouter backend over TLS-encrypted connections.

7. Bind sidecar agents to localhost. Run sidecar agents on 127.0.0.1 and use an nginx reverse proxy with TLS termination to expose them. Do not expose sidecar ports directly to the network.

8. Regularly rotate API keys. Establish a rotation schedule for both user and admin API keys. Revoke keys that are no longer in use.

9. Review audit logs. Monitor request logs and telemetry for suspicious activity, such as unusual request volumes, authentication failures, or access to unexpected models.

10. Restrict network access. Use firewalls or security groups to limit access to the MindRouter API, database, and sidecar ports to only the hosts and networks that require it.

The following are known security limitations in the current version of MindRouter:

Only the latest release of MindRouter receives security updates. Users are encouraged to stay on the most recent version.

If you are running an older version and discover a security issue, please still report it. We will assess whether it affects the current release.

The following environment variables control security-relevant behavior in MindRouter. These are typically set in your .env file or Docker Compose configuration.

For questions about MindRouter security that are not vulnerability reports, please open a discussion on the GitHub repository or contact sheneman@uidaho.edu.