Security Model
Encryption, audit trails, and TRCAA's threat model.
TRCAA handles sensitive incident data by design — log files that may contain credentials, PII, and internal infrastructure details. The security model addresses five areas: data at rest, data in transit, secret storage, audit trail, and least privilege.
Encryption
| What | How |
|---|---|
| Database at rest | SQLCipher, AES-256-CBC, PBKDF2-HMAC-SHA512 (256,000 iterations) |
| API keys / credentials | AES-256-GCM, random nonce per encryption |
| Kubeconfig files | AES-256-GCM at rest |
| Offline license certificate | Ed25519 signature verification |
PII redaction before any send
No text reaches an AI provider without passing through detection and approval first — see PII Detection for the full pattern list.
Tamper-evident audit trail
Every external data transmission is logged — provider, model, content hash, and timestamp. Audit entries are hash-chained:
prev_hash— hash of the previous audit entryentry_hash— SHA-256 of the current entry plusprev_hash
This makes post-hoc modification of the audit log detectable, not just logged.
Least-privilege by default
| Plugin | Permissions |
|---|---|
| dialog | open / save only |
| fs | read/write scoped to app dir and temp |
| shell | open only — no arbitrary shell by default |
| http | connect only to approved origins |
Content Security Policy
HTTP is blocked by default. Only a whitelisted set of HTTPS AI provider endpoints (plus localhost for Ollama) are reachable from the app at all.
No telemetry
Zero analytics, crash reporting, or usage tracking. What TRCAA sends externally is limited entirely to what you explicitly configure — AI provider calls (post-redaction) and, if enabled, your chosen integrations.