Who gets in, and on what terms.

• Least privilege— every person and system gets the minimum access required to perform their function. Nothing more.
• Need to know— access to consumer financial data is granted only when there is a documented business need.
• Unique identity— every access is tied to an individual account. No shared credentials, no generic accounts.
• Defense in depth— no single control is sufficient. Authentication, authorization, network controls, and monitoring work together.
• Default deny— access is denied unless explicitly granted. New systems, new team members, and new integrations start with zero access.

Multi-factor authentication (MFA)

MFA is required on all systems that access production assets or sensitive data. There are no exceptions.

Non-human authentication (service-to-service)

All automated and service-to-service communication uses cryptographic authentication rather than shared secrets:

• Plaid API— OAuth 2.0 tokens for all data retrieval. User-level access tokens are scoped to specific permissions and revocable.
• Vercel deployments— TLS-authenticated connections between compute functions and external services. Deploy tokens are scoped per project and environment.
• Database connections — (planned) TLS-encrypted connections with certificate verification. No plaintext database connections permitted.
• GitHub integrations— OAuth tokens and deploy keys for CI/CD. No long-lived personal access tokens in automation.

Password requirements

• All credentials are generated and stored in a team password manager.
• Minimum 16 characters for service accounts and API keys.
• No credential reuse across services.
• No credentials in source code, environment files committed to git, or chat messages.

All team access is managed through centralized identity providers rather than per-system local accounts:

• GitHub Organization — serves as the primary identity hub for engineering access. Organization-level SSO and MFA enforcement. Repository access, branch protection, and deploy permissions are all managed from the org level.
• Vercel Team— team membership and role assignments managed centrally. Linked to GitHub identity for deployment authorization.
• Google Workspace— centralized email and identity for all team communications and third-party SaaS access (where Google SSO is available).
• Planned: SSO consolidation — as the team grows, we will consolidate to a single SSO provider to manage access across all systems from one control plane, with centralized audit logging of all authentication events.

Access to production systems is granted based on role. Currently, Carlo has two roles. This table will expand as the team grows.

As the team grows, we will implement granular roles including: read-only database access for support, deploy-only access for junior engineers, and admin access restricted to senior engineering.

Source control (GitHub)

• Repository access is managed through a GitHub organization with SSO and MFA enforced.
• The main branch is protected: direct pushes are blocked, pull request reviews are required.
• Branch protection rules prevent force pushes and require status checks to pass before merging.

Hosting and deployment (Vercel)

• Production deployments are triggered only from the protected main branch via Vercel’s Git integration.
• Environment variables (including Plaid API keys) are stored in Vercel’s encrypted secret store, scoped to specific environments (production, preview, development).
• Vercel team access is limited to the founding team with admin roles.

Database (planned)

• Production database will be deployed in an isolated network, accessible only from our application’s compute environment.
• No direct public internet access to the database.
• Database credentials will be rotated on a regular schedule and stored in Vercel’s encrypted environment variables.
• Database-level RBAC will restrict query permissions by role (application user vs. admin).

Plaid API access

• Plaid API keys are stored in Vercel’s encrypted environment variables, never in source code.
• Plaid access tokens (per-user) are stored encrypted in our database, accessible only through the application layer.
• Plaid Dashboard access is restricted to the CTO for configuration and monitoring.

Consumer financial data (account info, balances, transactions from Plaid) receives the highest level of access restriction:

• Application-level access only — consumer data is accessed through the application layer, never through direct database queries in normal operations.
• User-scoped queries — the application enforces that users can only access their own financial data. Every database query for consumer data includes user-scoping.
• No bulk export— there is no administrative function to bulk export consumer financial data. Data access is per-user, per-request.
• Audit logging— (planned) access to consumer financial data through administrative channels will be logged with timestamp, accessor identity, and justification.
• No data in logs— consumer financial data (account numbers, balances, transaction amounts) is never written to application logs. Logs contain only request metadata.

Carlo requires authentication before consumers can access Plaid Link or any financial data:

• Account creation— email verification required before any financial features are accessible.
• MFA for consumers— multi-factor authentication will be available and encouraged for all consumer accounts. MFA will be required before Plaid Link is surfaced for the first time.
• Session management— sessions expire after a period of inactivity. Re-authentication is required for sensitive actions (connecting new accounts, exporting data, deleting account).
• Plaid Link— Plaid’s own OAuth flow provides additional authentication at the institution level. The consumer authenticates with their bank directly through Plaid’s secure interface.

• Continuous review— with a two-person team, access is reviewed continuously as part of daily operations.
• Formal reviews— quarterly access reviews will be implemented when the team exceeds five people. Reviews will verify that all access grants are still justified and revoke any that are not.
• Offboarding— when a team member or contractor departs, all access is revoked within 24 hours. Credentials are rotated for any shared infrastructure they had access to.
• Contractor access— contractors receive time-limited access tokens scoped to specific systems. Access expires automatically at the end of the engagement.

All team devices that access production systems or source code must meet these requirements:

• Full-disk encryption enabled (FileVault on macOS).
• Automatic screen lock after 5 minutes of inactivity.
• Operating system kept up to date with latest security patches.
• No production data stored locally on devices — all consumer data lives in the production database only.
• Password manager used for all credentials — no credentials stored in browsers, text files, or notes.

This Access Control Policy is reviewed at least annually, or whenever there is a significant change to team composition, infrastructure, or data handling practices. The next scheduled review is April 2027.

Questions about this policy or access control practices: