How we protect your data.

Carlo is currently a two-person founding team. Security responsibility sits with the CTO, who oversees all technical architecture, access controls, and incident response.

• Currently implemented: Security decisions are reviewed by both co-founders. All infrastructure changes require code review.
• Planned: As the team grows, we will designate a formal security lead and implement a security review process for all new hires and contractors.

• Least privilege— access to production systems and data is limited to the minimum required for each role.
• Unique accounts— every team member uses individual accounts. No shared credentials.
• Multi-factor authentication (MFA) — MFA is required on all systems that access production data, including source control (GitHub), hosting (Vercel), financial data services (Plaid), and email.
• Role-based access control (RBAC) — currently enforced through GitHub organization roles and Vercel team permissions. Database-level RBAC will be implemented with our production database deployment.
• Access reviews— with a two-person team, access is reviewed continuously. Formal quarterly access reviews will begin when the team exceeds five people.

• Hosting platform— Carlo is deployed on Vercel, which provides enterprise-grade infrastructure including SOC 2 Type II compliance, DDoS protection, and automatic TLS certificate management.
• TLS 1.2+— all data in transit between users and our application is encrypted via TLS 1.2 or higher. We do not support older, deprecated protocols.
• Network isolation— our database (planned: PostgreSQL) will be deployed in an isolated network with no direct public internet access. Connections will be restricted to our application’s compute environment.
• Edge network— Vercel’s global edge network provides automatic geographic distribution and DDoS mitigation.
• No SSH access— our serverless architecture means there are no long-running servers to compromise via SSH. Compute runs in ephemeral, isolated environments.

• Encryption at rest— all stored data will be encrypted using AES-256 or equivalent, managed by our database provider’s encryption-at-rest capabilities.
• Encryption in transit — TLS 1.2+ for all connections: user-to-application, application-to-database, and application-to-third-party APIs.
• Key management— encryption keys are managed by our infrastructure providers (Vercel, database provider) using their key management systems. We do not manage raw encryption keys directly. API keys and secrets are stored in Vercel’s encrypted environment variable system, never in source code.
• Data classification — we treat all user-provided financial data and Plaid-sourced data as sensitive. Access, logging, and retention policies reflect this classification.

• Secure development practices — all code changes go through pull request review before merging to production. The main branch is protected; direct pushes are not allowed.
• Dependency scanning— we run dependency auditing as part of our development workflow and monitor for known vulnerabilities in our dependency tree. GitHub Dependabot alerts are enabled.
• Framework security— Carlo is built on Next.js and React, which provide built-in protections against common web vulnerabilities including XSS (automatic output escaping) and CSRF.
• Input validation— user inputs are validated on both client and server. Database queries use parameterized statements to prevent SQL injection.
• Planned: Static analysis — we plan to integrate automated security scanning (SAST) into our CI/CD pipeline as the codebase grows.

Plaid is our sole conduit for accessing user financial data from institutions. Here is how that integration is secured:

• OAuth-based connections — users authenticate directly with their financial institution through Plaid Link. Carlo never sees or handles bank login credentials.
• Token management— Plaid provides access tokens that let us retrieve data from connected accounts. These tokens are stored encrypted and are scoped to the specific data permissions the user granted.
• No credential storage — we store only Plaid access tokens, never bank usernames or passwords. Tokens can be revoked by the user at any time.
• Minimal data retrieval — we request only the Plaid products (account info, balances, transactions) needed for Carlo’s financial simulations. We do not request identity verification, asset reports, or other Plaid products we do not need.
• Plaid’s security — Plaid maintains SOC 2 Type II compliance, encrypts all data in transit and at rest, and undergoes regular third-party security audits. See Plaid’s security page for details.

Carlo uses Vercel AI Gateway as the only AI provider layer for natural-language features. Product code does not call individual model vendors directly; Gateway routes requests to the selected model with zero data retention enforcement. The integration is secured as follows:

• API keys, never user credentials — AI Gateway is accessed using server-side API keys held only in Vercel’s encrypted environment variable system. Gateway credentials are never exposed to the browser, never embedded in client code, and never logged.
• Server-side calls only — all AI requests are made from server-side code. The browser does not call AI Gateway or model infrastructure directly. This lets us enforce request size limits, sanitize inputs, and apply per-user rate limits.
• Data minimization in prompts — we construct prompts using the minimum context needed to answer the user’s request. We do not pass auth tokens, password hashes, Plaid access tokens, or other secrets into prompts. We do not send full transaction histories when a summarized form is sufficient.
• No training on our data — Carlo sends AI Gateway requests with zero data retention enforcement enabled. If Vercel does not have a ZDR-compliant route for the requested model, the request fails instead of routing to non-ZDR model infrastructure. Under ZDR, Gateway and routed model infrastructure do not retain prompts, outputs, or sensitive data after the request.
• Gateway routing posture — Vercel documents AI Gateway ZDR eligibility and model-route terms on its model pages. References: AI Gateway ZDR, AI Gateway model list.
• Logging boundary— we log AI request metadata (model, latency, error state, user ID, request ID, token counts) for reliability, abuse monitoring, and unit economics. We avoid logging full prompt or response bodies in production telemetry except when explicitly necessary for debugging, in which case the logs are subject to the same retention controls as other server logs (see Data Retention Policy).

If a security incident occurs, we follow this process:

• Detection— monitoring of application logs, error rates, and anomalous access patterns. Vercel provides built-in monitoring and alerting for infrastructure events.
• Response— the CTO is the primary incident responder. Upon detection, the priority is containment (revoking compromised credentials, isolating affected systems) followed by investigation and remediation.
• Notification— in the event of a data breach affecting user data, we will notify affected users within 72 hours of confirming the breach. We will also notify relevant regulatory authorities as required by applicable law.
• Post-incident review — every security incident results in a written post-mortem and action items to prevent recurrence.

• Currently implemented: Dependency scanning via GitHub Dependabot. Critical vulnerabilities in dependencies are patched within 48 hours of disclosure; high-severity within one week.
• Currently implemented: Vercel’s platform handles OS-level patching and runtime security updates automatically.
• Planned for Q3 2026: Third-party penetration testing before public launch, with annual retesting thereafter.
• Planned for Q4 2026: Formal bug bounty or vulnerability disclosure program.

• Currently implemented: Both co-founders use MFA on all accounts, encrypted devices with full-disk encryption, and unique per-service credentials managed through a password manager.
• Currently implemented: Source code access is restricted to the founding team via GitHub organization controls.
• Planned: Background checks for all employees and contractors with access to production data or user financial information, to be implemented as the team grows.
• Planned: Formal security awareness training program for all team members, conducted at onboarding and annually thereafter.

Carlo is a fully cloud-hosted service. We do not operate physical data centers or on-premise servers. Physical security of our infrastructure is managed by our hosting providers:

• Vercel uses AWS infrastructure, which maintains SOC 2, ISO 27001, and other physical security certifications for its data centers.
• Our database provider (planned: managed PostgreSQL) will be selected from providers with equivalent physical security certifications.

Team members’ devices are protected with full-disk encryption and screen lock policies.

• CCPA— we are aware of and designed to comply with the California Consumer Privacy Act. Our Privacy Policy details the rights available to California residents.
• Plaid compliance— our Plaid integration follows Plaid’s data security requirements, including proper token handling, data minimization, and end-user consent flows.
• AI subprocessor diligence — AI requests route through Vercel AI Gateway with ZDR enforcement and route eligibility determined by Gateway routing.
• Planned: SOC 2 Type II — we intend to pursue SOC 2 Type II certification as we approach and pass public launch. The controls described in this document are designed with SOC 2 trust service criteria in mind.

In the interest of transparency, here is a summary of what is operational today and what is planned:

Currently implemented

• TLS 1.2+ on all connections
• MFA on all team accounts
• Encrypted environment variables (Vercel)
• Code review on all changes
• Protected main branch
• Dependency vulnerability scanning (Dependabot)
• Full-disk encryption on team devices
• Password manager for all credentials
• OAuth-based Plaid integration (no credential storage)
• Server-side-only integration with Vercel AI Gateway; Gateway credentials held in Vercel encrypted env vars
• Data minimization in AI prompts (no auth credentials, tokens, or unnecessary PII)
• Vercel platform security (DDoS protection, edge network, SOC 2)

Planned

• Production database with encryption at rest and network isolation
• Database-level RBAC
• Automated SAST in CI/CD
• Third-party penetration testing (Q3 2026)
• Formal vulnerability disclosure program (Q4 2026)
• Background checks for new team members
• Security awareness training program
• Formal quarterly access reviews
• SOC 2 Type II certification

Questions about this Security Policy or our security practices: