Security is designed for sensitive letters, not generic documents.

Session material is stored using OS-backed secure device storage rather than casual local persistence.

That reduces the chance that account access is exposed through ordinary app storage paths.

Mitletter uses authenticated API access and managed sessions to connect the device to the backend account.

Session handling should remain short-lived enough to limit risk while still keeping the product usable.

Where supported, users can enable biometric app lock such as Face ID or Touch ID to add a gate before opening the vault.

That helps protect document access when the device itself is shared or briefly unattended.

The backend stores document payloads, reminders, and uploaded assets required for sync and retrieval. When configured, server-side records can be encrypted at rest.

That protection matters because Mitletter often stores the original scan alongside the structured result.

The service is designed with access boundaries, stored-record protection, and limited-purpose provider sharing in mind.

Security still depends on the deployed environment, infrastructure, and how the backend is configured.

Mitletter does not auto-send replies or take irreversible action on the user's behalf. The user remains in the approval loop before external communication happens.

That reduces the risk of the system acting on the wrong interpretation without review.

Good security also depends on device hygiene, account credentials, and reviewing outputs before acting on them.

For security questions or incident-related support, contact support@mitletter.com.