How we protect your data.

Security responsibility sits with Carlo’s CTO, including system architecture, production access, incident response, and remediation. The founders receive reports sent to security@carlo.finance.

Production and infrastructure changes are recorded in source control and deployment logs. Carlo does not currently claim that every change receives a second-person review.

• Application authorization — protected application reads and writes resolve an authenticated actor, scope database access to the active organization, and enforce the capability required for the action.
• Production access — provider accounts and credentials are limited to the founding team and automated systems that need them. Shared human accounts are not the intended access model.
• MFA and SSO — MFA is used where it is enabled on individual provider accounts, but Carlo’s GitHub organization does not currently enforce organization-wide MFA or SSO. Carlo does not claim blanket MFA enforcement across every production service.
• Secrets — application secrets are supplied through Vercel environment storage or AWS Secrets Manager and are not committed to the repository.

• Web application — carlo.finance is deployed on Vercel and served over HTTPS.
• Workflow service — durable workflow execution runs on two AWS ECS Fargate tasks behind an application load balancer and web application firewall. The tasks run in private subnets and do not expose SSH access.
• Databases — the application database and the separate workflow database are operational managed Neon Postgres databases. Database connections use credentials supplied to the application and worker at runtime.
• Transport security — browser traffic and service connections use TLS. Provider credentials and user bank credentials are not sent to the browser by Carlo’s server code.

• Stored application and workflow data uses managed Neon storage; uploaded originals use Carlo-controlled Amazon S3 storage. These providers supply their managed encryption-at-rest controls.
• Connections from users, the application, the workflow worker, and third-party APIs use TLS.
• User-provided financial data, provider data, access tokens, and uploaded documents are treated as sensitive and are subject to the access, logging, and retention boundaries described here and in the Data Retention Policy.

• Authorization and validation — protected server routes perform authentication, organization scoping, capability checks, and input validation. Database access uses parameterized queries.
• Source-control reality — direct pushes to main are currently permitted. GitHub branch protection and mandatory pull-request review are not enforced on the current repository plan.
• Automated checks — pushes to main trigger type checking, linting, and tests. The production workflow builds the exact target commit, runs database migrations and smoke checks, verifies application and workflow compatibility, and promotes only after those deployment checks converge.
• Worker image scanning — the ECS worker image is gated on an Amazon ECR vulnerability scan with reviewed, time-bounded exceptions for any allowed high or critical finding.
• Not claimed today — GitHub Dependabot alerts, automated SAST, mandatory two-person review, and enforced protected-branch status checks are not represented here as current controls.

• Consumers authenticate with their institution through interfaces supplied by providers such as Plaid and SnapTrade. Carlo does not receive the consumer’s bank or brokerage password.
• Provider access tokens are stored for server-side use and are not exposed to the browser. They are scoped by the permissions granted through the provider connection and can be revoked by disconnecting the account.
• Carlo requests provider products needed for connected-account, balance, holding, and transaction features rather than treating a connection as permission to retrieve every available product.

AI requests are made from server-side code using Carlo-controlled provider credentials. Provider credentials, authentication secrets, and financial-connection access tokens are not included in prompts.

Requests can include the financial context needed to answer a user or the document content needed for extraction. Carlo selects provider account settings that do not use customer content to train provider models, but provider processing and retention remain governed by each provider’s terms and configuration. See the Privacy Policy for the current provider and analytics disclosures.

AI server logging is intended to retain request metadata rather than full prompt and response bodies except when content is explicitly needed for debugging under the normal log-retention controls. This is separate from PostHog product analytics and session replay, which are described in our Privacy Policy.

When Carlo confirms a security incident, the response priority is to contain access, rotate or revoke affected credentials, determine the data and systems involved, remediate the cause, and preserve a record of the response. Carlo will notify affected people and authorities as required by applicable law; this policy does not promise an earlier universal deadline than the law requires.

The following controls are not represented as implemented today:

• Enforced GitHub branch protection and mandatory PR review.
• Organization-wide SSO and MFA enforcement across every service.
• Consumer MFA and step-up reauthentication.
• Automated SAST, an independent penetration test, and SOC 2 Type II certification.
• A formal bug-bounty program and formal quarterly access reviews.

These are candidates for future hardening, not certifications or guarantees about the current service.