Access Controls Policy
Effective date: August 7, 2026 · Owner: Pedro Acosta, Founder · Review cycle: Annual
This policy defines how FinSight controls access to production infrastructure, sensitive data, and consumer financial information obtained via Plaid. It applies to all systems, services, and personnel involved in operating the FinSight platform.
Two things this policy is not: FinSight never receives or stores your bank username, password, or MFA codes — those are entered directly into Plaid's interface, never FinSight's. And the financial data FinSight does store (account balances, transactions, the budgets and goals you create) exists for one purpose only — to run the product features described in these docs and our Terms of Service. It is never sold, and it is never used to train third-party AI models — see our Privacy Policy for the full detail.
1. Scope
This policy covers:
- Production database (Neon PostgreSQL)
- Application hosting and deployment (Vercel)
- Authentication infrastructure (Clerk)
- Plaid API credentials and consumer bank-linked data
- Payment processing (Stripe)
- Source code repository (GitHub)
- All environment secrets and API keys
2. Defined and Documented Access Control Policy
FinSight maintains a written Information Security Policy (available internally) that specifies who may access which systems, under what conditions, and how access is granted and revoked. This Access Controls Policy supplements that document with specific implementation details.
Access decisions follow the principle of least privilege: every system, user, and service is granted only the minimum permissions required to perform its function.
3. Role-Based Access Control (RBAC)
FinSight enforces two distinct access tiers:
- User (default): Authenticated via Clerk JWT. Can access only their own data. All dashboard routes, API endpoints, and database queries are scoped to the authenticated user's ID — it is architecturally impossible to read another user's data.
- Admin / Super Admin: Elevated role stored in Clerk
publicMetadata. Every admin route handler performs a server-side role check on every request — there is no client-side role bypass path. The admin panel exposes account-health and support tooling (connection status, cancellation feedback, waitlist management) — it does not expose raw Plaid access tokens or bank credentials, because FinSight never has bank credentials to expose in the first place.
Admin access is limited to the operational and support needs of running FinSight — currently held only by the founder — and is never used to browse a user's financial data outside of responding to a specific support request or investigating a specific incident.
Unauthenticated requests to protected API routes return HTTP 401. Authenticated non-admin requests to admin routes return HTTP 403 or redirect to /dashboard.
4. Centralized Identity and Access Management
All user authentication flows through Clerk (SOC 2 Type II certified). Clerk issues short-lived JWT tokens validated on every request by FinSight's Next.js middleware. No passwords or session tokens are stored by FinSight directly.
Clerk provides:
- OAuth 2.0 (Google, GitHub) and magic-link sign-in
- Multi-factor authentication (passkeys / TOTP) enforced at the platform level
- Automatic session expiry and token rotation
- Brute-force and bot-detection protection
5. Multi-Factor Authentication
Multi-factor authentication is required for all access to critical systems that store or process consumer financial data:
- Consumer accounts: MFA enforced via Clerk (passkeys / TOTP required, not optional)
- Admin infrastructure: Vercel, GitHub, Neon, Stripe, and Clerk dashboards all require MFA on the founder's account
6. Audit Logging
Every admin action — viewing a user's account detail, exporting data, acting on a waitlist entry — is written to an append-only audit log with the admin's ID, the target user (if any), the action taken, and the request's IP address. The log itself is not exposed through the admin panel to reduce the value of the panel as an attack target; reviewing it requires direct, MFA-gated database access.
7. Secrets Management
All API keys, database credentials, and encryption keys are stored exclusively as Vercel environment variables — never in source code, configuration files committed to version control, or client-side bundles. The GitHub repository is private. Secrets are rotated when a vendor reports a compromise or when access changes.
Plaid access tokens obtained during bank linking are encrypted with AES-256-GCM before storage in the database. The encryption key is an environment secret and is never co-located with the ciphertext. There is nothing to protect beyond that token, either — FinSight itself never receives or stores your bank username, password, or one-time MFA codes in the first place.
8. API and Database Access Controls
- Rate limiting: All API endpoints are rate-limited via Upstash Redis (SOC 2 Type II). Limits are enforced per user ID.
- Input validation: All API inputs are validated with Zod before processing. No unvalidated user input reaches the database.
- ORM-only database access: All database queries use Prisma ORM with parameterized queries. No raw SQL with user-supplied values.
- Plaid read-only scope: FinSight requests only read-only Plaid product scopes (Transactions, Auth, Identity). No write or transfer capabilities are requested.
9. Third-Party Service Access
Production systems are operated entirely on SOC 2 Type II (or equivalent) certified infrastructure. No third-party personnel have direct access to FinSight's database or application secrets. Vendor access is scoped to the APIs and dashboards provided by each vendor's platform, and each vendor receives only the data it needs to do its job.
| Vendor | Certification | Access Scope |
|---|---|---|
| Vercel | SOC 2 Type II | Application hosting, deployment, logs |
| Neon | SOC 2 Type II | PostgreSQL database hosting |
| Clerk | SOC 2 Type II | Authentication and session management |
| Upstash | SOC 2 Type II | Redis rate limiting (no PII stored) |
| Stripe | PCI DSS Level 1 | Payment processing — card data never touches FinSight's servers |
| Plaid | SOC 2 Type II | Bank connectivity (read-only) |
| Resend | SOC 2 Type II | Transactional email delivery (receipts, alerts, digests) |
| PostHog | SOC 2 Type II | Product analytics — only for users who opt in to cookies |
| Sentry | — | Error monitoring, scrubbed of raw transaction data and access tokens — currently disabled pending contract renewal; errors fall back to structured server logs |
| Anthropic | SOC 2 Type II | AI chat, briefings, and reviews — API traffic, not used for model training |
10. Access Review and Removal
Because FinSight is currently operated by a single founder, access review today means: every vendor dashboard and the production database are reviewed for unused API keys, stale sessions, and unnecessary permissions at each policy review (Section 11) and immediately after any credential rotation. As the team grows, any additional person granted admin or infrastructure access will be added under the same least-privilege principle in Section 2, with access revoked the same day their role changes or their need for it ends.
11. Policy Review
This policy is reviewed annually by the Founder or upon any significant change to the platform's infrastructure or access model. Questions or concerns may be directed to info@finsight.it.com.