Skip to content

Security: Open-Agent-Tools/open-stocks-mcp

Security

SECURITY.md

Security Policy

Supported Versions

We release patches for security vulnerabilities. Currently supported versions:

Version Supported
0.6.x
< 0.6

Reporting a Vulnerability

We take the security of Open Stocks MCP seriously. If you discover a security vulnerability, please follow these steps:

Where to Report

Please do NOT report security vulnerabilities through public GitHub issues.

Instead, please report them via one of these methods:

  1. GitHub Security Advisories (Preferred)

    • Navigate to the Security Advisories page
    • Click "Report a vulnerability"
    • Fill out the form with details about the vulnerability
  2. Direct Email

    • If you prefer email, contact the maintainers directly
    • Include "SECURITY" in the subject line
    • Provide detailed information about the vulnerability

What to Include

When reporting a vulnerability, please include:

  • Description: Clear description of the vulnerability
  • Impact: What can an attacker accomplish?
  • Reproduction: Step-by-step instructions to reproduce the issue
  • Version: Which version(s) are affected
  • Proof of Concept: Code, screenshots, or other evidence (if available)
  • Suggested Fix: If you have ideas for how to fix it (optional)

What to Expect

  • Acknowledgment: We will acknowledge receipt within 48 hours
  • Assessment: We will assess the vulnerability and determine severity
  • Updates: We will keep you informed of progress toward a fix
  • Disclosure: We will coordinate with you on public disclosure timing
  • Credit: We will credit you in the security advisory (unless you prefer to remain anonymous)

Response Timeline

  • Initial Response: Within 48 hours
  • Status Update: Within 7 days
  • Fix Release: Depends on severity and complexity
    • Critical: Within 7 days
    • High: Within 14 days
    • Medium: Within 30 days
    • Low: Next regular release

Session Token Storage (At-Rest Security Model)

The robin-stocks library authenticates with Robinhood and stores OAuth tokens locally so subsequent launches can skip the interactive login flow. Open Stocks MCP wraps this storage with the following protections (v0.6.5+):

Encryption

Session tokens are encrypted at rest using AES-128 in GCM mode via cryptography.fernet.Fernet before they are written to disk. The plaintext pickle written by robin-stocks is immediately encrypted and removed, leaving only an encrypted ~/.tokens/robinhood.pickle.enc on disk. The plaintext form is only present for the brief moment during login/resume, after which it is re-encrypted.

Key Management

A per-machine Fernet key is generated on first use and stored in ~/.tokens/.session.key. This key is:

  • Generated with Fernet.generate_key() (URL-safe base64-encoded 32-byte AES key).
  • Stored with chmod 600 (owner read/write only).

If the key is lost (e.g., the file is deleted), the encrypted session pickle can no longer be decrypted and a fresh login will be required automatically.

Directory and File Permissions

The ~/.tokens directory is created or hardened to chmod 700 on every interaction, so other users on the same machine cannot list or read its contents. Every file written inside it is given chmod 600.

Limitations

  • The Fernet key itself is stored unencrypted on disk. An attacker with read access to ~/.tokens/.session.key can decrypt the session pickle. For higher assurance, store the key file on an encrypted filesystem, in a hardware security module, or in the OS keyring (a future enhancement).
  • The plaintext session exists briefly in process memory during login.
  • These protections apply only to the session pickle. Robinhood credentials (username and password) are supplied via environment variables and are never persisted to disk by this server.

Security Best Practices

When using Open Stocks MCP:

HTTP Transport Security Model

The HTTP MCP transport exposes tool invocation over a network socket. Because those tools can place trades against an authenticated broker session, the endpoint is treated as trust-equivalent to broker credentials.

  • Loopback by default: --host defaults to 127.0.0.1. Only processes running on the same machine can reach /mcp.
  • Explicit opt-in for network exposure: Binding to a non-loopback address (e.g. --host 0.0.0.0 for Docker) is allowed only when an API key is set. The server will refuse to start otherwise.
  • Bearer-token auth on tool endpoints: When an API key is configured, every request to /mcp, /sse, /session/refresh, and /tools must include Authorization: Bearer <api-key>. Health and status endpoints stay unauthenticated so container orchestrators can probe liveness.
  • Set the key via env var or flag: Pass --api-key <value> or set the MCP_API_KEY environment variable. Treat the key as a secret with the same care as broker credentials — anyone holding it can invoke trading tools.
  • TLS termination: The server does not terminate TLS itself. When exposing the endpoint over an untrusted network, run it behind a reverse proxy (nginx, Caddy, Traefik) that terminates TLS and forwards to the loopback bind, or rely on platform-level encryption (e.g. WireGuard, mTLS sidecar).

API Keys and Authentication

  • Environment Variables: Store all API keys and secrets in environment variables
  • Never Commit: Never commit .env files or credentials to version control
  • Rotate Regularly: Rotate API keys and passwords regularly
  • Broker Credentials: Securely store Robinhood, Schwab, and other broker credentials
  • OAuth Tokens: Handle OAuth tokens securely, use refresh tokens appropriately

Network Security

  • HTTPS Only: Always use HTTPS for API connections
  • Certificate Validation: Verify SSL/TLS certificates
  • Rate Limiting: Implement rate limiting to prevent abuse
  • Input Validation: Validate all inputs to MCP tools

Data Protection

  • Sensitive Data: Never log sensitive data (passwords, API keys, account numbers)
  • Personal Information: Handle PII in compliance with regulations
  • Financial Data: Secure storage and transmission of financial information

Security Updates

Security updates will be released as:

  1. Patch Releases: For backward-compatible security fixes (0.1.x)
  2. GitHub Security Advisories: Public disclosure after fix is available
  3. Release Notes: Detailed information in CHANGELOG.md
  4. CVE: We will request CVE numbers for significant vulnerabilities

Contact

For questions about this security policy or other security-related matters:

Attribution

This security policy is based on best practices from the open source community and recommendations from the GitHub Security Lab.

There aren't any published security advisories