How Qmmit Protects Your Code

🔒 Security Foundation

Qmmit follows a defense-in-depth approach. Every layer assumes the previous one could fail. Your data is protected by local-first architecture, encryption at rest and in transit, strict access controls, and continuous monitoring.

💻 Local-First Architecture

All prompt data stays on your machine until you explicitly push. The CLI stores everything in a local SQLite database at .qmmit/history.db. Nothing is transmitted to any server until you run git push.

This means you can use Qmmit in air-gapped environments, on private repos, or with sensitive codebases. The data never leaves your machine unless you choose to sync it.

🛡️ Permission-Based Architecture

Qmmit uses strict read-only permissions by default when scanning AI tool session files. It reads session data from Cursor, Copilot, Claude Code, Kiro, and other tools but never modifies those files.

Write operations are restricted to two locations:

• .qmmit/ directory — local prompt database and config
• .git/hooks/ — git hook scripts (installed during qmmit init)

The CLI cannot write to any other location in your project. This sandboxed write model prevents accidental modification of your source code.

🔐 Encryption

Credentials are encrypted at rest using AES-256-GCM with a machine-derived key. The encryption key is derived from your machine identity, so tokens are not portable between machines — this limits the blast radius if a credential file is compromised.

All data in transit uses TLS 1.3. The sync API only accepts HTTPS connections.

🔍 Secret Auto-Redaction

Before any prompt data leaves your machine, Qmmit automatically scans for sensitive content:

• AWS access keys and secret keys
• GitHub, GitLab, and Bitbucket tokens
• OpenAI, Anthropic, and other API keys
• JWT tokens and bearer tokens
• Private keys (RSA, SSH, PGP)
• Passwords and connection strings
• Email addresses and IP addresses
• High-entropy strings (Shannon entropy > 4.5)

Detected secrets are redacted silently before sync. You can also run qmmit scan manually to check for secrets at any time.

👤 Authentication & Access Control

🧹 Input Sanitization

All user inputs are sanitized before processing:

• Command injection prevention — dangerous shell characters and patterns blocked
• Prompt injection detection — catches attempts to override AI instructions
• SQL injection prevention — parameterized queries throughout
• Path traversal prevention — ../ sequences stripped from file paths
• Null byte removal — prevents null byte injection attacks

✅ Trust Verification

When you run qmmit init in a new repository for the first time, Qmmit requires explicit confirmation before installing hooks and scanning session files. This prevents accidental tracking of sensitive repositories.

Trusted repositories are recorded in ~/.qmmit/trusted_repos.json using SHA-256 fingerprints of the repository path.

🌐 Network Security

• HSTS with 2-year max-age, includeSubDomains, and preload
• X-Frame-Options: SAMEORIGIN (prevents clickjacking)
• X-Content-Type-Options: nosniff
• Strict Referrer-Policy
• Permissions-Policy blocking camera, microphone, geolocation
• CORS restricted to qmmit.dev origin
• API rate limiting: 60 syncs/hour, 100 prompts per sync

🔏 Privacy Controls

You control what becomes public:

• Every prompt can be set to Public, Private, or Redacted
• Organization repos are auto-detected and forced private
• Private repos stay private — prompts hidden from public profile
• qmmit privacy provides an interactive privacy manager
• qmmit redact <id> redacts specific prompt content

🚨 Reporting Security Issues

If you discover a security vulnerability in Qmmit:

• Do not disclose it publicly
• Email developer@qmmit.dev with detailed reproduction steps
• Allow time for us to address the issue before public disclosure
• We will acknowledge receipt within 48 hours