Skip to content

Security: Chati-dev/Chati.dev

Security

.github/SECURITY.md

Security Policy

Supported Versions

Version Supported
3.0.x ✅ Current
2.x ❌ Not supported — upgrade to 3.0.x
< 2.0 ❌ Not supported

We recommend always running the latest version. Use npx chati-dev check-update to verify.

Reporting a Vulnerability

If you discover a security vulnerability in Chati.dev, please report it responsibly.

How to Report

  1. Do NOT open a public GitHub issue for security vulnerabilities
  2. Email security@chati.dev with details
  3. Include:
    • Description of the vulnerability
    • Steps to reproduce
    • Potential impact assessment
    • Affected versions
    • Suggested fix (if any)

We will acknowledge your report, assess severity, and coordinate a fix with you.

Scope

In Scope

Area Examples
Agent System Prompt injection that bypasses Session Lock, Constitution enforcement, or write scope isolation
Terminal Spawning Write scope escape, model bypass, or unauthorized parallel execution
CLI Installer Path traversal, command injection, arbitrary file write
Session State Credential exposure in session.yaml or CLAUDE.md
System Files Injection via templates, workflows, or intelligence files
Memory Layer Unauthorized access to stored memories across projects
Generated Artifacts Secrets or credentials in generated code or documentation

Out of Scope

  • Vulnerabilities in third-party npm dependencies (report to upstream maintainers)
  • Issues requiring physical access to the machine
  • Social engineering attacks
  • Denial of service via resource exhaustion
  • Security issues in the user's own project code (not generated by Chati.dev)

Security Architecture

Design Principles

  1. Least Privilege: Agents operate within their designated scope (Article I, XI)
  2. No Secrets in System: Credentials are referenced by name only — never stored (Article IV)
  3. Session Isolation: .chati/session.yaml and .chati/memories/ are gitignored by default
  4. Constitution Enforcement: Security violations halt the pipeline (Article IV)
  5. Session Lock: Active sessions cannot be bypassed to access raw AI mode (Article XV)
  6. Supply Chain Integrity: Ed25519 manifest signing on publish, verified on install (Article IV)
  7. Read Protection: Sensitive file reads blocked by hook before execution (Article IV)

Supply Chain Security

Package integrity is enforced through cryptographic signing:

Stage What Happens
Publish sign-manifest.js generates SHA-256 hash for every framework file, signs the manifest with Ed25519 private key, embeds signature + public key in package
Install npx chati-dev init verifies Ed25519 signature against public key, validates per-file SHA-256 hashes, blocks installation if tampered
Validation npx chati-dev health includes manifest integrity check

The signing key (signing-public-key.pem) is embedded in the package. The private key is never published.

Read Protection

A Claude Code PreToolUse hook (read-protection.js) blocks reads of sensitive files:

Blocked Pattern Example
.env, .env.* (except .env.example) .env.production, .env.local
*.pem (except signing-public-key.pem) server.pem, private.pem
*.key server.key, tls.key
credentials.*, secrets.* credentials.json, secrets.yaml
.git/config May contain access tokens

Multi-Terminal Security

Autonomous agents run in separate claude -p terminals. Security measures:

Control Implementation
Write Scope Isolation Each agent's write scope is enforced via prompt instructions. Parallel agents have disjoint write paths validated before spawning.
Model Enforcement The --model flag is set by construction — agents cannot switch to a different model at runtime.
--dangerously-skip-permissions Used for spawned terminals because claude -p cannot prompt users interactively. Mitigated by: write scope enforcement in prompt, Constitution guard hook, mode governance hook.
Prompt Integrity Prompts are piped via stdin (not CLI args) to prevent shell injection. Context is self-contained — no external file references at runtime.
Parallel Validation validateWriteScopes() blocks parallel groups with overlapping write paths before spawning.

Security-Relevant Constitution Articles

Article Security Control
IV No destructive operations without confirmation. No secrets in system files. SAST mandatory.
XI Mode governance restricts write scope. Planning mode cannot modify project code.
XIII Memory Layer never auto-modifies user files. Proposals require explicit approval.
XV Session Lock prevents accidental system escape. Exit requires explicit intent.
XVI Model governance — no downgrade from assigned model. Cost tracking logged in session.

Security Best Practices

When using Chati.dev:

  1. Never commit secrets: Ensure .env, credentials, and API keys are in .gitignore
  2. Review generated files: Check CLAUDE.md and session.yaml before sharing projects
  3. Keep updated: Run npx chati-dev check-update regularly
  4. Verify installations: Run npx chati-dev health to validate system integrity
  5. Audit memories: Periodically review .chati/memories/ for sensitive content
  6. Use SAST: The QA-Implementation agent runs SAST scanning — don't skip it

Disclosure Policy

We follow responsible disclosure:

  1. Reporter submits vulnerability via security@chati.dev
  2. We acknowledge receipt and assess severity
  3. We develop and test a fix
  4. We coordinate release timing with the reporter
  5. We publish the fix with a security advisory
  6. We credit the reporter (unless they prefer anonymity)

Security is a pipeline requirement, not an afterthought.
Chati.dev © 2026

There aren’t any published security advisories