Safe Security
Security rules for references, encryption, redaction, audit metadata, connectors, and sharing stubs.
Safe Security
Cuitty Safe treats references as safe to commit and values as sensitive at every boundary.
Value handling
- Never store decrypted values in Cuitty Code, Registry, Site, logs, wire-protocol fixtures, desktop snapshots, or docs examples.
- Never place decrypted values in URLs, trace spans, audit payloads, crash reports, or generated config unless the user explicitly requested an output file.
readprints to stdout and must be treated as sensitive.- Terminal masking defaults to enabled.
- Errors must redact values before leaving provider code.
Encryption
Inline encrypted values must use authenticated encryption, not reversible obfuscation.
INLINE_ONLY=csafe:v1:aes-256-gcm:kid_localdev:base64url-nonce:base64url-ciphertext
Envelope metadata should include version, algorithm, key id, nonce, ciphertext, and optional authenticated data. Authenticated data should include the account/safe/secret ref, file path when available, and configured purpose.
Local vaults
Local vaults store encrypted records and keep key material in the OS credential store when available. Headless passphrase fallback requires explicit opt-in. Vaults should lock after inactivity.
Connector safety
1Password connector metadata may include vault names, item titles, field names, and object IDs. It must not cache secret values by default.
Persist-backed Safes require E2EE and alpha acknowledgement. Remote writes are blocked unless encryption is required.
Audit
Audit events are metadata-only:
reference, actor, process, provider, result, timestamp
Secret values are never audit fields. Reference hashing may be enabled where secret names are themselves sensitive.
Sharing
Sharing is a v0 stub. Future sharing is planned for Cuitty Auth grants, but v0 does not create invite links, cross-user decrypt grants, or direct provider token sharing.