Security architecture you can verify.
We document what we've actually built — not what sounds impressive. Every security control on this page reflects production-implemented behavior you can verify.
What we've built
These are the actual security controls implemented in the current production system.
Workspace Data Isolation
Every workspace is a strictly isolated tenant. PostgreSQL Row Level Security (RLS) policies are enforced at the database layer on every table — tenders, requirements, company evidence, proposals, compliance records, submissions, and analytics.
- RLS enforced at PostgreSQL level — not just application code
- Workspace members can only read/write their own workspace data
- Cross-tenant data access is not possible via the application API
Private Document Storage
Tender documents, company evidence files, and supporting attachments are stored in private, RLS-protected storage buckets. Files are not publicly accessible — every download requires authenticated, workspace-scoped authorization.
- Supabase Storage with private bucket configuration
- Storage paths scoped per workspace — cryptographically isolated
- No public file URLs are generated for sensitive documents
Role-Based Access Control
Workspace membership is managed through an explicit role system. Access is enforced at both the application and database layers.
- Roles: Owner, Admin, Member, Reviewer
- Invitation-based team access — no open registration to existing workspaces
- Platform admin authority is database-enforced, not application-layer only
Authentication
Authentication is handled by Supabase Auth, which manages session tokens, password hashing, and email verification flows securely.
- Email + password authentication with secure session tokens (JWTs)
- Password reset via verified email flow
- Protected routes enforce server-side authentication checks
Server-Side AI Processing
All AI analysis runs exclusively on the server. API keys, document content, and company evidence never reach the browser or client-side code.
- AI provider API keys are server-only environment variables
- Document content is processed server-side and never returned raw to the browser
- Structured output schemas validated at runtime — no free-form AI text as business decisions
Evidence Traceability
Every qualification verdict is backed by specific requirement clauses and company evidence records. We don't deliver unexplained scores — we show exactly why.
- Each requirement match links to the specific tender clause and evidence record
- Evidence gaps are explicitly identified — not silently assumed as met
- Qualification reports are auditable and persistent per workspace
How we use AI responsibly
AI accelerates analysis. Humans make the final decision.
AI assists — it doesn't decide
GetBidRadar uses AI to extract and structure tender requirements. A separate, deterministic scoring engine computes the final qualification score from your verified company evidence. AI does not independently determine whether you should bid.
Your facts come from your evidence
Qualification scores are computed against company evidence you provide in your knowledge base. The system will not fabricate certifications, track records, or financial capacity you haven't documented.
Missing information is flagged, not assumed
If a required qualification cannot be matched to your company's evidence, it is explicitly marked as a gap or unknown. We do not guess or assume qualifications are met.
Recommendations should be reviewed
BID / REVIEW / NO-BID recommendations are starting points for human judgment, not final binding instructions. Your bid team should review the full evidence context before committing to pursue a contract.
Your data is not used for model training
Your company evidence, tender documents, and workspace data are not used to train public AI models. They remain isolated to your workspace.
AI provider transparency
GetBidRadar routes AI requests through a server-side gateway using commercial AI providers. We do not claim AI output is infallible. Extraction errors can occur on ambiguous or poorly formatted documents.
What we've built on
Supabase
PostgreSQL database with Row Level Security, Auth, and private Storage. Hosted infrastructure managed by Supabase.
Server-Side Rendering
Application rendered server-side. Sensitive business logic executes on the server, not in the browser.
Data Residency
Data is stored in the region configured in your Supabase project. Specific residency guarantees depend on your project configuration.
Data practices
What data do you collect?
We collect the information you provide during registration (name, email, company), the tender documents and URLs you submit for analysis, and the company evidence you add to your knowledge base. We also collect usage metrics to enforce plan limits and improve the service.
Who can see my company's tender documents?
Only authenticated members of your workspace can access your workspace's documents. Database RLS policies prevent access by other workspaces. GetBidRadar platform operators can access data for support purposes when explicitly required — this is documented in our Terms of Service.
Can I delete my data?
You can delete individual tender analyses, requirements, and knowledge base entries from within the application. For full account and workspace deletion, contact us. We will fulfill deletion requests in accordance with our Privacy Policy.
How long is my data retained?
Active workspace data is retained as long as your workspace exists. Trial workspaces that have not been accessed for an extended period may be subject to cleanup as described in our Terms of Service. We do not sell your data.
Security or compliance inquiry?
If you have questions about our security architecture, data handling, or require a security review before procurement, contact us directly.
Also see our Privacy Policy and Terms of Service for full data processing commitments.