SECURITY MODEL
The current scanner is designed so raw uploaded CSV contents are processed in the customer's browser rather than uploaded to the application backend.
Raw uploaded CSV contents are parsed and analysed in the browser by the current scanner.
The savings engine uses deterministic rules and calculations. Uploaded CSV contents are not sent to an LLM.
The product recommends review actions. It does not automatically remove, downgrade or reassign licences.
Supabase provides authentication and account/organisation functionality. Application metadata and scan summaries can be stored separately from raw CSV contents.
Stripe handles checkout and customer billing management. Payment-card handling is kept in Stripe-hosted flows rather than the scanner.
The current public application is served through Cloudflare Pages. Public deployment checks are used to avoid publishing server secret keys.
Browser-local processing reduces one class of data exposure, but it does not replace normal enterprise security review, endpoint security, browser security, identity controls or contractual requirements.
| Data / action | Current handling | Important boundary |
|---|---|---|
| Uploaded raw CSV | Processed in browser | Customer should still treat the local endpoint and browser as part of its security boundary. |
| Account identity | Supabase authentication | Normal identity/session controls apply. |
| Plan and billing state | Supabase + Stripe webhook lifecycle | Server-side secrets remain outside the public bundle. |
| Payment-card data | Stripe-hosted billing | Technology Spend Optimizer does not need to collect card details in the scanner UI. |
| Recommended licence actions | Customer review | No autonomous removal or downgrade is executed. |