Who gets in, and on what terms.

• Least privilege — grant only the access needed for the task.
• Unique identity — use individual provider accounts for human access rather than shared logins.
• Default deny — authenticated access and an explicit authorization check are required for protected application data.
• Defense in depth — application authorization, secret storage, provider controls, network boundaries, and deployment checks operate together.

Team access is currently managed separately in GitHub, Vercel, AWS, Google, Neon, Plaid, SnapTrade, and other providers. Carlo does not currently operate one centralized identity provider across all of them.

• MFA is used where it is enabled on individual provider accounts, but Carlo does not claim that every provider enforces it.
• The GitHub organization does not currently enforce organization-wide MFA or SSO. Repository roles are managed at the organization and repository level.
• Provider memberships are restricted to people who need access and are revoked when the need ends. Formal quarterly access reviews are not yet an implemented control.

• Application secrets are supplied at runtime through Vercel environment storage or AWS Secrets Manager and are excluded from source control.
• Database connections use TLS-capable managed Neon endpoints and runtime credentials. The application database and the separate workflow database are both operational today.
• Financial-data provider credentials and per-user access tokens are used only in server-side code and are not exposed to browsers.
• GitHub Actions uses scoped credentials and AWS identity federation for deployment workflows rather than embedding production secrets in the repository.

Source control

Direct pushes to main are currently permitted. The repository plan does not enforce branch protection, mandatory pull-request review, or required status checks before a push lands.

Pushes to main trigger automated type checking, linting, and tests. The production deployment workflow builds and verifies the exact target commit before promotion. These checks reduce risk, but they are not a substitute for enforced branch protection.

Hosting and workers

The web application runs on Vercel. Durable workflow execution runs on AWS ECS Fargate behind an application load balancer and WAF, with tasks in private subnets. Access to each provider is managed through that provider’s team roles and runtime secrets.

Databases

Carlo uses a managed Neon Postgres application database and a separate managed Neon workflow database. Normal consumer-data access goes through application or worker code. Limited administrative tooling can access a database for approved operational work, so Carlo does not claim that direct administrative access is impossible.

• Protected application operations resolve the authenticated actor and active organization before reading or writing financial data.
• Organization-scoped queries and capability checks are the primary application authorization boundary.
• There is no general-purpose administrative UI for bulk exporting every household’s financial data.
• Application logs are intended to exclude secrets and raw provider credentials. Product analytics and session replay have separate disclosures in the Privacy Policy.

• Carlo supports email-and-password sign-in and Google sign-in. An authenticated session is required before protected financial data or connection flows are available.
• Consumer email verification and consumer MFA are not currently required. Carlo does not claim that MFA is required before Plaid Link is shown.
• Standard sessions last up to seven days and refresh daily while in use. Carlo does not currently enforce separate step-up reauthentication for connecting an account, exporting data, or deleting an account.
• Plaid Link or another provider interface handles institution-level authentication. Bank and brokerage credentials go to the institution/provider flow, not to Carlo.

Provider access should be removed when a team member or contractor no longer needs it, and affected shared infrastructure credentials should be rotated when appropriate. Contractor access is not represented as automatically expiring unless the underlying provider actually enforces an expiry.

Production data is not part of ordinary local development. Approved operational or debugging workflows can create protected local copies, so Carlo does not claim that production data can never be present on a team device. Local copies and credentials remain subject to device encryption, access restrictions, and deletion when no longer needed.

• Centralized workforce SSO across all providers.
• Organization-wide MFA enforcement across all providers.
• Protected main with mandatory review and required checks.
• Consumer MFA, mandatory email verification, and step-up reauthentication.
• Formal quarterly access reviews and centrally enforced contractor-token expiry.

This policy is reviewed when access controls, authentication, infrastructure, or team composition changes materially, and at least annually. Public claims should be updated when implementation changes.