Health information deserves more than a password.

Sign-in is protected with modern password hashing and short-lived session tokens. Optional phone verification adds a second factor for sensitive account actions like password reset, caregiver invitations, and profile deletion.

Caregiver access is invitation-only. From Shared Access on your dashboard, invite a caregiver by email and choose their scope per profile — emergency info, medications, records, or full access. They must sign in with their own account to accept, and can only view the profiles you connect to them.

Every request to view or change a record is checked server-side against row-level security rules that only allow the profile owner or an explicitly authorized caregiver. Roles include Co-Parent, Grandparent, Babysitter, School Nurse, and Teacher — each with a narrower scope than the last. Revoking a caregiver instantly ends their access on every device.

GuardianNest uses a defense-in-depth access model: every data table is protected by Row-Level Security (RLS) policies, and every sensitive permission check is performed by a server-side function that runs with elevated privileges only to verify the caller's identity and relationship to the data.

These functions are marked SECURITY DEFINER so they can read the ownership and caregiver records needed to make a decision, but they still derive the caller's identity from their authenticated session — never from a parameter the caller supplies. For example, when the app checks whether someone can view a profile, it calls a function like is_owner_or_caregiver, which looks up the authenticated user ID and compares it to the profile owner or the approved caregivers list.

Because the check happens inside the database, a client cannot bypass it by manipulating a request. The same pattern is used for admin checks, incoming invite lookups, caregiver grants, and audit logging. This is the mechanism that keeps the "you control every share" promise enforceable on the server, not just in the UI.

Emails such as sign-in confirmations, caregiver invitations, and phone-verification codes are queued internally and processed by a single backend worker. The worker endpoint requires a valid signed JWT, and it explicitly rejects any token that is not issued for service-level operations.

Queue reads are performed through a database wrapper that is only executable by authenticated callers. The worker itself runs with service-role credentials so it can update send logs and move failed messages to a dead-letter queue, but it cannot be triggered by an anonymous or ordinary user request. Rate-limit responses, authentication failures, and delivery errors are logged and retried safely, with a hard cap on attempts before a message is set aside for review.

This design means that even if someone discovered the queue-worker's URL, they could not drain or re-queue messages without a valid service-role token issued by our backend.

GuardianNest runs on managed cloud infrastructure in the United States. Subprocessors are limited to the services we actually use to operate the app — hosting, database, email delivery, SMS delivery, and error monitoring — and each is bound by a data-processing agreement. A current list is available on request.

Encrypted backups are taken on a regular rotation to protect against accidental loss. When you delete a record or close your account, we remove it from production systems within 30 days and it ages out of backups on the standard rotation.

We protect the platform; you protect your account. Use a strong, unique password, enable phone verification, and only invite caregivers you personally trust. If a device is lost or an invited caregiver's status changes, revoke their access from Shared Access.

Security researchers can reach us at security@guardiannest.net. We acknowledge reports within two business days and coordinate disclosure in good faith.