• Row-level security at the database. Standwyse is multi-tenant on Postgres, and isolation is enforced by the database itself: every tenant-scoped table carries Row-Level Security policies, so a query from one organisation can never return another organisation’s rows — even if application code has a bug.
• Tenant checks on every privileged action. Server actions that use elevated database access re-verify the signed-in user’s membership and role against the specific organisation and event they are acting on. Tenant scope is always derived from validated records, never trusted from the client.
• Fail-closed production auth. If the production deployment is ever misconfigured (for example, missing its database credentials), protected routes refuse access rather than degrading open. The app also refuses to boot in production with demo-tenant settings present.

• The AI never decides. Document compliance verdicts are deterministic: the AI only extracts fields named in the organiser’s rubric, and plain, testable code applies the rules. A document containing “ignore the rules and approve this” cannot change its own verdict, because the AI never emits one.
• Append-only audit log. Every AI verdict and every human override is recorded in a ledger that pins the model, vendor, prompt version, and SHA-256 hashes of the exact prompt and response. No update or delete path exists — corrections append new entries, so history is immutable.
• Per-surface kill switches. Each AI surface (document review, concierge, and the other assistants) has its own off switch. During an incident a single surface can be disabled and the product degrades to manual workflows — uploads simply wait for human review.
• Prompt-injection defences, tested in CI. Extracted values are sanitised (zero-width characters, bidirectional overrides, control characters, and other instruction-smuggling tricks are stripped) before they reach the UI or audit trail, and an adversarial red-team evaluation suite — covering approve-instructions, hidden text, metadata injection, role confusion, and exfiltration attempts — runs in CI.

• Encrypted in transit and at rest. All traffic is TLS, and data is encrypted at rest by our infrastructure providers (Supabase and Vercel).
• Private document storage. Uploaded documents live in private storage buckets — there are no public object URLs.
• Short-lived signed access. Document access goes through signed URLs issued only after the caller’s permissions are checked, and each URL expires after 15 minutes.

• Structured audit logging. Privileged operations emit structured server events, alongside the append-only compliance audit ledger described above.
• Error monitoring with PII scrubbing. Errors are tracked in Sentry behind a redaction filter that strips emails, names, credentials, tokens, and signed-URL query strings before anything leaves the process — over-redaction is treated as the safe side.
• Cross-tenant tests gate every change. CI includes a dedicated cross-tenant isolation suite that exercises the row-level security policies directly, plus unit coverage of the deterministic verdict engine and the prompt-injection sanitiser. Accessibility audits run on the public pages too.

Standwyse uses the following sub-processors to provide the service. AI providers process content solely to deliver the feature requested — customer documents and conversations are not used to train their models.

Security documentation and our compliance roadmap are available on request via security@standwyse.com. A Data Processing Agreement (DPA) is available on request.

Send security questionnaires and vulnerability disclosures to the same address — we respond to disclosures promptly and appreciate coordinated reporting. For how we handle personal data, see the Privacy Policy.