We release patches for security vulnerabilities. Which versions are eligible for receiving such patches depends on the CVSS v3.0 Rating:

Kubrick CLI undergoes comprehensive automated security scanning:

• CodeQL: GitHub's semantic code analysis engine scans for security vulnerabilities
• Bandit: Python security linter checks for common security issues
• Semgrep: Static analysis tool for detecting security vulnerabilities and bugs

• Safety: Checks Python dependencies against known security vulnerabilities
• Dependabot: Automated dependency updates for security patches

• Trivy: Comprehensive vulnerability scanner for Docker images
• Scans for OS packages, language-specific packages, and application dependencies
• Checks against CVE databases

• OSSF Scorecard: Automated security health metrics for open source projects
• Evaluates repository security practices

Please do not report security vulnerabilities through public GitHub issues.

If you discover a security vulnerability, please send an email to rcland12@gmail.com with:

1. Description: A clear description of the vulnerability
2. Impact: What could an attacker potentially do?
3. Steps to Reproduce: Detailed steps to reproduce the issue
4. Affected Versions: Which versions are affected?
5. Suggested Fix: If you have ideas on how to fix it (optional)

• Initial Response: Within 48 hours acknowledging receipt
• Status Update: Within 7 days with an assessment of the report
• Fix Timeline: Depends on severity and complexity
  • Critical: 1-7 days
  • High: 7-30 days
  • Medium: 30-90 days
  • Low: Handled in regular development cycle

Security fixes are released as patch versions (e.g., 0.2.0 → 0.2.1) and announced through:

• GitHub Security Advisories
• Release notes
• PyPI version updates

1. Keep Updated: Always use the latest version

   kubrick update        # upgrades via uv tool, pipx, or pip, matching your install

2. Review Code Generated by AI: Always review code before executing

   • Don't blindly run generated scripts
   • Verify file operations match expectations
   • Check tool calls for unexpected actions

3. Sandbox Untrusted Environments: Use Docker for isolation

   docker run --rm -it \
     --user $(id -u):$(id -g) \
     -v ${PWD}:/workspace \
     rcland12/kubrick-cli

4. Protect API Keys:

   • Store keys with kubrick auth login or environment variables; never in config files
   • Never commit API keys to version control
   • Rotate keys regularly and set spending limits with your provider
   • See Credential storage

5. Monitor Tool Execution: Pay attention to tool calls being made

   • Kubrick shows every tool call, and asks before edits and commands in the default mode
   • Dangerous commands always show a warning and ask when someone is at the terminal
   • Use bypass mode only in disposable environments (containers, VMs)

1. Network Security:

   • Don't expose model servers directly to the internet; bind to the LAN and firewall the port
   • Use localhost or internal networks
   • Consider using VPN/tunnels for remote access

2. Model Security:

   • Only use models from trusted sources
   • Verify model checksums/signatures
   • Keep model serving infrastructure updated

3. Access Control:

   • Implement authentication if exposing services
   • Use API keys or tokens
   • Monitor access logs

1. Permission modes: default asks before file edits and non-read-only commands; accept_edits auto-approves edits inside the working directory; plan is read-only; bypass approves everything except dangerous commands at an interactive terminal. Reads and edits outside the working directory ask in every mode except bypass.
2. Dangerous command confirmation: commands matching destructive patterns (rm -rf, sudo, force-push, curl | bash, mkfs, ...) show a warning and require confirmation.
3. Non-interactive safety: in -p mode or without a terminal, anything that would need approval is denied unless you pass --permission-mode accept_edits or bypass. Commands that match a dangerous pattern are refused even in bypass, since there is nobody to confirm them.
4. "Always allow" rules apply to one program (pytest, git commit, python -m pytest), never to cd. In a chained command (&&, ;, |, &) every part must be read-only or allowed on its own, and commands that redirect into files always ask.
5. Limits: max_file_size_mb for reads, tool_timeout_seconds for commands (max 600), max_iterations model calls per turn, max_tool_result_chars per tool result.
6. Argument validation: tool arguments are checked against each tool's schema before anything runs.

{
  "permission_mode": "default",
  "tool_timeout_seconds": 120,
  "max_file_size_mb": 10,
  "max_iterations": 50,
  "credential_store": "keyring",
  "credential_max_age_days": 90
}

API keys are never written to config.json. For each provider key, Kubrick checks, in order:

1. Environment variables: ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENAI_COMPATIBLE_API_KEY. These always win over stored keys.
2. The credential store, chosen by credential_store:
   • keyring: the OS keychain (macOS Keychain, Windows Credential Manager, Linux Secret Service). Requires pip install 'kubrick-cli[keyring]' and a working keychain backend.
   • file: ~/.kubrick/credentials.json, with each value encrypted using Fernet (AES-128-CBC + HMAC-SHA256, from the cryptography package).
   • auto (default): the keychain when one is available, otherwise the file.

Store, inspect, and remove keys with kubrick auth login|status|logout [provider]. In an interactive session Kubrick also prompts for a missing required key (input hidden) and stores it.

• On first use Kubrick creates ~/.kubrick/machine.key: 32 random bytes, mode 0600.
• The encryption key is derived with HKDF-SHA256 from machine.key, salted with the OS machine ID (/etc/machine-id on Linux, IOPlatformUUID on macOS, MachineGuid on Windows; empty if unavailable, e.g. in most containers).
• credentials.json is written atomically with mode 0600; ~/.kubrick is set to 0700.
• Entries are stored per key slot. Another machine, or a container with a different machine ID, gets its own slot rather than overwriting yours.

What this protects against: API keys leaking through config.json, dotfile repositories, backups, bug reports, or a copied ~/.kubrick directory. A copy of the files on another machine can't be decrypted, because the machine ID differs.

What it does not protect against: malware or any process running as your user on the same machine, which can read machine.key too. If that matters, use the OS keychain or environment variables injected by a secrets manager.

• Deleting machine.key, moving to a new machine, or changing the machine ID makes stored keys unreadable. kubrick auth status shows them as unreadable; run kubrick auth login.
• Set credential_max_age_days (e.g. 90) to treat older stored keys as expired and require logging in again. This is off by default. Rotating keys at the provider is the stronger control.

Earlier versions stored openai_api_key / anthropic_api_key in plaintext in config.json. On first run, 0.2.0 moves them into the credential store and removes them from config.json. Consider rotating keys that were stored in plaintext.

Bedrock uses the standard AWS credential chain (environment, ~/.aws profiles, SSO, instance roles). Kubrick stores no AWS credentials; SSO sessions expire on AWS's schedule and you refresh them with aws sso login.

• LLM Hallucinations: AI may generate plausible but incorrect/insecure code
• Injection Vulnerabilities: Always validate AI-generated code
• Unintended Side Effects: Review tool calls and code changes

1. Always Review: Inspect generated code before execution
2. Use Version Control: Commit before major operations
3. Test in Safe Environments: Use Docker or VMs for testing
4. Keep Permission Prompts On: Prefer default or accept_edits over bypass

We monitor dependencies for security vulnerabilities:

• Automated Updates: Dependabot submits PRs for security patches
• Safety Checks: CI pipeline checks dependencies against vulnerability databases
• Minimal Dependencies: We keep dependencies minimal to reduce attack surface

Current dependencies:

• rich - Terminal formatting (well-maintained, widely used)
• prompt_toolkit - Interactive CLI (well-maintained, widely used)
• cryptography - Encryption for the credential store (PyCA, widely used)

Optional extras: boto3 ([bedrock]), keyring ([keyring]).

Our Docker images:

• Based on official Python slim images
• Scanned by Trivy for vulnerabilities
• Multi-arch builds (amd64, arm64)
• Run as your own user with --user "$(id -u):$(id -g)" (the kubrick-docker wrapper and docker-compose.yaml do this); the image itself doesn't set a USER
• Rebuilt with each release; security.yml also scans the image on every push

• OWASP: We follow OWASP secure coding practices
• CWE: Code is checked against Common Weakness Enumeration
• CVE: Dependencies monitored against CVE databases
• OSSF: Project follows OpenSSF best practices

For security inquiries: rcland12@gmail.com

For general support: GitHub Issues

• We practice responsible disclosure
• Security fixes are released before public disclosure
• We acknowledge security researchers in release notes (if desired)
• We do not run a bug bounty program at this time

We appreciate security researchers who responsibly disclose vulnerabilities:

Last Updated: October 2026 Policy Version: 1.1