Security Policy
Tendergate
Platform: tendergate.ai
Software v1.3. Approved: 7 October 2026. Next review: no later than 7 October 2027.
Introduction
This Security Policy outlines the measures and protocols in place to ensure the security and integrity of the Tendergate. The platform provides AI-powered analysis of procurement documents (RFPs) against vendor proposals, automatically detecting compliance gaps, mismatches, and risks. This policy is designed to protect the platform, its data, and its users from unauthorized access, disclosure, alteration, and destruction.
Scope
This policy applies to all clients, employees, contractors, and third-party service providers who have access to the Tendergate or its data. It covers the web application, background processing systems, AI analysis agents, document storage, and all integrations with third-party services.
Platform High-Level Architecture
Tendergate is a Ruby on Rails 8 cloud application with a reactive user interface powered by Hotwire (Turbo and Stimulus). Customer data is stored in secure PostgreSQL database instances on Amazon Web Services (AWS). All data in the platform is fully encrypted, both in transit and at rest.
Our web infrastructure is hosted on Heroku, a world-class PaaS service, with resources hosted within the EU region. This setup provides strong security, regulatory alignment with GDPR, and the capacity to grow with our customers. More about Heroku’s security: https://www.heroku.com/policy/security
The platform employs a two-tier AI agent architecture for document analysis:
- Main Orchestrator Agent — handles reasoning, orchestration, and tool selection
- Specialized Sub-Agents — perform focused tasks such as document reading, evidence gathering, and entity matching
- Library Content Search — documents added to the Library are indexed for search. To create this index, Library passages and search queries are sent to OpenAI to generate embeddings (numerical representations of text), using the platform’s credentials even when an organization uses its own AI provider API key. The resulting index is stored in the platform database, scoped to the organization
We focus on secure web application development, actively working to prevent issues such as back-door access, cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injection, clickjacking, and unauthorized cross-origin scripts.
SSL/HTTPS is enforced for all communications. The physical infrastructure is hosted and managed within Amazon’s secure data centers utilizing AWS technology. Amazon continually manages risk and undergoes recurring assessments to ensure compliance with industry standards. Amazon’s data center operations have been accredited under:
- ISO 27001
- SOC 1 and SOC 2/SSAE 16/ISAE 3402
- PCI Level 1
- FISMA Moderate
- Sarbanes-Oxley (SOX)
Additionally, we are committed to compliance with the GDPR. More about GDPR and Heroku compliance: https://devcenter.heroku.com/articles/gdpr
Data Security & Privacy
Data Encryption: All data transmitted to and from the platform is encrypted using TLS. Data at rest in PostgreSQL and S3 storage is encrypted using AES-256 encryption provided by AWS.
Data Backup: Regular automated backups of the PostgreSQL database are performed via Heroku’s continuous protection. Backup integrity is verified periodically to ensure data can be effectively restored.
Data Handling: All data collected, stored, processed, and shared by the Tendergate complies with relevant data protection laws and regulations, including GDPR, to ensure the privacy and protection of user data.
Data Classification: The platform primarily handles commercial and technical procurement data (RFP specifications, pricing, certifications, technical proposals). Documents may also contain personal data such as contact persons, signatories, and team member CVs. All uploaded content is treated as confidential by default.
Data Usage: Data is only used for purposes explicitly consented to by the users or as required for the provision of the platform’s services. Uploaded documents are processed solely for the purpose of procurement analysis.
Data Disclosure: User data is not disclosed to third parties without user consent, except where required by law.
Data Retention: Customer data, including uploaded documents, analysis results, and conversation logs, is retained for the duration of the active account. Upon account termination or explicit customer request, all associated data is deleted from the platform, including backups within the standard backup rotation cycle.
Right to Deletion: Customers may request deletion of specific documents, analysis runs, or their entire account data at any time, in accordance with GDPR Article 17 (Right to Erasure).
AI & LLM Security
Tendergate uses artificial intelligence to analyze procurement documents. This section describes the security measures specific to our AI processing pipeline.
Data Flow to AI Providers
For analysis and related document workflows, we send document content to Anthropic, OpenAI and Google through their commercial APIs (Google Gemini uses paid services). Under their commercial API terms, this content is not used to train their generative AI models.
Our standard API arrangements do not provide zero data retention. Providers may retain requests and responses for security and abuse monitoring:
- Anthropic (Claude): API inputs and outputs are normally deleted within 30 days.
- OpenAI (GPT): Abuse-monitoring logs may contain prompts and responses and are normally retained for up to 30 days.
- Google (Gemini): Prompts, contextual information and responses are retained for 55 days for abuse monitoring.
Longer retention can apply for legal obligations or suspected abuse. Stored files and other stateful API features may have separate retention periods under the provider's terms.
Our application hosting and document storage are in the EU (Ireland). AI processing may take place outside the EU, including in the US. Transfers are subject to GDPR Chapter V safeguards, including standard contractual clauses in the relevant providers' data processing agreements.
OpenRouter: When an organization connects OpenRouter with its own API key, document content is sent to OpenRouter, which forwards requests to model providers. Retention and use for training depend on the organization's OpenRouter account settings and the selected providers' policies.
Full list of sub-processors: /subprocessors.
Daytona: Per-run cloud sandboxes that hold the agent's working files (uploaded documents, intermediate notes, generated artifacts). Sandboxes are scoped to a single analysis run and torn down once the run completes; sandbox state is never shared between organizations.
AI Security Controls
Prompt Injection Mitigation: The platform implements structured prompt construction with clear separation between system instructions and user-provided document content. Agent tools validate all inputs before execution, reducing the risk of prompt injection attacks.
Output Validation: All AI-generated findings (compliance concerns, observations, entity extractions) are validated through structured tool calls with type checking, enum validation, and range verification before being persisted to the database. Critical and major findings undergo an additional automated verification pass.
Token and Cost Controls: The analysis engine enforces iteration limits and token budgets to prevent runaway processing. Token usage is tracked per analysis run and per agent type, providing full cost transparency and auditability.
Agent Isolation: Sub-agents operate with minimal context — they receive only the specific document sections and instructions needed for their task, not the full conversation history or other customers’ data.
Conversation Log Security: Full conversation logs between the orchestrator agent and AI providers are stored encrypted and are accessible only to the owning organization’s authorized users. Logs can be exported for audit purposes.
Document Processing Security
Upload Security: Documents are uploaded via the web interface with content-type validation. Uploaded files are stored in Amazon S3 with server-side encryption (AES-256) and are not publicly accessible.
Processing Pipeline: Uploaded documents are stored in S3 and copied into a per-run Daytona sandbox where the agent extracts text in-place using local skills (PDF, DOCX, XLSX, etc.). No third-party document parsing service is involved. Each run executes as an isolated background job.
Access Control: Documents are scoped to their parent procurement or bid record. Only users belonging to the owning organization can access documents. Tender documents that a buyer publishes on Tendergate are public on the tender page, or open only to people with the link for an invite-only tender. There are no other shared or public document URLs.
Document Deletion: When a document is deleted, the corresponding S3 object and parsed content are removed. Deleting a Library document also removes its search index entries.
Sealed Bids
Encryption in the Browser: When a bidder submits a sealed bid to a tender published on Tendergate, the bidder’s browser encrypts each file and the price list before upload, with a new key for every file. Until the opening, our servers store only encrypted data.
Separate Sealing Service: The tender keys and the sealed bids are held by a separate sealing service with its own database and keys, hosted in the EU. The Tendergate application holds no key and has no code that can decrypt a bid; it can only ask the sealing service for an opening.
Opening: The sealing service releases bids only after its own clock passes the submission deadline and the buyer’s appointed openers approve with their own opening keys (a passkey or an authenticator code set up on the sealing service): one opener for a simple purchase, two acting together for a regulated procedure. Every approval and release is written to a signed log that cannot be edited.
Submission Receipts: Every sealed submission gets a signed receipt with the time from the sealing service’s clock and a SHA-256 fingerprint of every file. Anyone can check a receipt at tendergate.ai/receipts/verify.
Limits: Tendergate operates the sealing service and holds its keys. Someone with direct access to those keys could decrypt outside the application; every decryption inside the application requires the openers’ approval and is signed. For a private purchase a buyer may run an open tender instead, where the buyer sees each bid as it arrives; bidders are told so on the tender page before they bid.
User Access Control
Authentication: All users must access the platform using a unique email address and password. Passwords must meet the platform’s complexity requirements, including minimum length and the use of both alphanumeric and special characters. Passwords are hashed using bcrypt with an appropriate cost factor and are never stored in plain text.
Two-Factor Authentication: Users can add a second sign-in step with an authenticator app (time-based one-time codes) or a passkey, and can sign in with a passkey alone. Single-use backup codes allow recovery when the other methods are unavailable. When two-factor authentication is on, it also applies to Google sign-in and password resets. Authenticator secrets are encrypted at rest and backup codes are stored only as keyed hashes. Repeated wrong codes lock the second step for 15 minutes. Organization owners and admins can require two-factor authentication for every member of their organization.
Session Management: User sessions are managed securely with encrypted, HTTP-only session cookies. Sessions expire after a period of inactivity. Concurrent session control is enforced.
Authorization: User access is strictly scoped to their organization. Users can only view and interact with procurements, bids, documents, and analysis results belonging to their organization. Role-based access levels are enforced. When a buyer publishes a tender on Tendergate, bidders’ organizations submit bids into it: the buyer’s organization reads them after the opening (in a regulated procedure, only the appointed openers and evaluators) or, in an open tender, as they arrive. A bidder’s organization sees only its own bids.
Account Review: User accounts are reviewed periodically to ensure that access levels are appropriate and that dormant accounts are disabled.
Access Logging and Monitoring
Monitoring Systems: Continuous monitoring is implemented through Heroku’s platform metrics and alerting capabilities to detect unusual activities that could indicate security incidents or vulnerabilities.
Analysis Audit Trail: Each AI analysis run maintains a complete audit trail including: initiating user, timestamps, documents analyzed, tools invoked, token usage, and all findings generated. This trail is immutable once the analysis is complete.
Incident Investigation: In the case of suspected or actual security incidents, detailed investigations are conducted, leveraging access logs, analysis audit trails, and monitoring data to understand the scope and impact.
Multi-Tenant Isolation
Organization-Level Isolation: The platform enforces strict multi-tenant isolation at the organization level. Each organization’s data (procurements, bids, documents, analysis results, entities) is logically separated in the database and cannot be accessed by users from other organizations. The one exception is bids on tenders published on Tendergate, which reach the buyer’s organization as described under Authorization and Sealed Bids.
Query-Level Enforcement: All database queries are scoped to the authenticated user’s organization, ensuring that data leakage between tenants is prevented at the application layer.
Search Index Isolation: The Library search index is scoped to each organization, and every search is limited to the searching organization's own current Library documents.
File Storage Isolation: Uploaded documents in S3 are organized and access-controlled per organization, preventing cross-tenant file access.
Infrastructure Security
Shared Responsibility Model: In line with Heroku’s shared responsibility model, while Salesforce ensures the security of the Heroku infrastructure, Tendergate is responsible for securing the application layer and managing access to its Heroku account and resources effectively.
Heroku Security Features: The platform utilizes Heroku’s security features to enhance its security posture, including automated SSL certificate management, network-level isolation, and customer-configurable features to maintain secure deployments.
Environment Variable Security: All sensitive credentials (API keys, database URLs, encryption keys) are stored as Heroku config vars, never committed to source code. Access to production configuration is restricted to authorized personnel.
Dependency Security: Application dependencies are regularly audited using automated tools (Bundler Audit for Ruby gems, Brakeman for static analysis, importmap audit for JavaScript dependencies) to detect and remediate known vulnerabilities.
Compliance and Certifications
GDPR: Our application hosting and document storage are in the EU (Ireland). AI processing may take place outside the EU, including in the US. Transfers are subject to GDPR Chapter V safeguards, including standard contractual clauses in the relevant providers' data processing agreements.
ISO 27001, 27017, and 27018: Recognition of Salesforce’s certifications against these standards ensures adherence to recognized security management best practices and protection of PII.
SOC 1, 2, and 3: Salesforce’s SOC reports confirm the design and effectiveness of Heroku’s controls relevant to the security, availability, and confidentiality of customer data.
PCI: Salesforce’s Attestation of Compliance as a PCI Level 1 Service Provider is acknowledged. Payment card processing is fully delegated to Stripe (see Payment Security).
Payment Security
Stripe Checkout: All payment processing is handled entirely by Stripe via Stripe Checkout. No payment card data is transmitted to, processed by, or stored on the Tendergate infrastructure.
PCI Compliance: PCI DSS compliance is fully delegated to Stripe, a certified PCI Level 1 Service Provider. The platform’s PCI scope is limited to redirecting users to the Stripe-hosted checkout page.
Webhook Security: Stripe webhook events are verified using Stripe’s webhook signature verification to ensure authenticity and prevent replay attacks.
Credit System: Customer credits are managed internally after confirmed Stripe payment events. Credit balances are maintained in the platform’s database with full transaction audit trails.
Security Audits
Regular Audits: Security audits are conducted regularly to assess the platform’s compliance with this policy and to identify potential vulnerabilities.
Automated Scanning: Static analysis (Brakeman), dependency auditing (Bundler Audit), and JavaScript dependency checks (importmap audit) are run as part of the development and deployment process.
Audit Response: Findings from security audits are addressed in a timely manner, with corrective actions implemented to mitigate identified risks.
Third-Party Security
The platform integrates with the following third-party services. Each is assessed for compliance with relevant security standards:
| Provider | Purpose | Data Shared | Security Posture |
|---|---|---|---|
| Heroku (Salesforce) | Application hosting | All application data | SOC 1/2/3, ISO 27001, PCI Level 1, GDPR |
| AWS (S3) | Document file storage | Uploaded documents | SOC 1/2/3, ISO 27001, PCI Level 1 |
| Anthropic | AI analysis (Claude) | Document content for analysis | API no-training policy, SOC 2 |
| OpenAI | AI analysis (GPT) | Document content for analysis | API no-training policy, SOC 2, ISO 27001 |
| AI analysis (Gemini) | Document content for analysis | API no-training policy, ISO 27001, SOC 1/2/3 | |
| OpenRouter | AI request routing (when connected by the organization) | Document content and prompts forwarded to model providers | OpenRouter account settings and the selected providers' data policies apply |
| Daytona | Per-run agent sandbox | Customer documents (sandbox-scoped) | Tenant-isolated, ephemeral runtime |
| Stripe | Payment processing | No card data (redirect only) | PCI Level 1, SOC 1/2 |
| Google Analytics | Website analytics (via tendergate.ai domain) | Anonymized usage data (page views, traffic sources) | GDPR-compliant, ISO 27001, SOC 1/2/3 |
| Sentry (Functional Software) | Application error monitoring | Error reports: exception messages, stack traces, request metadata (automatic collection of personal data such as IP addresses and cookies is disabled) | US data region, SOC 2 Type II, ISO 27001, GDPR DPA |
| Smartlook | Session recording and analytics (via tendergate.ai domain) | User interaction data (clicks, scrolls, navigation) | EU data processing, GDPR-compliant, SOC 2 |
Data Minimization: Data shared with third-party providers is limited to what is necessary for the requested workflow, including analysis, composition, Library indexing and Library search.
Contractual Safeguards: Agreements with third-party providers include terms ensuring data protection, confidentiality, and incident notification obligations.
Analytics Note: Any analytics cookies (such as Google Analytics or Smartlook) are managed at the tendergate.ai domain level. The Platform itself does not deploy tracking scripts directly. Analytics cookies are used in accordance with applicable law.
Acceptance and Compliance
All users of the Tendergate are required to acknowledge and comply with this security policy. Violations of the policy may result in disciplinary action, up to and including termination of access to the platform.
Incident Response
Incident Detection: The platform implements monitoring tools and automated alerting to detect potential security incidents, including unauthorized access attempts, unusual API usage patterns, and infrastructure anomalies.
Incident Response Plan: In the event of a security incident, a predefined incident response plan is activated. This includes:
- Containment — Isolate affected systems to prevent further impact
- Eradication — Identify and remove the root cause
- Recovery — Restore affected services and verify integrity
- Post-Incident Analysis — Document findings and implement preventive measures
Data Breach Notification: In the event of a personal data breach, affected customers and relevant supervisory authorities will be notified within 72 hours as required by GDPR Article 33.
Communication: Stakeholders are informed about significant security incidents in accordance with the platform’s communication protocol. Security incidents can be reported to info@mitigate.dev.
Policy Review and Update
Review Cycle: This security policy is reviewed annually or following significant changes to the platform, its hosting environment, or its AI provider integrations.
Updates: The policy is updated as necessary to address new security challenges, including evolving AI/LLM security considerations, and to reflect changes in best practices.
Prepared by Mitigate: Edgars Beigarts, Mitigate CTO
Contact
SIA Mitigate
Gustava Zemgala gatve 74A, Riga, LV-1039, Latvia
Reg. No.: 50103381201
Security incidents: info@mitigate.dev
Data processing inquiries: datuapstrade@mitigate.dev
Technical support: ai@mitigate.dev