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.
• read prints 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.

Store-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.