Security
A summary of the controls this platform actually implements, each one something you could verify by reading the code rather than a claim you have to take on faith.
Row-level security, enabled and forced
Every table holding tenant data has row-level security both enabled and forced, written explicitly in every migration — not the automatic RLS Supabase applies to its own default schema, which does not reach ours.
Credential material is unreachable, not just protected
Signing keys, usage ledgers and the audit log live in a schema no API role is ever granted access to. A policy bug there cannot leak anything, because nothing can address the schema to exploit one.
Nothing lives in the default schema
No AutoSugges table is ever created where the automatic public API can see it. The runtime Data API exposes zero application tables by construction.
Publishable vs. secret credentials
A publishable key is not a secret — it ships in your client bundle and is assumed observable. It carries scope (owner, list, version, origin allow-list, billing identity), never write access. A secret key, where one exists, never leaves the server side.
Origin allow-lists
Every publishable key carries an origin allow-list, checked by exact match against the browser's own Origin header. This is a filter, not the authorization boundary — quota and rate limits still apply to every request regardless of origin.
Turnstile at session establishment only
Cloudflare Turnstile challenges run at sign-up, key provisioning and other session-establishing actions — never per keystroke on the autocomplete path itself, and a failed challenge is rejected and never billed.
Metering runs before the cache, every time
Requests resolve, authorize and meter/quota-check before the cache is ever consulted. This ordering is enforced by the type system, not left to convention, so a request cannot reach cache or storage without first clearing quota.
Published artifacts are immutable
A publish produces a new, hash-addressed artifact. A client never sees data mixed from two versions, and activation only happens once the new version has verified.
Key revocation reaches the edge directly
Revoking or disabling a publishable key rewrites its edge record synchronously as part of the action you took — not on a delayed sweep — so a revoked key stops resolving on its very next request.
What this page does not claim
No compliance certification, no completed penetration test, and no uptime guarantee is claimed here, because none of those exists yet for this product. Per-IP rate limiting and a durable audit trail are open items rather than shipped controls — this page describes what is built, not a roadmap dressed up as a feature.
Report a vulnerability
Found a way tenant isolation, a credential or quota enforcement could be broken? Email support@autosugges.com with what you found and how to reproduce it. Reports are read and acted on directly — there is no bug-bounty program or dedicated security team, only the person who builds this.