Security Philosophy
AutoTender handles sensitive commercial data: company financials, team credentials, government certifications, and pricing strategies. Our security architecture is designed with the assumption that this data is high-value and that our users operate in regulated industries where data breaches carry significant legal and reputational consequences. Every architectural decision prioritises data isolation, encryption, and minimal attack surface.
Infrastructure
AutoTender.ai runs on established cloud providers for hosting, the database, authentication and file storage. Each holds a SOC 2 Type II report from annual third-party audits; those reports are theirs, not ours (see Certifications below). All data is encrypted in transit with TLS and at rest with AES-256. Database backups are encrypted, with point-in-time recovery. Our network provider gives DNS and DDoS protection. The providers are listed, with what each processes, in section 7 of our
Privacy Policy.
Authentication
User authentication is handled by a managed authentication service with the PKCE (Proof Key for Code Exchange) code exchange flow, which protects against authorisation code interception attacks. Sessions use SameSite=Lax cookies with automatic JWT refresh, and the site is served only over HTTPS (HSTS). These cookies are not httpOnly: the browser library that keeps your session signed in has to read them from the page, so we rely on the Content-Security-Policy and on not rendering untrusted markup to protect them. Login and signup forms are protected by an invisible bot check to prevent automated attacks. Password sign-in is rate-limited per IP address, and sign-up and password reset have their own limits. Password changes trigger an immediate security notification email to the account holder. Google and Microsoft sign-in are supported as alternatives to email and password. Password strength is enforced during registration and password changes with a real-time visual indicator requiring a minimum strength score.
Data Isolation
All user-facing tables are protected by Row Level Security (RLS) policies that scope access to the authenticated user via the auth.uid() = user_id check, so one user's data is not visible to another (except where you explicitly share it). Internal and operational tables, used only by server-side processes, are not client-accessible: they have RLS enabled with no anon or authenticated policy (deny-by-default) and are reachable only by the server-side service role. Service-role access (used by AI agent API routes) bypasses RLS but is restricted to server-side API routes that are: authenticated with a secret key that only our servers and our workflow engine hold (compared in constant time); rate-limited independently; and scoped to specific operations (e.g., a bid generation route can only write to the bids table for the requesting user's ID).
Portal Logins
AutoTender does not ask for, store or use your procurement portal logins. You sign in to each portal yourself, in your own browser, and the Chrome extension works only within the portal page you have open. You press each portal's final submit control yourself.
API Security
All API routes are protected by tiered rate limiting with sliding windows, set per route type (sign-in, general API, webhooks). Auth-critical routes fail closed: if the rate limiter is unavailable, requests are rejected rather than allowed. Payment and email webhook endpoints use HMAC-SHA256 signature verification with constant-time comparison to prevent timing attacks, and enforce a 5-minute replay window to prevent replay attacks. Agent API routes (used by the AI pipeline) and the other calls from our workflow engine authenticate with a Bearer token that is a secret shared only between our servers and the workflow engine, compared in constant time; in production the database service-role key is not accepted as that token. All API responses include appropriate CORS headers restricting access to authorised origins.
Payment Security
All payment processing is handled by Stripe. We never see, store, or process your full credit card number. Stripe is PCI DSS Level 1 certified (the highest level of payment industry security certification). Webhook events from Stripe are verified via HMAC-SHA256 signature before processing. Subscription state changes (upgrades, downgrades, cancellations, payment failures) are processed exclusively through Stripe webhooks to prevent state manipulation. The Stripe customer portal is used for all payment method management, ensuring card data never passes through our servers.
AI Processing Security
Bid proposals are generated through the paid APIs of commercial AI model providers (see sections 5 and 7 of our Privacy Policy). Your data is sent over TLS-encrypted connections directly from our server-side API routes (never from the client browser). The providers' API terms state that API data is not used to train their models. Generated proposals are stored in our database, protected by RLS. AI model API keys are stored as server-side environment variables and are never exposed to the client. The AI pipeline runs entirely server-side; no AI processing occurs in the user's browser.
Pricing Firewall
Before any bid is submitted, the Pricing Firewall runs independent numerical checks in deterministic code (no AI involvement), covering margins, rates, arithmetic, currency, tax and contract totals. A check that finds an error that makes the price unsafe (for example no priced lines, a total more than 5% away from the sum of its lines, a negative margin or a price far outside the published tender value) aborts the bid, which stops until the pricing is fixed. A check that finds something worth a second look (for example a margin below your floor, a price outside the tender's value range, or a bid currency different from the currency in your pricing profile) raises a warning and shows it on the bid. Separately, when a tender's currency differs from the currency of your day rates, AutoTender does not price the bid from them, because it does not convert currencies. For some warnings a language model may propose a corrected price. It never chooses the margin and it cannot add or remove priced lines: AutoTender prices the scenarios in code, and a price it could not bring into range waits for you to tick "I approve this price". The Pricing Firewall exists specifically because financial errors in government bids can create legally binding obligations at incorrect prices.
Chrome Extension Security
The Chrome Extension follows a strict security model: authentication tokens are stored in chrome.storage.session (cleared when the browser closes), ensuring credentials do not persist if the browser is left open on a shared device. Refresh tokens are stored in chrome.storage.local on your device. Chrome does not encrypt this storage, and the extension limits it to its own pages and background worker so that scripts on a portal page cannot read it. Signing out removes the refresh token and any cached bid details. The extension communicates only with AutoTender's API endpoints and makes no requests to third-party services. Fonts are bundled locally (no Google Fonts CDN calls). Content scripts only activate on recognised government procurement portal domains. The extension never clicks submit buttons on portals; it fills form fields for user review. When a release of the service needs a newer extension, the extension shows a notice asking you to update it.
Service Worker and Caching
The service worker implements app shell caching (precaches the root and offline pages) and static asset caching (images, fonts, icons and the site's code files). As a deliberate security decision, the dashboard and every other signed-in page, and the data the app loads, are NOT cached by the service worker: they always come from the network. This prevents authenticated page content from persisting in the browser cache on shared or public devices. The offline page provides a branded experience when connectivity is lost without exposing any authenticated data.
Audit Trail
Every significant action in the bid lifecycle is recorded in an audit trail that users cannot change or delete: bid generation start and completion; individual agent pipeline results (pass/fail/score per agent); quality score changes; user edits to proposals; reviewer approvals and rejections; and pricing firewall check results. The audit trail is accessible to the account owner via the bid detail page and is included in GDPR data exports. Records of AI agent runs are deleted about 12 months after the run, as our Privacy Policy (section 9) says.
Incident Response
Our incident response procedure includes: immediate investigation of any suspected security incident; notification of the relevant data protection supervisory authority within 72 hours of confirmed breaches involving personal data (as required by GDPR); notification of affected users without undue delay when the breach is likely to result in high risk; root cause analysis and remediation; and post-incident review and policy updates.
Data Processing Agreement
Enterprise and regulated buyers can request our Data Processing Agreement (DPA) for review during procurement evaluation. The DPA covers data processing scope, sub-processor disclosures, GDPR obligations, breach notification procedures, audit rights, and data retention terms.
Download our DPA template or contact
legal@autotender.ai for a signed copy.
Compliance
Customers can download our Data Processing Agreement, with every sub-processor named, from Settings. If your procurement includes a security questionnaire, send it to
legal@autotender.ai and we will complete it.
Certifications
We state our position precisely, because a vendor that overstates it is found out at diligence.
AutoTender does not currently hold SOC 2, ISO 27001 or FedRAMP authorisation. Our hosting providers hold their own certifications, and those are theirs rather than ours. Running on certified infrastructure is not the same as being certified, and we do not present it as such.
A SOC 2 Type II report requires an observation window measured in months, so it is gated by the calendar rather than by engineering. The security measures we use are described on this page; no independent auditor has examined them yet.
FedRAMP authorisation and platform-level CMMC are deliberately not in progress. Both are multi-year programmes that make sense only for a vendor whose core market is US federal, and we would rather say so plainly than imply a roadmap we are not funding. We compete on jurisdictional breadth instead.
Subprocessors
The kinds of third party that process customer data on our behalf, where they operate and the transfer mechanism for each, are published in section 7 of our Privacy Policy. Customers can download the named list, with what each sub-processor receives, from Settings in the application, and a buyer evaluating AutoTender can ask us for it.
We give notice before adding a subprocessor that processes customer content. If you need that notice contractually, ask for it in the DPA.
Data Residency
Bid content, company profiles and uploaded documents are stored with our database provider and served through our hosting provider's edge network; AI processing runs with the model providers. The location of each category is in section 7 of our Privacy Policy.
If your procurement requires data to remain within a specific jurisdiction, tell us before you buy rather than after. We would rather decline a contract we cannot meet than agree to a residency guarantee we cannot evidence.
Vulnerability Reporting
If you discover a security vulnerability in AutoTender, please report it to
security@autotender.ai. We aim to acknowledge your report within three business days and to keep you informed while we fix it. We ask that you: provide sufficient detail to reproduce the vulnerability; give us reasonable time to address the issue before public disclosure; and do not access, modify, or delete other users' data during your research. We do not currently offer a formal bug bounty programme but we are grateful for responsible disclosure and will credit researchers (with permission) in our security advisories.