Information Security Policy

KYLE LifeOS is a single-user personal finance and life-tracking application built and operated by Kyle Neumeier for his own use. It is not a commercial product and is not offered to other users: there is no sign-up, and the only person whose data is processed is the operator, who is the account holder of every connected financial institution.

This policy documents the operationalized controls protecting that data, including financial data retrieved via Plaid. It covers the application, its hosted infrastructure, and the operator's administrative access to both. Kyle Neumeier is the sole operator and is solely responsible for information security; he can be reached at support@kyleneumeier.com.

Only the Plaid Transactions product is requested. The Auth, Identity, Assets, Income, and Liabilities products are not enabled, so the application never receives full account or routing numbers, government identifiers, or identity-verification data.

The most sensitive data held is therefore:

• Account name, type, and masked number (last four digits only)
• Current and available balances
• Transaction history — date, amount, description, and merchant
• Plaid access tokens (encrypted at rest, see below)

Banking credentials are never transmitted to, seen by, or stored by this application; they are entered directly with Plaid or the institution's own OAuth page. Health and fitness data held in other areas of the application is treated at the same sensitivity level as financial data and is subject to every control below.

Application access requires authentication via Supabase magic-link or passkey plus a time-based one-time-password (TOTP) second factor, restricted to a single hard-allowlisted email address. The request proxy rejects any authenticated identity other than that address and redirects any session that has not been elevated to AAL2 through the TOTP challenge. Every API route independently re-verifies the server-side session, the allowlisted identity, and the TOTP elevation before executing; webhooks and scheduled jobs, which carry no session, are authenticated as described under infrastructure below.

Database access is server-side only. Row-level security is enabled on every table with no policies — a deny-all at the public API boundary — and the application performs no client-side table reads. Administrative accounts (GitHub, Vercel, Supabase, Plaid, Anthropic) require two-factor authentication and follow least-privilege. There are no shared accounts, no other human users, and no third-party access.

All traffic is served over HTTPS/TLS 1.2+. Plaid access tokens are encrypted at the application layer with AES-256-GCM using a 256-bit key held as an environment secret and never written to the database, so a database disclosure alone yields no usable token. The underlying PostgreSQL database and object storage are additionally encrypted at rest by Supabase.

The application is hosted on Vercel; the database, authentication, and object storage are managed by Supabase. Neither the operator nor the application maintains self-managed servers, physical infrastructure, or office networks. Storage buckets holding photos are private and served only through short-lived signed URLs.

Inbound webhooks are authenticated: Plaid webhooks are verified using Plaid's signed Plaid-Verification JWT — ES256 signature validation against Plaid's published key, a request-body SHA-256 match, and a five-minute freshness window that rejects replays. A request without a valid signed token is rejected; there is no shared-secret fallback. Other integration webhooks and all scheduled jobs are gated by shared secrets. Secrets live in environment configuration and are never committed to source control.

The application relies on the following subprocessors, each an established provider acting on the operator's behalf under its own published security program:

• Plaid — bank connectivity and transaction data
• Supabase — database, authentication, object storage
• Vercel — application hosting and scheduled jobs
• Anthropic — transaction categorization and the in-app assistant
• OpenAI — optional voice transcription and speech synthesis
• Google — optional calendar and mail integration, only if connected by the operator

No subprocessor receives banking credentials or full account numbers. Financial data sent to Anthropic for categorization is limited to transaction descriptions and amounts and is not used to train models. When the operator asks the in-app assistant about finances, it may read stored balances and transactions to answer; no credential or full account number exists in the application to send. Because the operator is the only data subject, no subprocessor processes any other person's data. New subprocessors are reviewed for their security posture and data handling before adoption, and this list is updated when one is added or removed. Error reporting through Sentry is built into the code but not enabled, so Sentry receives no data; it will be added here if that changes.

Application and platform request logs are retained by Vercel, for the short retention window of the hosting plan; database and authentication logs are retained by Supabase. Unhandled application errors appear in the Vercel runtime logs. There is no separate error-tracking service in use: Sentry is integrated in the code but not enabled.

Scheduled jobs are wrapped in a failure alerter that delivers a push notification to the operator on any throw or 5xx, so a silently failing background job surfaces rather than degrading unnoticed. Because there is exactly one authorized identity, any successful sign-in that the operator did not perform is by definition anomalous, and authentication events are reviewable in the Supabase dashboard.

The database runs on Supabase's free plan, which does not provide restorable database backups, and no separate backup is currently maintained. Financial data is the least exposed to that gap: it can be re-derived in full by re-syncing from Plaid. Source code is version-controlled in Git and mirrored to GitHub; infrastructure is reproducible from that repository, and the application can be redeployed from source. Environment secrets are held in the hosting provider's encrypted configuration store.

As a single-user application with no external customers, there is no service-level commitment and no business-continuity obligation to third parties. An outage or data loss affects only the operator.

The application is written in TypeScript under strict mode. Every input boundary — API route bodies, form submissions, and AI tool inputs — is validated with Zod schemas; parameterized queries via an ORM are used throughout, and no user input is interpolated into SQL.

All changes move through version control. Changes are normally checked locally with type checking, linting, the automated test suite, and a production build before they are pushed, and continuous integration runs the same checks on every push and pull request. Deployment is performed by the hosting provider from the main branch and is not gated on the continuous-integration result; the provider's own production build must succeed, and a failed build never goes live. As a single developer there is no peer code review. There is no manual file access to production servers, and production database schema changes are applied deliberately with row-level security re-asserted afterward.

Dependencies are monitored by GitHub Dependabot security alerts, which open automated security-update pull requests, with weekly version-update checks. Security advisories are triaged on receipt and patched according to severity — known-exploited and critical issues in reachable code take priority over transitive vulnerabilities in build-only tooling. Runtime platform patching (operating system, language runtime, TLS termination) is the responsibility of the managed hosting providers named above.

The application maintains an automated test suite covering its business logic, which runs in continuous integration on every change, alongside integration scripts that exercise data paths against a real database. Authentication, authorization, and webhook verification are not currently covered by automated tests; they are enforced in a small amount of code at the request proxy, at each API route, and in the webhook handlers.

For transparency: no independent third-party penetration test or formal security audit has been performed, and no security certification (SOC 2, ISO 27001) is held. This is a single-operator personal application, and those programs are not proportionate to its scope. The compensating controls are a minimal attack surface (one allowlisted identity, deny-all database policies, no unauthenticated write endpoints, no other users to attack or impersonate), minimal data collection, and reliance on managed platforms that do maintain such certifications.

There is one operator and no employees, contractors, or third-party personnel. Consequently the following controls are not applicable and are recorded here as such rather than left unanswered:

• Background screening — no personnel to screen
• Onboarding / offboarding access revocation — no accounts to grant or revoke
• Security awareness training — no staff; the operator builds and maintains the application himself
• Physical & facility security — no offices, data centers, or physical infrastructure; all compute is on managed cloud platforms
• Separation of duties — not achievable, and not meaningful, in a single-operator system

Every administrative account — hosting, database, source control, and the Plaid Dashboard itself — is protected by two-factor authentication.

Data is retained while the operator uses the application. A connected institution can be disconnected at any time from within the application, which removes the Item at Plaid and stops all further retrieval. Because the operator controls the database directly, any stored data can be permanently deleted on request to the contact below. There are no other data subjects, so no third-party deletion or access requests arise.

On a suspected compromise the operator will, in order: revoke active sessions and rotate the affected secrets (encryption key, Plaid, Supabase, and hosting credentials); revoke and re-link affected Plaid Items; assess the scope of exposure from platform and application logs; and remediate the underlying cause before restoring normal operation.

Plaid is notified without undue delay, and in any event within the timeframe required by the Plaid Master Services Agreement, of any incident affecting Plaid-provided data. Affected financial institutions are notified through Plaid. Because the operator is the only data subject, no other end-user notification is required. Security reports from third parties are received at the contact address below and acknowledged within five business days.

This policy and the controls it describes are reviewed at least every six months, and additionally whenever a material change is made to authentication, data storage, subprocessors, or the Plaid products requested. Review consists of confirming that each control stated here is still true of the deployed system, reassessing the principal risks (credential compromise of an administrative account, exposure of the encryption key, and subprocessor compromise), and updating this document with a revised date.

Security questions, vulnerability reports, and requests from financial institutions or Plaid can be sent to support@kyleneumeier.com. Related documents: the privacy policy, terms of service, and application overview.