Please do NOT report security vulnerabilities through public GitHub issues.

Instead, please report them responsibly:

1. Email: Send details to the project maintainers via GitHub private vulnerability reporting
2. GitHub: Use the Security Advisories feature to report privately

• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Suggested fix (if any)

• Acknowledgment: Within 48 hours
• Initial Assessment: Within 1 week
• Fix Timeline: Depends on severity (critical: ASAP, high: 1-2 weeks, medium: next release)

When deploying Murphy System:

• Never commit .env files or API keys to version control
• Use strong, unique API keys for production
• Run behind a reverse proxy (nginx/Caddy) in production
• Enable HTTPS for all external connections
• Restrict CORS origins to your known domains
• Review the Deployment Guide for hardening steps

Murphy System uses session-based authentication via HttpOnly cookies:

Password hashing: bcrypt (cost factor from bcrypt.gensalt()) — never stored in plaintext.

Session tokens: cryptographically-random 32-byte URL-safe base64 strings from secrets.token_urlsafe(32). Persisted using a three-tier storage hierarchy:

1. Redis — when REDIS_URL is configured (recommended for multi-process deployments).
2. SQLite WAL — when Redis is not configured, sessions are persisted to the session_store table in the WAL backend (DATABASE_URL, defaults to murphy.db). Sessions survive process restarts.
3. In-memory — last resort when both Redis and SQLite are unavailable.

User accounts: Persisted to the user_accounts table in the SQLite WAL backend (same DATABASE_URL as session storage). Accounts and their credentials survive process restarts. The founder account is re-seeded / role-synced on every startup from MURPHY_FOUNDER_EMAIL / MURPHY_FOUNDER_PASSWORD.

API key environment variable: MURPHY_API_KEYS (plural, comma-separated) is the canonical variable. MURPHY_API_KEY (singular) is also accepted as a fallback for backward compatibility.

Cookie flags: HttpOnly=True (XSS protection), SameSite=lax (CSRF protection), Secure=True in staging/production, 24-hour Max-Age.

This security policy covers the Murphy System core runtime and all modules in the src/ directory. Third-party dependencies are covered by their own security policies.

Murphy System enforces SHA-256 minimum for all hashing in production code paths:

Prohibited algorithms: MD5 and SHA-1 are not used in production code for any security-relevant or identifier-generation purpose. Test code may use these algorithms for negative-validation only. The codebase was scanned with bandit and AST analysis to verify compliance (round 55).

All planned security enhancements have been implemented. The following multi-agent security controls are now operational:

• Per-request authorization — ownership verification on every mutating request (src/security_plane/authorization_enhancer.py)
• PII sanitization — automated detection and redaction of 8 sensitive data types in logs (src/security_plane/log_sanitizer.py)
• Bot resource quotas — per-bot and per-swarm resource limits with automatic suspension (src/security_plane/bot_resource_quotas.py)
• Communication loop detection — DFS-based cycle detection and rate limiting in swarm messaging (src/security_plane/swarm_communication_monitor.py)
• Bot identity verification — HMAC-SHA256 message signing with key revocation (src/security_plane/bot_identity_verifier.py)
• Behavioral anomaly detection — z-score analysis, resource spikes, and API pattern monitoring (src/security_plane/bot_anomaly_detector.py)
• Unified security dashboard — event aggregation, correlation, and compliance reporting (src/security_plane/security_dashboard.py)

Murphy System implements CSRF protection via the _CSRFProtection class in src/fastapi_security.py:

• SameSite cookies: Session cookies are issued with SameSite=lax (development) or SameSite=strict (production), providing browser-level CSRF protection for same-origin requests.
• Double-submit pattern: Mutating API endpoints (POST, PUT, DELETE, PATCH) require the caller to supply the session token in the Authorization: Bearer <token> header or X-API-Key header — both inaccessible to cross-origin attackers who can only trigger cookie-bearing requests via HTML forms.
• Origin validation: The middleware rejects requests whose Origin header does not match the configured MURPHY_CORS_ORIGINS allow-list in staging/production environments.

Murphy System enforces per-IP and per-user rate limits to prevent abuse:

Configuration: Set MURPHY_RATE_LIMIT_RPM environment variable to control the requests-per-minute limit (default: 60 RPM in production, unlimited in development).

When the limit is exceeded, the API returns HTTP 429 Too Many Requests with a Retry-After header.

Authentication endpoints (/api/auth/login, /api/auth/signup) include brute-force lockout protection:

• Lockout threshold: After a configurable number of consecutive failed authentication attempts (default: 10), the source IP is locked out.
• Lockout duration: Lockouts expire after a configurable window (default: 15 minutes).
• Scope: Lockouts are tracked per IP address using the in-memory counter store (replace with Redis for multi-process deployments).
• Logging: All lockout events are written to the security audit log with timestamps and source IP.

Murphy System provides automated key rotation via the ScheduledKeyRotator class in src/secure_key_manager.py:

Environment variables:

• MURPHY_API_KEY — Canonical API key variable (recommended).
• MURPHY_API_KEYS — Legacy comma-separated multi-key alias; accepted for backward compatibility.
• MURPHY_KEY_ROTATION_INTERVAL_DAYS — Days between automated rotations (default: 90).