Security & Data Architecture

1. Security Overview

VibeCheck is designed as a private, owner-scoped workspace for contract and related document workflows. The current implementation emphasizes private storage, server-side authorization, Row Level Security where applied to application data, and a server-side redaction and eligibility boundary before contract-derived text is sent to a configured AI provider for eligible features.

Security controls reduce risk. They do not make VibeCheck absolutely secure. Users remain responsible for account hygiene, minimizing unnecessary sensitive data in uploads, and reviewing outputs before relying on them.

How personal data is handled is described in the Privacy Policy. Commercial and account terms are described in the Terms of Service. This page focuses on architecture and controls.

2. Account and Authentication Security

• Magic Link sign-in: authentication uses email Magic Link flows completed through Supabase Auth (PKCE / code exchange), not a traditional password-based login.
• Google Sign-In: when selected, Google authenticates the user; VibeCheck receives permitted identity/authentication data and does not receive the Google password.
• Cloudflare Turnstile: login flows use Turnstile with server-side token verification to reduce automated abuse.
• Session cookies: authenticated sessions are maintained through HTTP-only auth cookies managed by the Supabase Auth integration; the application refreshes session cookies on protected routes.
• Client-supplied identity is not authoritative: protected operations resolve the authenticated user on the server. Client-provided user IDs are not treated as proof of ownership.

3. Data Access Controls

VibeCheck restricts access to user-owned resources through a combination of application-layer authorization and database policies.

• Owner-scoped workspaces: contracts, vault objects, and related user resources are designed to be accessible to the owning authenticated account.
• Row Level Security (RLS): application data tables are protected with Supabase RLS policies where those policies are implemented for the relevant tables.
• Server-side enforcement: privileged reads, writes, deletions, billing mutations, and AI analysis entry points run through server actions or server-only modules rather than trusting browser-only checks.
• Service-role credentials remain server-side and are not exposed to browser code.

4. Document and Storage Security

• Private storage: uploaded contract and related document objects are stored in private, owner-scoped storage paths rather than public buckets.
• Short-lived signed access: private document access uses short-lived signed URLs rather than permanent public object URLs.
• Soft delete for vault contracts: the current vault deletion path removes the storage object and sets deleted_at on the corresponding metadata record rather than presenting deletion as an immediate irreversible wipe of every backup or dependent system.
• Original document preservation on analysis: evaluation and derived artifacts are designed not to overwrite original uploaded document bytes.

5. Contract Processing and AI Boundaries

For contract analysis features that use AI, the current pipeline is designed as follows:

1. Upload to private, owner-scoped storage.
2. Server-side extraction of supported file formats.
3. Detection and redaction of supported identifiers where the workflow requires it.
4. Eligibility checks before AI processing.
5. Transmission of eligible server-side redacted or processed content to the configured AI provider for the requested AI feature.

Raw uploaded document bytes are not intentionally sent to the AI provider by the contract-analysis pipeline. AI credentials and provider secrets remain server-side and are not exposed to the browser. Provider selection follows current application routing for eligible features.

Important limitation: server-side redaction reduces exposure risk for supported identifiers. It is not a guarantee that all sensitive information is removed. Redaction can miss context-dependent or previously unknown sensitive information. Users must minimize unnecessary secrets before upload and must not treat automated redaction as a secrecy guarantee.

Generated documents use structured facts and snapshots according to the relevant document workflow. Generated contracts may bridge into the Contract Vault where that product path is enabled. AI output can contain errors and does not authorize contracts, certify legality, or invent legal citations.

6. Application and Network Controls

• Content Security Policy (CSP) and related HTTP security headers are applied application-wide, including X-Content-Type-Options, Referrer-Policy, X-Frame-Options (SAMEORIGIN), and Permissions-Policy restrictions.
• The X-Powered-By response header is disabled.
• Production configuration includes upgrade-insecure-requests in the CSP where that mode is enabled; deployments are expected to serve the application over HTTPS.
• Sensitive processing for contracts, billing mutations, and AI analysis is designed to run server-side.

7. Analytics and Public Data Boundaries

Public web analytics, when enabled, is limited to deliberately public/indexable paths. Authenticated workspace and tool routes are not part of the public analytics allowlist. Analytics event design aims to avoid authenticated account identity fields and to avoid contract bodies, findings, Money or ledger rows, billing credentials, and similar sensitive payloads.

Cookie Consent and optional analytics preference remain separate product controls. This Security page does not change consent behavior. Details of personal-data handling for analytics appear in the Privacy Policy.

8. Abuse Prevention and Operational Controls

• Rate limiting and abuse controls apply to sensitive flows such as billing checkout and free-plan entitlement paths.
• Hashed network/IP signals: for privacy-conscious free-plan abuse scoring, the application hashes network signals with a server key rather than storing raw IP addresses indefinitely for that control. Hashed network evidence contributes to scoring and is not used as a sole global identity that blocks every user on a shared public IP.
• Turnstile verification contributes to login and abuse resistance where configured.
• Paid entitlements are not locked by free-plan abuse controls in the current design.

9. Logging and Monitoring

VibeCheck maintains server-side audit logging for selected security and operational actions through an authenticated RPC path. Direct authenticated inserts into audit tables are revoked; identity for audit rows is bound to the authenticated session.

• Audit metadata is minimized with key-based sanitization so forbidden key fragments and nested free-text structures are dropped.
• Audit events may store an IP hash and coarse user-agent string rather than embedding contract text or secrets.
• Callers must not place contract bodies, passwords, tokens, or raw PII into audit metadata.

Public web analytics emission is separate from audit_logs and is not used as a substitute application database.

10. Deletion and Retention Limits

User-initiated deletion of vault documents uses a soft-delete pattern for contract metadata (deleted_at) after storage object removal. Deletion from the product UI does not mean immediate erasure from every backup, provider log, payment record, or legally retained system.

Retention for accounting, tax, payment, fraud, security investigation, and dispute purposes may extend beyond ordinary account use. Privacy rights and retention categories are described in the Privacy Policy.

11. Limitations and Responsible Use

• No absolute security guarantee: controls reduce risk but cannot eliminate unauthorized access, provider incidents, malware, misconfiguration, or human error.
• No certification claim on this page: VibeCheck does not present this page as third-party security certification or audit evidence.
• Redaction is risk reduction, not completeness: do not upload passwords, private keys, OTPs, payment-card data, or other secrets as ordinary document content.
• AI and generated output can be wrong: humans decide; code verifies deterministic checks; AI explains within bounded schemas.
• Provider infrastructure: hosting, authentication, storage, payments, email, and AI providers process data under their own terms and locations. VibeCheck does not promise that all data is stored only in India.

12. Reporting a Security Concern

If you believe you have found a security issue in VibeCheck, contact team@tryvibecheck.in with a clear description of the issue, affected surfaces, and steps to reproduce where safe to share. Do not include passwords, one-time codes, payment credentials, private keys, or unnecessary personal data in the report.

VibeCheck does not publish a fixed breach-notification SLA or dedicated security@ address on this page. Account, privacy, and security correspondence currently uses the established team@tryvibecheck.in contact channel. Response timing depends on severity, completeness of the report, and operational capacity.

13. Contact

Operator: Mehta Industries. Product: VibeCheck. Website: https://tryvibecheck.in. Contact: team@tryvibecheck.in.

For privacy requests, use the Privacy Policy contact process. For commercial terms, see the Terms of Service and Refund & Cancellation Policy.