Trust & Security
This page lists what GreenLine365 does to keep each business's data separate, tamper-evident and credential-safe. Every statement here is one our own repository demonstrates, and each says where the proof lives. We hold no third-party security certification and do not claim one.
1What we can prove
Four things, each verifiable by reading the code and running its tests.
Tenant isolation is enforced by the database engine
Row-level security is enabled on every table, and forced on the operational spine so it binds the table owner as well as ordinary roles. Every spine policy is keyed to the caller's tenant membership and fails closed when there is none — a request with no membership sees zero rows, not an error message to probe. Forcing does not stop a database role that bypasses row-level security; the roles that do are never given to a client, and the append-only logs are bound by a trigger rather than by forcing.
Evidence webapp/tests/spine-*-policy.check.mjs — each policy was observed refusing a cross-tenant read before it was observed allowing a same-tenant one.
The audit trail is append-only and hash-chained
Every event on an order links to the previous one by hash. Updates, deletes and truncates on the log are refused by a database trigger, so an altered history is detectable rather than merely discouraged.
Evidence webapp/supabase/migrations/20260827070000_spine_events.sql
Production credentials never leave the deployment environment
No key lives in the repository or its history. Live credentials exist only in GitHub secrets and the hosting provider's environment, the build refuses to start without the variables it needs, and rotation is a written procedure that verifies a secret is present and well-formed without ever printing it.
Evidence webapp/scripts/validate-env.js · docs/runbooks/key-rotation.md
Every guard has a recorded red
A security test counts only after it has been watched failing for the right reason. Guards are proven with the hole open, then closed, then re-proven under mutation, and the refusing rule is named in the output.
Evidence docs/governance/GL365-TEST-EVIDENCE-RULES-2026-08-27.md
2How isolation works
Every row of business data carries the identifier of the tenant it belongs to. The database checks that identifier against the caller's tenant membership on every read and write, in the database itself, not in the application. A request from someone with no membership in that tenant returns nothing.
This means the rule holds regardless of what the website, an API route or a script does. Privileged database access is never used for an ordinary customer-facing request, and a potential cross-tenant leak is treated as a critical failure that stops other work until it is closed.
Sessions are authenticated tokens verified for signature before any database call, and inbound webhooks from third parties are verified against the sender's signature before their contents are read.
3What we do not claim
We do not hold, and do not claim, any third-party security or compliance certification. We do not describe our storage with an encryption standard we have not verified ourselves, and we do not describe the platform as suitable for regulated health data. If a claim like that ever appears on this site, it is an error; please report it using the contact below.
Our hosting and database providers publish their own security documentation. Those statements are theirs, made about their infrastructure, and we do not repeat them here as if they were ours.
4AI and your data
Where GreenLine365 uses a language model, the request goes to a third-party model provider through a gateway listed under sub-processors. Content a business enters is stored under that business's tenant identifier and read back under the same row-level security as everything else; the model does not have a route to another tenant's rows.
Voice and chat agents that act on a business's behalf are provisioned per business and identify themselves as automated.
5Sub-processors
The providers that run or touch GreenLine365 data, listed by what they do for us.
| Provider | Role |
|---|---|
🌐Vercel | Application hosting and edge network |
🗄️Supabase (on AWS) | Database, authentication and file storage |
🛡️Cloudflare | DNS and traffic proxy in front of the application |
🤖OpenRouter | Gateway to third-party language models |
📦GitHub | Source control, CI and deployment secrets |
6Contact & reporting
To report a vulnerability, ask a security question, or flag a statement on this site that goes beyond what we can prove, contact us directly.
Related Documents: