Invio v1.0.0.1.11 stores provider credential values through the owner-approved Python keyring integration and requires an approved OS-protected backend. There is no plaintext-file fallback. The normal operational SQLite database stores only an opaque credential reference, and application settings remain non-sensitive.

If protected credential storage is unavailable, Account persistence fails closed. If a persisted credential entry is missing/unreadable at startup, the Account metadata is retained but the runtime Account is restored as Not Verified, so the existing P01 Task gates prevent execution.

Do not include provider secrets, exported logs containing sensitive customer data, or local per-user application databases in issues, pull requests, commits, screenshots, or diagnostic archives.

Use the repository's private/security reporting channel where available. Do not publish active provider credentials or customer data in a public issue.

P02 protects credential persistence. Recipient-level delivery reconciliation, generalized PII/log redaction, and full live/native security certification are later production roadmap phases and are not claimed by this release.

P03 verification error summaries are scrubbed against the Account credential values before durable storage.

v1.0.0.1.11 additionally persists a fail-closed Not Verified downgrade when protected credentials are missing/unreadable and stages Account Edit with a durable Not Verified safety marker before crossing the SQLite/keyring boundary. Migration backups use SQLite backup semantics so committed WAL state is not omitted.