Security
How SOPSai protects workspace data, SOPs, company knowledge, and AI-assisted workflows.
SOPSai helps teams create, manage, and search SOPs and company knowledge. Security is built around authenticated access, workspace isolation, role-based permissions, careful file handling, input validation, and abuse prevention.
No online service can guarantee absolute security. This page is not a certification, audit report, compliance guarantee, or promise that every risk has been eliminated.
SOPSai uses Supabase Auth for account authentication and session management. Private application areas require authenticated accounts.
Users are responsible for keeping login credentials secure. Workspace owners and admins are responsible for inviting only authorized users and removing access when it is no longer appropriate.
SOPSai organizes customer content by workspace. SOPs, departments, playbooks, assignments, acknowledgements, company profiles, company documents, and attachments are scoped to the active workspace.
Server-side checks validate that records belong to the current workspace before sensitive actions are allowed, including edits, assignments, uploads, archive actions, and membership changes.
SOPSai uses three primary workspace roles: Owner, Admin, and Employee.
Owners have full workspace and account control. Admins manage SOPs, playbooks, departments, assignments, and day-to-day workspace operations. Employees read assigned or permitted SOPs and playbooks and complete acknowledgements.
Sensitive actions are protected server-side and are not only hidden in the user interface.
SOPSai uses Supabase PostgreSQL. Row-Level Security policies are used to help restrict workspace data to authorized members.
RLS policies and workspace-scoped application queries are both part of the security model. RLS does not replace secure application logic; SOPSai uses both together.
SOPSai uses private storage for SOP attachments and company knowledge documents where applicable. Upload paths are workspace-scoped.
File names are normalized, supported file types are limited, file sizes are capped, and unsupported or risky file types may be rejected.
Access to stored files should be checked before download or signed URL creation so files from one workspace are not exposed to another workspace.
SOPSai validates and normalizes user input on sensitive actions. Examples include SOP titles, company fields, department names, category names, invite emails, file names, file types, file sizes, due dates, IDs, route parameters, and tags.
SOPSai uses lightweight server-action rate limits for expensive or sensitive actions such as AI question generation, AI SOP drafting, uploads, invites, and similar operations. Additional platform-level abuse controls may be added over time.
Vercel and other hosting providers may provide platform-level DDoS protections, but app-level abuse controls are still part of SOPSai's security approach.
AI features may send prompts, SOP content, clarifying answers, uploaded supporting context, and company knowledge excerpts to AI service providers to generate SOP drafts.
Uploaded documents and company knowledge are treated as reference material, not trusted instructions. SOPSai includes prompt-safety instructions intended to reduce risks from malicious, conflicting, or irrelevant uploaded content.
AI output should be reviewed by users before use. SOPSai does not guarantee that AI output is accurate, complete, compliant, or suitable for a particular business process.
API keys and secrets are intended to be stored in server-side environment variables. Public browser code should only use public environment variables.
Secrets should not be exposed in client bundles, public repositories, screenshots, logs, or customer-facing error messages.
SOPSai uses or is adding browser security headers such as Content Security Policy, Referrer Policy, X-Content-Type-Options, Permissions Policy, X-Frame-Options, and HSTS where appropriate.
These controls help reduce common browser-based risks, but they are only one part of the broader security model.
SOPSai uses logs and diagnostics to operate, troubleshoot, secure, and improve the service.
User-facing errors should avoid exposing raw database errors, stack traces, file paths, private storage paths, API keys, or secrets. Some internal diagnostic logs may contain operational details needed for security and support.
SOPSai will investigate suspected security incidents and may take containment, remediation, and notification steps as required by law, contract, or platform policy.
Incident response processes will mature as the product grows and as customer requirements become more formal.
If you believe you found a vulnerability, contact security@sopsai.io or support@sopsai.io with reproduction steps and relevant details.
Please avoid accessing, modifying, deleting, or sharing data that does not belong to you while testing or reporting an issue.