Security and Trust

Security and Trust

SithInsta is local-first and evidence-bound. Its compatibility HTTP server is intended for loopback operation, not direct exposure to the public internet.

Default Boundary

• The default bind address is 127.0.0.1.
• A non-loopback bind requires --allow-network, a strong SITH_API_TOKEN, and an explicit SITH_ALLOWED_HOSTS or --allowed-hosts allowlist.
• Production access must sit behind authenticated TLS or a private VPN.
• The built-in bearer token is a transport guard, not multi-user identity, role-based authorization, tenant isolation, edge rate limiting, or TLS.
• Local LLM and CLI targets are restricted to loopback HTTP, reject redirects, ignore environment proxies, and enforce bounded payloads.

Evidence Rules

• Findings, graph edges, model outputs, and identity hypotheses should retain evidence references and timestamps.
• Model output is review material, not proof of identity, intent, ideology, coordination, or criminal conduct.
• Original evidence remains primary; OCR and depth artifacts are derived material.
• EvidenceVault verification is anchored to the installation key under data/vault_keys/. Back up and protect that key separately from vault packages.

Sensitive Data

Never commit tokens, passwords, cookies, account credentials, private keys, case evidence, databases, logs, model caches, or vault material. Keep config/instagram_accounts.local.json local and use environment-variable references rather than plaintext passwords.

The private Hugging Face model mirror is for approved model artifacts only. It must never contain source code, case material, credentials, logs, databases, or vaults.

Before Network Deployment

1. Read the versioned SECURITY.md.
2. Put the API behind authenticated TLS or a private VPN.
3. Add user identity, role-based authorization, case or tenant isolation, and edge rate limiting.
4. Use a secret manager and narrow service credentials.
5. Prove encrypted backup and restore procedures.
6. Run a dedicated threat model and deployment security review.

Vulnerability details should be reported privately to the repository owner rather than opened as a public issue.