Information Security Policy

1. Access Control Policy

Envi operates a least-privilege access model. Access to systems and data is granted only to individuals who require it to perform their defined responsibilities. All access is role-based and formally tracked.

1.1 Developer and Administrator Access

• Access to production systems (Supabase, GitHub, Firebase, Plaid Dashboard, Apple Developer, Google Play Console) is restricted to the sole operator by default.
• Contractors are granted the minimum permissions necessary for the specific engagement and no others.
• All administrative access requires Multi-Factor Authentication (MFA). See Section 6.
• Shared credentials are prohibited. Each individual with system access holds their own authenticated identity.
• Production secrets (API keys, service account credentials) are stored exclusively in environment variable stores (Supabase project secrets, CI/CD secrets) and never hardcoded in source code.

1.2 Application-Level Access

• End-user access to Envi application data is enforced at the database level via Supabase PostgreSQL Row-Level Security (RLS) policies.
• RLS ensures that each authenticated session can only read or write records belonging to that user's account.
• No cross-user data access is possible through the application layer, even if exploited.

1.3 Third-Party Access

• Third-party integrations (Plaid, Firebase, OpenRouter) are granted API-key-scoped access only. No third party holds administrative credentials to Envi's primary systems.
• Plaid access tokens are stored server-side in Supabase; the mobile application never receives or caches Plaid access tokens directly.

2. Periodic Access Reviews and Audits

Envi conducts formal access reviews on an annual basis, or following any significant personnel change (e.g., end of a contractor engagement).

• Scope: All production systems, including GitHub repository collaborators, Supabase project members, Firebase service accounts, CI/CD secrets, and third-party API keys.
• Process: The operator reviews each system's access list, revokes any unnecessary permissions, and rotates credentials that have been dormant for more than 90 days.
• API Key Rotation: All production API keys are rotated at least annually or immediately upon suspected compromise.
• Audit Logging: Supabase audit logs and GitHub access logs are reviewed during each access review cycle.
• Documentation: The outcome of each review is recorded in the project's security log with the date and actions taken.

3. Zero Trust Access Architecture

Envi's infrastructure is designed on zero trust principles: no user, device, or network is implicitly trusted. All access to systems and data requires explicit verification.

• No implicit network trust: All service-to-service communication occurs over TLS. There are no allowlisted IP ranges that bypass authentication. Edge functions and Supabase endpoints require valid authentication on every request.
• Identity verification at every layer: The mobile application authenticates with Supabase JWT tokens. The backend (Supabase Edge Functions) validates these tokens on every request before processing any financial data. Database operations are additionally gated by RLS policies regardless of the calling layer.
• Least privilege by default: Supabase service roles are not used in client-facing code. Application logic runs with the authenticated user's permissions, not elevated service-role permissions.
• Secrets isolation: Production credentials are not accessible in development environments. Local development uses sandbox credentials only.
• Continuous verification: User sessions expire and require re-authentication. Plaid access tokens are stored server-side and never exposed to the client.

4. Centralized Identity and Access Management

Envi uses a layered, centralized identity model with a single authoritative identity provider at each tier.

4.1 Application (End-User) Identity

• Supabase Auth serves as the centralized identity provider for all Envi end-users.
• Authentication state is managed via Supabase JWT tokens. All downstream systems (database, edge functions) derive authorization from the same Supabase identity.
• There is no parallel identity system. Disabling a user in Supabase Auth immediately revokes all application access.

4.2 Developer and Infrastructure Identity

• All developer tooling (GitHub, Firebase Console, Google Play Console, Apple Developer) uses Google account sign-in, consolidating developer identity under a single Google identity.
• Revoking the Google account or disabling it in Google Workspace immediately propagates to connected services.
• Service accounts (Firebase FCM, Google Play) are scoped to individual projects and managed through Google Cloud IAM.

5. Access De-provisioning

Access is revoked promptly and systematically when an individual's need for access ends.

5.1 Contractor and Vendor Off-boarding

• Upon completion or termination of any contractor engagement, access is revoked within 24 hours across all systems to which the contractor had access.
• This includes: removal from GitHub repository collaborators, revocation of any scoped API keys issued for the engagement, and removal from any Supabase project access.
• Any credentials shared during the engagement are rotated immediately after off-boarding.

5.2 Automated Enforcement via Centralized IAM

• Because developer tooling is consolidated under Google account identity (Section 4.2), disabling or revoking the central Google identity immediately terminates access to all connected services without requiring manual per-system removal.
• Supabase Auth user accounts can be disabled in a single action through the Supabase dashboard, immediately invalidating all active sessions and JWT tokens for that user.

5.3 Solo Operator Note

Envi is operated by a single individual. There are no full-time employees beyond the sole proprietor. De-provisioning procedures apply to all contractors and external collaborators.

6. Multi-Factor Authentication (MFA)

6.1 Developer and Administrative Systems

• MFA is required on all administrative accounts: GitHub, Supabase Dashboard, Firebase Console, Google Play Console, and Apple Developer account.
• Authenticator-app-based TOTP is the required second factor. SMS-based MFA is not used for production systems.

6.2 Consumer-Facing Application

• The Envi mobile application (where Plaid Link is deployed) uses Supabase Auth, which supports TOTP-based MFA.
• MFA is offered to end-users and enforced on accounts that connect financial institution data via Plaid.

7. Vulnerability Management and Patching SLA

Envi monitors for vulnerabilities in application dependencies and infrastructure, and remediates them according to the following defined SLAs.

7.1 Severity Definitions and Patch Timelines

• Critical (CVSS 9.0–10.0): Patch or mitigate within 7 calendar days of identification.
• High (CVSS 7.0–8.9): Patch within 30 calendar days of identification.
• Medium (CVSS 4.0–6.9): Patch within 90 calendar days of identification.
• Low (CVSS 0.1–3.9): Addressed in the next planned maintenance cycle, within 180 days.

7.2 Monitoring and Detection

• GitHub Dependabot is enabled on the Envi repository to surface dependency vulnerabilities automatically.
• Security advisories from Supabase, Firebase, Plaid, and React Native are monitored via their official channels.
• App Store and Play Store releases are reviewed for security-impacting SDK updates before each submission.

7.3 Tracking

Identified vulnerabilities are logged in the project's security issue tracker with severity classification, identification date, and resolution date. This log is reviewed during annual access reviews.

8. Incident Response

• Detection: Security incidents are identified through monitoring alerts, user reports, or third-party notifications.
• Containment: Upon confirmation of a breach or suspected compromise, affected credentials are rotated immediately and implicated access is revoked.
• Notification: Affected users are notified within 72 hours of confirmed data exposure, consistent with applicable data protection requirements.
• Post-incident review: Root cause analysis is documented and corrective actions are implemented within 30 days.
• Contact: Security incidents can be reported to privacy@envi.money.

9. Data Handling and Encryption

• Encryption in transit: All communication between the mobile application and Envi's backend uses TLS 1.2 or higher. No financial data is transmitted over unencrypted channels.
• Encryption at rest: User data stored in Supabase (PostgreSQL) is encrypted at rest using AES-256 by the hosting infrastructure.
• Plaid tokens: Plaid access tokens are stored server-side in Supabase with access restricted by RLS. They are never transmitted to or stored on end-user devices.
• Credential handling: No production credentials, API keys, or service account files are committed to source control. All secrets are managed through environment variable systems.

10. Policy Owner

This Information Security Policy is owned and maintained by the Envi operator. Questions, concerns, or requests related to this policy should be directed to:

Email: privacy@envi.money
Effective date: June 9, 2026
Review cycle: Annual (next review: June 2027)