How BillGuarded protects billing records
Last updated: September 27, 2026.
Private storage
Customer files are stored in a non-public Supabase Storage bucket. Uploads use short-lived signed upload access rather than public object permissions. The Free Proof Scan accepts common business-record formats, while paid automated audit conclusions remain restricted to evidence the deterministic engine can safely reconcile.
Workspace isolation
New workspaces receive a high-entropy access token. The token itself is not stored in the database; BillGuarded stores a one-way hash and requires the matching credential before allowing private intake or recovery activity for that workspace.
Server-only data access
Customer audit, finding, Stripe-event, and billing tables have row level security enabled and do not grant direct table privileges to anonymous or authenticated browser roles. Sensitive database actions are performed by server-side code.
Evidence boundary
BillGuarded does not turn an unsupported parse into a billing claim. Structured evidence can enter the deterministic engine directly. PDF, XLS, XLSX, TXT, TSV, or otherwise non-deterministic records can be held for assisted normalization before a conclusion is produced. That fallback widens intake without weakening the evidence standard.
Payment integrity
Stripe handles card payment collection for paid scopes. BillGuarded provisions paid audit state from signed Stripe webhook events in production, and webhook event IDs are recorded so processing is idempotent. The Free Proof Scan requires no payment or card.
Private result recovery
Paid audits and Free Proof Scans use separate signed access mechanisms. Paid recovery re-verifies the exact completed Stripe Checkout and associated customer records. Proof Scan recovery verifies the exact workspace credential before issuing a private result cookie.
Recovery credentials are placed after the URL fragment marker so they are not transmitted in the initial HTTP request. Recovery pages remove the fragment from the visible address and send the credential to a same-origin server endpoint in a POST body. Recovery links remain bearer credentials: keep them private and do not forward or publish them.
Abuse and browser controls
Intake creation is rate-limited, file metadata is validated before signed upload access is created, production redirect origins are pinned to the BillGuarded domain, recovery responses are private and non-cacheable, private recovery and result surfaces are excluded from search indexes, and the application sends restrictive browser security headers.
Report a security issue
Send suspected vulnerabilities to support@billguarded.com. Please do not include customer documents, recovery links, or secrets in an initial report.