CURFEW SECURITY & SUBPROCESSORS#
1. Purpose#
This page describes the technical and organizational measures Curfew Labs Inc. uses to protect Customer Data, and lists the subprocessors that may process Customer Data.
It is referenced by the Curfew Customer Terms, Schedule C (AI & Agent Terms), and the Data Processing Addendum. It is maintained as a live page and is updated as our practices and subprocessors change.
Nothing on this page is a service level commitment. No uptime, response time, or recovery time on this page is contractually binding unless expressly stated in a signed order form.
2. Hosting and data location#
All Customer Data is stored in the United States.
| Item | Detail |
|---|---|
| Application platform | Railway Corp., US West region (sfo) |
| Database | PostgreSQL, managed on Railway, same region |
| Object storage (uploads, files, generated PDFs) | Railway object storage, same account |
| Backups | Amazon Web Services S3, us-east-1 (N. Virginia) |
| Email (inbound and outbound) | Amazon SES, us-east-1 |
| Text messages (sign-in codes; planned) | AWS End User Messaging, us-east-1 |
| AI inference (default) | Amazon Bedrock, us-east-1 and us-east-2 |
| Primary data location | United States |
| Data residency options | None. There is no EU region. |
No Customer Data is stored in the European Union.
3. Encryption#
| Control | Status |
|---|---|
| Encryption in transit | TLS for all connections to the Services, to the database, and to every subprocessor API |
| Database encryption at rest | |
| Backups encryption at rest | Yes. AES-256 server-side encryption, verified on the S3 bucket |
| Inbound email storage at rest | Yes. AES-256 server-side encryption, verified on the S3 bucket |
| Uploaded files at rest | Not claimed. See below. |
| Third-party credentials you supply | AES-256-GCM, encrypted with a master key held only in the platform environment. Stored write-only: never returned to a browser, and displayed only as a last-four hint |
| Sign-in passwords | Not applicable. Curfew uses passwordless email sign-in and does not store passwords |
| Customer-managed keys | Not available |
On uploaded files. Our object storage provider does not expose a server-side-encryption setting, so we do not claim that uploaded files are encrypted at rest. What we do claim, and can evidence: the store is private, every download is access-gated and short-lived, transfers are encrypted in transit, and links expire. We would rather state a narrower true thing than a broader one we cannot prove.
4. Access control#
| Control | Status |
|---|---|
| Application runs as a least-privilege database role | Yes. The application connects as a non-superuser role that is itself subject to row-level security. The superuser role is used only for schema migrations and break-glass, never by the running application |
| Tenant isolation enforced in the database | Yes. Row-level security is enabled and forced on entity-owned tables, keyed to the workspace of the current request, default-deny |
| Multi-factor authentication for personnel with production access | |
| Production access logged | Partially. Administrative actions inside the product are logged to an append-only audit log per workspace. Direct database and platform access is not separately logged beyond the provider's own logs |
5. Customer-facing security features#
| Feature | Status |
|---|---|
| Passwordless sign-in | Yes. Single-use, short-lived email links. No password is created, stored, reused or leaked |
| Multi-factor authentication for Users | Not available |
| Single sign-on / SAML | Not available |
| Role-based permissions | Yes. Three organization roles, plus a per-person, per-app access level, plus additive in-app permissions for sensitive functions such as compensation and payments |
| Per-app access is explicit | Yes. No app is granted automatically. A new workspace starts with no apps installed |
| Administrator audit log | Yes. An append-only log of administrative events per workspace, browsable by administrators |
| Session management | Sessions are signed cookies with a 30-day maximum age. A configurable idle timeout is not available |
| IP allowlisting | Not available |
| Malware scanning of uploads | Yes. Files uploaded to file-sharing and ticketing features are scanned before they can be downloaded; an infected file is retained as evidence but blocked |
| Data export | Available per app; a single-click account-wide export is not currently offered |
6. Logging and monitoring#
| Control | Status |
|---|---|
| Application and infrastructure logging | Provided by the hosting platform |
| Administrative audit log | Yes, append-only, per workspace, retained for the life of the workspace |
| Integration health monitoring | Yes. Connections are probed on a daily schedule and results retained as a run history |
| Alerting on anomalous security activity | No. We do not currently operate security-specific alerting |
| Agent Action logging | Yes, with an important qualification. See below |
Agent Actions. Curfew's assistant runs with the permissions of the person using it and cannot see or do anything that person could not. Any action that would change data is returned as a proposal that a person must confirm; the assistant does not write on its own. Each assistant session retains the tool calls it made and their timings, reviewable by the person who ran it.
Qualification, because Schedule C §C.6.3 depends on it: that trace is visible to the individual User in their own session. There is not currently a workspace-wide administrator view of every Agent Action across all Users. If Schedule C places supervision of Agents on the Customer, an administrator cannot fully discharge that duty today.
7. Backups and recovery#
| Item | Detail |
|---|---|
| Backup frequency | Twice daily, 06:00 and 18:00 UTC |
| What is backed up | Full database dump, plus a mirror of the object store |
| Backup location | Amazon S3, us-east-1, separate cloud account from the primary host |
| Backup retention | Daily 30 days; first-of-month copies 400 days; superseded object versions 90 days |
| Backups encrypted | Yes, AES-256 at rest, TLS in transit |
| Backup storage private | Yes, public access blocked, versioning enabled |
| Restoration tested | Partially. The archive is verified as readable and complete end to end. A full restore into a live database has not been drilled |
| Recovery point objective | None committed. Worst case is the interval since the last backup, up to 12 hours |
| Recovery time objective | None committed |
Customers are responsible for exporting their own Customer Data. Backups are maintained for our operational continuity and are not a customer-facing restore service. We do not commit to restoring individual records, Accounts, or data deleted by a User or Administrator.
8. Development and change management#
| Control | Status |
|---|---|
| Version control for all application code | Yes |
| Type checking and linting enforced | Yes, on every build |
| Automated testing | Partially. Business-logic engines carry unit tests. There is a maintained library of manual test kits per app, and runs are recorded with findings filed as defects |
| Documented bug severity framework | Yes |
| Code review before merge to production | No formal gate. Changes are pushed to the main branch and deploy automatically |
| Separate deployment approval | No. Deployment is automatic on merge |
| Static analysis beyond linting | No |
| Schema changes reviewed | Applied deliberately as versioned migrations, separately from application deploys |
9. Vulnerability management#
| Item | Detail |
|---|---|
| Platform patching | Managed by the hosting provider for the runtime and database |
| Penetration testing | Not currently performed |
| Untrusted file handling | Files uploaded by users are parsed in an isolated worker with a time and size limit, so a malformed file cannot stall the service, and are malware-scanned before download |
| Vulnerability reporting | support@curfewsuite.com |
Safe harbor. If you report a vulnerability to us in good faith, give us a reasonable opportunity to remediate before disclosing it, do not access or modify data belonging to others, and do not degrade the Services, we will not pursue legal action against you for that research.
10. Personnel#
| Control | Status |
|---|---|
| Confidentiality obligations for all personnel and contractors |
11. Incident response#
We maintain an incident response process covering detection, triage, containment, remediation, and notification.
Notification. Where we become aware of a personal data breach affecting Customer Data, we will notify the affected Customer without undue delay in accordance with the Data Processing Addendum, and will provide information reasonably available to us to support the Customer's own notification obligations.
We do not commit to a fixed hour count on this page. We do not currently operate security-specific alerting (§6), so a commitment to detect within a fixed window would not be one we could keep.
Curfew is a processor, not a controller, for Customer Data. Notification to data subjects and to supervisory authorities is the Customer's obligation.
12. Compliance and certifications#
| Framework | Status |
|---|---|
| SOC 2 Type II | Not currently held |
| ISO 27001 | Not currently held |
| GDPR | Data Processing Addendum available at www.curfewsuite.com/dpa |
| CCPA / CPRA | Curfew acts as a service provider; see the DPA |
| HIPAA | Not supported. Do not submit protected health information |
| PCI DSS | Not applicable to Curfew. Card details are entered directly into our payment processor and are never transmitted to or stored by Curfew. We hold only a card brand and last four digits for display |
13. Subprocessors#
We engage the following subprocessors to process Customer Data. This list is current as of the date above.
A note on what is not on this list, because it is unusual and it is deliberate: document conversion, malware scanning, speech-to-text and product analytics all run on infrastructure we operate ourselves rather than through a third-party service. Those functions therefore add no subprocessor and send no Customer Data outside the systems listed below.
13.1 Infrastructure#
| Subprocessor | Purpose | Location |
|---|---|---|
| Railway Corp. | Application hosting, compute, managed PostgreSQL, object storage | United States (US West) |
| Amazon Web Services, Inc. | Backup storage (S3); inbound and outbound email (SES); AI inference (Bedrock); text messages for sign-in codes (AWS End User Messaging; planned) | United States (us-east-1, us-east-2) |
| Stripe, Inc. | Payment processing and card storage for Curfew subscription billing | United States |
whether Railway's own subprocessor disclosure needs to be referenced here.
13.2 Model Providers#
Referenced by Schedule C, Section C.4.3.
| Model Provider | When used | Terms engaged under | Training on Input/Output | Retention |
|---|---|---|---|---|
| Amazon Bedrock (AWS) | Default for all AI features | |||
| OpenRouter, Inc. | Fallback only, if Bedrock is unavailable | |||
| Anthropic / OpenAI / Google | Only if you supply your own API key | Your agreement with that provider, not ours | Per your agreement | Per your agreement |
Bring your own key. A workspace may supply its own model provider credentials. Where it does, inference runs under that workspace's own agreement with that provider and Curfew's platform credentials are not used. A workspace may also require this, so that its data never rides a shared Curfew key.
No Customer Data leaves the United States for AI processing under the default configuration, because Bedrock is used in US regions. This is the reverse of the usual startup position and is worth stating.
Each row must be verified against the agreement actually signed with that provider, and re-verified when that provider changes its terms.
13.3 Other data flows that are not subprocessing#
Disclosed for completeness. No Customer Data is sent to these.
| Service | Purpose | What is sent |
|---|---|---|
| U.S. Census Bureau Geocoder | Normalizing US postal addresses you type | The address text being normalized |
| European Central Bank rates (via Frankfurter) | Daily currency rates | Nothing. We fetch a public rate table |
13.4 Changes to subprocessors#
We will update this page before engaging a new subprocessor that processes Customer Data. Customers may subscribe to change notifications by writing to support@curfewsuite.com. Objection rights, if any, are set out in the Data Processing Addendum.
14. Shared responsibility#
Security of the Services is a shared responsibility.
Curfew is responsible for: the security of the platform, its infrastructure, its code, and its subprocessor relationships; the controls described on this page.
You are responsible for: who you invite as Users and Administrators; what permissions you grant them; the safeguarding of the email accounts used to sign in, which are the credential; which Third-Party Services you connect and what credentials you supply to them; how you scope and supervise Agents; what data you submit, including compliance with Section 6.4 of the Terms; and exporting your own Customer Data.
Because sign-in is by email link, the security of a User's email account is the security of their Curfew account. We recommend enforcing multi-factor authentication on your email provider.
Administrators can access, export, and permanently delete Customer Data, including data submitted by other Users. No control described on this page prevents that.
15. Contact#
Security reports: support@curfewsuite.com Privacy and data protection: support@curfewsuite.com General: support@curfewsuite.com
16. Changes to this page#
We may update this page as our practices and subprocessors change. Material changes are versioned. Prior versions are archived at www.curfewsuite.com/security.