A real sample security pack
Generated for Driftnet, This sample was generated by the same pipeline customers use, from a real intake for driftnet — an LLM-eval tool we run ourselves on Vercel, Stripe, OpenRouter, and GitHub. Operational details the public record doesn't establish use the most plausible value for a solo-founder SaaS on that stack.
This is the exact pipeline output a paying customer receives — the same prompts, the same validator gate, the same rendering — shown in full. Nothing here is staged or hand-edited. Every document carries its attestation line; items the intake marked “not yet” appear only in the Roadmap section, never as current practice.
Driftnet — Security & Trust
Based on answers provided by Driftnet on 2026-06-12. Self-attested by the vendor; not audited or certified by any third party.
Overview
Driftnet is an LLM-eval tool that catches output drift, built for solo developers. The product is operated by a single founder. Security controls are proportionate to that scale: specific in the areas that matter for customer data, and honest about what is not yet in place.
Infrastructure & Hosting
Driftnet runs on Vercel using serverless functions and Vercel Blob storage. All customer data is held in the United States in Vercel's iad1 region. No other geographic regions are used.
A public health endpoint is available at driftnet.forage.bot/api/health for uptime verification.
Backups and a formal disaster-recovery runbook are not currently in place; see Roadmap below.
Data Protection
Data stored: Customer email addresses, eval prompts and model outputs submitted for testing, and billing records processed through Stripe.
Encryption in transit: TLS 1.2 or higher on all endpoints.
Encryption at rest: Provider-managed encryption on Vercel Blob storage.
Retention and deletion: Data is removed from live systems within 30 days of a verified deletion request submitted to driftnet@forage.bot.
Export: Customers can download their eval packs and results at any time from their tokenized dashboard.
GDPR: Export and deletion requests are handled on request via driftnet@forage.bot.
Access & Authentication
Production access: The founder is the only person with access to production systems and customer data. Access requires individual credentials with two-factor authentication (2FA) enforced.
Customer authentication: Customers access the product through tokenized private dashboard links. No passwords are created or stored by Driftnet.
Staff device security: The founder's machines use full-disk encryption and OS-level automatic updates.
SSO for customers is not currently available; see Roadmap below.
Monitoring & Vulnerability Management
Logging: Request and function logs are retained at Vercel's default hosting-provider retention. No extended log retention is configured at this time.
Dependency management: GitHub Dependabot provides automated alerts for dependency vulnerabilities. Critical patches are applied within days of notification.
Incident response: The founder monitors alerts, assesses and remediates incidents, and notifies affected customers by email within 72 hours of confirming an incident.
Development practices: Changes go through staging preview deploys before reaching production. Secrets are stored in environment configuration, not in source code. An automated test suite runs on every change.
A third-party penetration test has not been conducted; see Roadmap below.
Subprocessors
| Subprocessor | Purpose |
|---|---|
| Vercel | Hosting (serverless functions and blob storage) |
| Stripe | Payment processing and billing records |
| OpenRouter | LLM inference |
| GitHub | Support issue tracking |
Current Posture & Roadmap
In place today
- TLS 1.2+ encryption in transit on all endpoints
- Provider-managed encryption at rest on Vercel Blob storage
- Production access restricted to the founder, with 2FA enforced
- Tokenized dashboard links for customer authentication (no stored passwords)
- Full-disk encryption and auto-updates on founder devices
- GitHub Dependabot automated dependency alerting; critical patches within days
- Staging preview deploys before all production changes
- Secrets stored in environment configuration, not source code
- Automated test suite on every change
- Data deletion within 30 days of request
- Customer data export available on demand
- GDPR export and deletion handled on request
- Breach notification to affected customers within 72 hours of confirmed incident
- Public health endpoint at
driftnet.forage.bot/api/health
Planned
- We plan to implement a formal backup strategy for customer data
- We plan to document a disaster-recovery runbook
- We plan to offer SSO as a customer authentication option
- We plan to conduct a third-party penetration test
- We plan to configure extended audit log retention beyond provider defaults
- We plan to pursue formal security certification (such as SOC 2)
- We plan to obtain cyber-liability insurance
Contact
Security questions, vulnerability disclosures, and data-subject requests (including GDPR export and deletion) should be sent to driftnet@forage.bot.
Security Questionnaire Answer Bank — Driftnet
Based on answers provided by Driftnet on 2026-06-12. Self-attested by the vendor; not audited or certified by any third party.
Q: How is customer data encrypted at rest?
A: Customer data stored in Vercel Blob storage is protected by provider-managed encryption at rest, applied automatically by Vercel to all objects in the storage layer. This covers eval prompts, model outputs, and any other customer data persisted to blob storage. We rely on Vercel's documented encryption controls for this layer rather than operating our own key management. Customers can review Vercel's infrastructure security documentation for implementation specifics.
Q: How is customer data encrypted in transit?
A: All endpoints exposed by Driftnet enforce TLS 1.2 or higher; no unencrypted HTTP connections are accepted. This applies to the customer dashboard, the public health endpoint at driftnet.forage.bot/api/health, and all API calls made by serverless functions running on Vercel. Data in transit to subprocessors such as Stripe and OpenRouter is also protected by TLS as required by those providers' own policies.
Q: How do you enforce access control and least privilege to production systems and customer data?
A: Production systems and customer data are accessible only to the founder, who is the sole member of the team. Access is granted through individual credentials with two-factor authentication enforced on critical systems; no shared or service accounts with broad permissions are used. Customer-facing access to data is scoped per customer through tokenized private dashboard links, so each customer can only reach their own eval packs and results. No additional staff, contractors, or third parties have standing access to production.
Q: Is multi-factor authentication (MFA) enforced for personnel with access to production or customer data?
A: Yes. Two-factor authentication is enforced for the founder's accounts on all critical systems, including production infrastructure. Because the team consists of one person, this control covers the entirety of staff access to production and customer data. The founder's workstation is additionally protected by full-disk encryption and OS auto-updates to reduce endpoint risk.
Q: How are customer data backups handled, and do you maintain a disaster-recovery runbook?
A: Formal backups and a documented disaster-recovery runbook are not yet in place; these are both identified roadmap items. Today, Vercel's platform provides some inherent durability for blob storage objects, but Driftnet does not operate independent backup jobs or a tested restore process. Planned: We plan to implement scheduled backups and a written disaster-recovery runbook. Prospective customers with strong RTO/RPO requirements should factor this gap into their risk assessment.
Q: What is your incident-response process, and what is your breach-notification commitment?
A: Driftnet operates a founder-run incident-response process: incidents are detected through monitoring alerts, assessed for scope and impact, remediated, and affected customers are notified by email within 72 hours of confirming that an incident has occurred. This 72-hour notification window applies to security incidents including any unauthorized access to customer data. The process is informal and undocumented beyond this description, reflecting the single-person team size. Customers can reach the security contact at driftnet@forage.bot to report suspected incidents.
Q: Which subprocessors process or store customer data on your behalf?
A: Driftnet uses four subprocessors that may touch customer data: Vercel (serverless function hosting and blob storage, United States — iad1 region), Stripe (payment processing and billing records), OpenRouter (LLM inference; eval prompts and model outputs are routed through OpenRouter for processing), and GitHub (support issue tracking, which may contain information customers include in support requests). All customer data at rest is held in Vercel's iad1 region in the United States. Customers with questions about a specific subprocessor's data-handling practices should consult that provider's documentation directly.
Q: How can customers request deletion of their data, and what are your data-retention practices?
A: Customers can request deletion of their data by emailing driftnet@forage.bot; data is removed from live systems within 30 days of a confirmed deletion request. The data categories held are customer email addresses, eval prompts and model outputs submitted for testing, and billing records managed through Stripe. Customers can also export their eval packs and results at any time by downloading them from the tokenized dashboard. GDPR data-subject requests for export or deletion are handled through the same support email channel.
Q: How do you manage software vulnerabilities and dependency updates?
A: Driftnet uses GitHub Dependabot to receive automated alerts when dependencies have known vulnerabilities. Critical patches are applied within days of an alert being raised. All code changes pass through an automated test suite, and changes are deployed to staging preview environments before being promoted to production, which reduces the risk of a patch introducing a regression. There is no formal vulnerability disclosure program, but security reports can be submitted to driftnet@forage.bot.
Q: Do you support Single Sign-On (SSO) for customer authentication?
A: SSO is not currently offered. Today, customers authenticate to Driftnet through tokenized private dashboard links issued per customer; no passwords are created or stored on Driftnet's side. Planned: SSO support is on our roadmap. Customers requiring SSO as a condition of procurement should note that it is not available at this time.
Q: What security certifications or third-party audits does your organization hold?
A: Driftnet does not currently hold any security certifications and has not undergone a third-party penetration test or independent security audit. The controls described in this document are self-attested. Planned: Third-party penetration testing and formal security certification are on our roadmap. We are a single-person early-stage product, and we are transparent about this gap so that customers can make an informed risk decision. Security questions and concerns can be directed to driftnet@forage.bot.
Q: Do you maintain audit logs of access to production systems and customer data?
A: Driftnet retains the request logs and serverless function logs generated automatically by Vercel for hosted infrastructure; these capture inbound requests and function execution records for the default retention period Vercel applies. No extended log retention or centralized audit-logging pipeline beyond Vercel's defaults is configured at this time. Because production access is limited to a single individual authenticated with 2FA, the access-control surface for audit purposes is narrow. Extended log retention and a more structured audit-logging approach are items we intend to address as the product matures.
Access Control & Identity Policy
Based on answers provided by Driftnet on 2026-06-12. Self-attested by the vendor; not audited or certified by any third party.
Scope
This policy covers how access to Driftnet's production systems, customer data, and supporting services is granted, managed, and revoked. It applies to all systems that process or store customer data, including Vercel (hosting and blob storage), Stripe (billing), OpenRouter (LLM inference), and GitHub (support issue tracking).
Account Provisioning and Deprovisioning
Driftnet is a one-person operation. The sole account holder is the founder, who holds credentials for all systems listed above. There is no employee onboarding or offboarding process because there are no additional staff. If subprocessor accounts need to be revoked or rotated — for example, following a credential compromise — the founder performs that action directly through each provider's administrative console.
Subprocessor accounts are created only as needed for the specific function each provider serves. No shared or generic credentials are used across services.
Production Access
Only the founder can access production systems and customer data. Access to Vercel's deployment environment, blob storage, and all connected services is authenticated through individual, named credentials. No third party, contractor, or automated service account holds standing access to production outside of the permissions granted to each subprocessor for its stated function (e.g., Stripe's access is limited to billing data; OpenRouter's access is limited to inference requests).
Authentication Requirements
Staff accounts: Two-factor authentication (2FA) is enforced on all critical systems accessible by the founder. This covers the Vercel dashboard, GitHub, Stripe, and OpenRouter accounts. Credentials are not stored in source code; all secrets are held in environment configuration on Vercel.
Customer accounts: Customers do not create passwords and no passwords are stored. Instead, each customer receives a tokenized private dashboard link unique to their account. Access to eval packs and results is gated on possession of that token. This eliminates the risk of password reuse or credential stuffing against customer accounts.
Least Privilege
Because only one person operates Driftnet, the principle of least privilege is applied at the subprocessor level rather than across internal roles:
- Vercel holds access to hosting infrastructure and blob storage only.
- Stripe handles payment processing and holds billing records; it has no access to eval data.
- OpenRouter receives inference requests; it does not receive persistent customer identifiers beyond what is included in a given request.
- GitHub is used for support issue tracking; it is not connected to production infrastructure.
The founder's own access is necessarily broad, which is an accepted risk of a single-person team and is partially mitigated by 2FA enforcement and full-disk encryption on all working devices.
Roadmap
The following items are not yet in place and are planned for future implementation:
- Customer SSO: We plan to offer SSO login options for customers as the product grows beyond its current tokenized-link authentication model.
- Formal access review process: We plan to document a periodic review of subprocessor permissions and API key rotation schedules as team size or customer volume increases.
Contact
Questions about this policy or requests related to account access can be directed to driftnet@forage.bot.
Incident Response & Breach Notification Policy
Based on answers provided by Driftnet on 2026-06-12. Self-attested by the vendor; not audited or certified by any third party.
Overview
Driftnet is a one-person operation. Incident response is carried out directly by the founder, without a dedicated security team. This document describes how we detect, assess, contain, and recover from security incidents, and what customers can expect from us if their data is involved.
Detection
We rely on a combination of automated monitoring and direct observation to identify potential incidents:
- Hosting-provider logs: Vercel request logs and serverless function logs are available for review and surface anomalous activity such as unexpected error rates or unusual request patterns.
- Health endpoint: A public endpoint at
driftnet.forage.bot/api/healthgives a live indication of service availability. - Dependency alerts: GitHub Dependabot sends automated alerts when known vulnerabilities are identified in project dependencies. These alerts are reviewed by the founder as they arrive.
- Stripe and subprocessor notifications: We monitor communications from Vercel, Stripe, OpenRouter, and GitHub for any platform-level security notices that could affect customer data.
Assessment
When a potential incident is identified, the founder assesses it against the following questions:
- Which systems or data categories are affected — customer email addresses, eval prompts and model outputs, or billing records via Stripe?
- Is the exposure ongoing or contained?
- Which customers, if any, are likely affected?
The scope of the response scales with the severity of the answers.
Containment and Remediation
Containment steps depend on the nature of the incident but follow this general sequence:
- Isolate or disable the affected function, endpoint, or credential as quickly as possible.
- Apply a fix. For dependency vulnerabilities, critical patches are applied within days of a confirmed alert. For configuration or code issues, a corrected deploy is pushed through our standard process — staging preview first, then production.
- Verify the fix is in place before restoring full service.
- Rotate credentials if any secrets, tokens, or access keys may have been exposed. Secrets are stored in environment configuration, not in source code, which limits the blast radius of a repository exposure.
Production systems are accessible only to the founder, via individual credentials protected by 2FA, which reduces the number of access vectors that need to be reviewed.
Customer Notification
If we confirm a security incident that affects customer data, we will notify affected customers by email within 72 hours of confirming the incident. The notification will describe what happened, which data categories were involved, what we have done to contain it, and any steps we recommend customers take.
Post-Incident Review
After every confirmed incident, the founder conducts a brief written review covering: what happened, how it was detected, how long it took to contain, and what change — to code, configuration, or process — prevents recurrence. This review is retained internally.
Roadmap
The following recovery and resilience capabilities are not yet in place. We plan to address them as the product grows:
- Backups: We plan to implement regular automated backups of customer data so that a data-loss event can be recovered from a known-good state.
- Disaster-recovery runbook: We plan to document a formal DR runbook that covers specific recovery steps, target recovery times, and validation procedures.
- Extended log retention: We plan to configure log retention beyond Vercel's short default window, giving us a longer audit trail for incident investigation.
Contact
Security questions and incident disclosures can be sent to driftnet@forage.bot.
Data Protection & Retention Policy
Based on answers provided by Driftnet on 2026-06-12. Self-attested by the vendor; not audited or certified by any third party.
1. Data Categories We Handle
We store the following categories of customer data in connection with operating Driftnet (driftnet.forage.bot):
- Email addresses — used to identify customers and send operational communications.
- Eval prompts and model outputs — the LLM inputs and responses customers submit for drift testing.
- Billing records — payment and transaction data processed through Stripe.
We do not collect passwords. Customers access their dashboards through tokenized private dashboard links; no password is created or stored on our side.
2. Encryption
In transit: All data exchanged between customers and Driftnet is protected by TLS 1.2 or higher on every endpoint.
At rest: Customer data stored in Vercel Blob storage is encrypted at rest using provider-managed encryption supplied by Vercel.
3. Data Retention and Deletion
We retain customer data for as long as the customer account is active or as needed to provide the service. Customers may request deletion of their data at any time by emailing driftnet@forage.bot. We will remove the data from live systems within 30 days of receiving a confirmed deletion request.
Customers can also export their eval packs and results at any time directly from their tokenized dashboard.
4. Backups
We do not currently maintain a separate backup system for customer data beyond what Vercel's platform provides by default. See the Roadmap section below.
5. Subprocessors
The following third-party subprocessors may handle customer data as part of delivering the service:
| Subprocessor | Purpose | Data Involved |
|---|---|---|
| Vercel | Hosting, serverless compute, and blob storage | All customer data at rest and in transit |
| Stripe | Payment processing | Billing records |
| OpenRouter | LLM inference routing | Eval prompts and model outputs |
| GitHub | Support issue tracking | Information included in support communications |
All customer data is stored in the United States, in Vercel's iad1 region.
6. GDPR Data-Subject Requests
We support the following data-subject rights for customers who are subject to GDPR:
- Access / Export: Customers can download their eval packs and results from their tokenized dashboard at any time. Additional data exports are available on request via driftnet@forage.bot.
- Deletion / Erasure: Customers may request erasure of their data by emailing driftnet@forage.bot. We complete deletion from live systems within 30 days.
Requests are handled directly by the founder. We aim to acknowledge requests promptly and fulfil them within the 30-day window described above.
7. Roadmap — Items Not Yet in Place
The following data-protection measures are planned but not currently operational:
- Backups: We plan to implement a structured backup process with defined retention windows and restoration testing.
- Disaster-recovery runbook: We plan to document a formal disaster-recovery procedure covering data restoration steps and recovery-time targets.
8. Contact
Security questions, data-subject requests, and vulnerability disclosures should be directed to: