Harvey Security Review - Pre-Release Assessment

Overview

This document provides a comprehensive security review of Harvey (v0.0.2+) in preparation for release. It identifies strengths, vulnerabilities, and recommendations for hardening the codebase.

Review Date: 2026-05-19 (Updated)
Reviewer: Mistral Vibe
Target Version: 0.0.2+ (post-fixes)

Executive Summary

Harvey has significantly improved its security posture since the initial review. All critical issues identified previously have been addressed:

• ✅ /run command now uses parseCommandLine() validation
• ✅ Sensitive environment variable list expanded (Cohere, Groq, Perplexity)
• ✅ Sensitive file deny list expanded (SSH keys, authorized_keys)

Current Security Score: 8.5/10 - Strong foundation, suitable for personal and experimental use. See SECURITY.md for known limitations before production deployment.

Strengths (Well Implemented)

Fixed Issues (Previously Reported, Now Resolved)

Remaining Medium Priority Issues

Clarifications (Documentation Updates Needed)

parseCommandLine() Behavior

Documentation (corrected): SECURITY.md originally stated that parseCommandLine() “rejects shell metacharacters.” This has been corrected — SECURITY.md now accurately describes that security comes from exec.Command() not invoking a shell.

Actual Behavior: The function parses command lines with quote handling but does NOT reject shell metacharacters like |, >, <, &, ;.

Why This Is Still Secure: Security comes from using exec.CommandContext(program, args...) which does NOT invoke a shell. Metacharacters are passed as literal string arguments to the program, not interpreted by a shell. This is actually a strength - it avoids shell injection entirely.

Recommendation: Update documentation to clarify that: - Shell metacharacters are NOT filtered/rejected by parseCommandLine() - Security is achieved by NOT using a shell (direct exec) - Metacharacters are passed as literal arguments

Code Quality & Hardening

Security Scorecard

Overall: 8.5/10 - Production-ready with minor hardening recommended

Recommendations for Next Release

High Priority (Address Before Production Deployment)

1. Network Security Hardening
   • Add TLS certificate verification for all remote LLM endpoints
   • Warn or block HTTP URLs for cloud providers (Anthropic, OpenAI, Mistral, etc.)
   • Validate URL schemes in clientForEndpoint() to prevent SSRF
2. Windows PowerShell Security
   • Restrict PowerShell script execution to workspace directory
   • Consider using -NoProfile flag to prevent profile-based attacks
   • Add execution policy restrictions

Medium Priority (Address in Next Minor Release)

3. Input Validation
   • Add maximum length limits on tool arguments (e.g., 64KB per string argument)
   • Validate route URL formats before connection
   • Consider pattern-based filtering for environment variables (e.g., *_API_KEY, *_SECRET)
4. Rate Limiting
   • Add configurable rate limits on tool calls per turn and per session
   • Consider resource quotas (CPU, memory) for skill execution
5. Symlink Hardening
   • Review TOCTOU windows in workspace path resolution
   • Consider using O_PATH file descriptors for atomic file access

Low Priority (Future Enhancements)

6. Audit Persistence
   • Add optional file-based audit logging (disabled by default for privacy)
   • Consider remote audit log shipping for enterprise deployments
7. Sandboxing Improvements
   • Consider using Linux namespaces/seccomp for stronger isolation
   • Evaluate gVisor or similar for untrusted code execution

Detailed Analysis

1. Environment Variable Filtering

Current State: Harvey filters known LLM API keys from child processes executed via skills and /run commands.

Strengths: - Comprehensive filtering in filterSkillEnvironment() and filterCommandEnvironment() - Includes all major providers: Anthropic, OpenAI, Mistral, DeepSeek, Google/Gemini, Cohere, Groq, Perplexity - Always ensures PATH is set - Both functions maintain synchronized lists

Gaps: - No pattern-based filtering (e.g., *_API_KEY, *_SECRET, *_TOKEN) - Could miss custom/named API key variables

Recommendation: Consider adding pattern-based filtering as a fallback, but be cautious of false positives.

2. Command Execution

Current State: Harvey uses exec.CommandContext() directly without shell interpretation.

Strengths: - No shell injection via sh -c pattern - parseCommandLine() handles quoted arguments properly - Timeout support via context - Environment filtering applied to all child processes - Safe mode restricts executable commands

Implementation Details: - /run command: Uses parseCommandLine() validation (line 2190) - run_command tool: Uses parseCommandLine() validation (line 268) - git_command tool: Uses parseCommandLine() for args (line 342) - Skill execution: Direct bash/powershell invocation with filtered environment

Note: The unused cmdRunCtx function (line 3469) does NOT use parseCommandLine(), but since it’s not registered as a handler, this is not a security issue. However, it should either be removed or updated for consistency.

3. Path Traversal Protection

Current State: Workspace paths are validated to stay within the workspace root.

Strengths: - Workspace.AbsPath() uses filepath.Clean() and prefix checking - resolveWorkspacePath() additionally checks symlinks via EvalSymlinks - Sensitive files blocked by extension/name pattern - Agents directory explicitly blocked

Implementation: - AbsPath(): String-based prefix comparison (potential TOCTOU) - resolveWorkspacePath(): Uses EvalSymlinks for symlink resolution - sensitiveFileDenied(): Checks against deny list including SSH keys

Gaps: - Small TOCTOU window between path resolution and actual file access - String-based comparison in isAgentsDir() could theoretically be bypassed

4. Sensitive File Access

Current State: Tools reject access to known sensitive file patterns.

Deny List (sensitiveDenyPatterns in tools.go): - .env, .pem, .key, .p12, .pfx (extension matching) - authorized_keys, harvey.yaml, id_ed25519, id_rsa (exact name matching) - Files starting with .env (prefix matching)

Strengths: - Comprehensive coverage of common sensitive files - Covers SSH keys, certificates, config files

Gaps: - No size limits on files that can be read - Could miss custom sensitive filenames

5. Network Security

Current State: Remote routes can use HTTP or HTTPS.

Strengths: - Cloud providers use environment variables (which are filtered from child processes) - Routing can be disabled via configuration

Gaps: - No TLS certificate verification enforced - HTTP URLs accepted for cloud providers (potential credential leakage) - No validation of endpoint URLs (SSRF potential) - No hostname validation

URL Schemes Supported: - ollama://, llamafile://, llamacpp:// → converted to HTTP - Direct http:// and https:// URLs also accepted

Conclusion

Harvey has matured into a capable tool with a strong security foundation, suitable for personal and experimental use. All previously identified critical issues have been addressed. Review SECURITY.md for known limitations before deploying in a sensitive or multi-user environment.

Key Achievements: 1. ✅ Command injection protection via direct exec (no shell) 2. ✅ Comprehensive API key filtering 3. ✅ Workspace sandboxing with path traversal protection 4. ✅ Sensitive file blocking 5. ✅ Safe mode for command restrictions 6. ✅ Audit logging

Remaining Work: - Network security hardening (TLS, SSRF prevention) - Windows PowerShell restrictions - Input validation improvements

The codebase demonstrates security-conscious design throughout, with proper use of Go’s security primitives and defense-in-depth approaches.

References

• OWASP Top 10
• CWE Top 25
• Go Security Checklist
• Google’s Security Best Practices

This review was conducted by analyzing the Go source code in the harvey/ directory, including: commands.go, skill_dispatch.go, tools.go, routing.go, anyllm_client.go, workspace.go, permissions.go, audit.go, terminal.go, builtin_tools.go, config.go.