Information Security Policy

1. Purpose and scope

Curator operates a multi-tenant SaaS platform that connects to customers’ business systems (commerce, advertising, finance, CRM, messaging, and file storage providers), ingests business data, and runs AI agents over that data on the customer’s behalf.

This policy governs the confidentiality, integrity, and availability of:

• customer business data ingested through connectors, and any files a customer uploads;
• customer credentials and OAuth grants for third-party providers;
• authentication data for Curator user accounts;
• Curator source code, infrastructure, and secrets;
• corporate systems (email, chat, document storage, code hosting, ticketing).

Scope of application: all employees, founders, contractors, and any third party with access to Curator systems or customer data. Compliance is a condition of access.

Out of scope: customers’ own environments and the security of the third-party providers they choose to connect. Curator’s responsibility begins at the point data is received and ends at the point data is returned or deleted.

2. Roles and responsibilities

Security is a named responsibility, not a shared assumption. Where the company is small enough that one person holds several roles, the CTO documents that in the risk register rather than leaving it implicit.

3. Personnel security

• Onboarding: background check where legally permitted; signed confidentiality/IP agreement; acceptance of this policy and the Acceptable Use rules in §3.1; access granted on a least-privilege basis by the CTO.
• Training: security awareness training at onboarding and annually, covering phishing, social engineering, credential handling, secure handling of customer data, and AI-specific risks (prompt injection, unintended data exposure through agent tools).
• Offboarding: on the last working day, all accounts disabled, SSO sessions revoked, device returned or wiped, and any shared secrets the individual could have observed rotated. Offboarding is tracked to completion on a checklist retained by the CTO.
• Contractors are held to the same standards, with access time-boxed to the engagement and reviewed at its close.

3.1 Acceptable use

• Company work is performed on company-managed devices with full-disk encryption, screen lock ≤ 5 minutes, automatic OS updates, and endpoint protection enabled.
• Credentials are stored only in the company password manager. Credentials are never pasted into chat, tickets, source code, or AI tools.
• Production customer data is not copied to local machines, personal storage, or personal accounts. Where a debugging task appears to require it, the engineer requests approval from the CTO and uses a redacted or synthetic dataset instead wherever possible.
• Third-party services that will process customer data are not adopted without subprocessor review (§11).

4. Asset and data inventory

The CTO maintains a current inventory covering:

• Production infrastructure — the Fly.io gateway application and its persistent volume, the Supabase Postgres database, the Vercel-hosted frontend, and the browser extension distribution.
• Data stores — raw upstream entity rows, the artifact rollup schema, tenant upload bytes on the gateway volume, and agent session workdirs.
• Corporate SaaS — code hosting, chat, email, document storage, ticketing, analytics.
• Subprocessors — see §11.

4.1 Data classification

Restricted and Confidential data are never used in development or test environments. Test fixtures are synthetic or drawn from tenants Curator owns.

5. Access control

• Identity: all corporate and infrastructure access is via SSO with MFA enforced. Shared logins are prohibited; where a vendor supports only one account, credentials live in the password manager with access limited to named individuals and are rotated on any personnel change.
• Least privilege: access is granted by role, only to what the role requires, and only for as long as the role requires it. Production database access is limited to engineers with an operational need.
• Database roles: the platform uses distinct, purpose-scoped Postgres roles rather than a single superuser DSN — an owner/migration role, a read-only sandbox role, a write-scoped sandbox role limited to artifact tables, and a processor role. The agent sandbox connects through a local pooler configured so that the underlying database password is never exposed to agent-executed code.
• Tenant isolation: enforced in the database with row-level security on tenant-scoped tables, so isolation does not depend on application code remembering to filter. New tenant-scoped tables must ship with RLS in the same migration; a change that adds a tenant-scoped table without RLS is rejected in review.
• Reviews: the CTO performs a quarterly access review across infrastructure, database roles, corporate SaaS, and repository permissions, revoking anything no longer justified. Review completion is recorded.
• Customer-facing access: customer users authenticate through the platform’s managed auth provider; authorization is scoped to their tenant and workspace. Curator staff do not access a customer’s tenant except for support or incident response with a legitimate operational reason, and such access is logged.

6. Credential and secret management

• Application secrets are stored in the hosting platform’s encrypted secret store (Fly secrets / Vercel environment variables) and injected at runtime. The repository contains only a committed example file with placeholder values; real values are never committed.
• Customer OAuth grants for third-party providers are held by a dedicated connector broker (Nango) rather than in Curator’s own database, reducing the blast radius of a database compromise. Any API keys Curator does store are encrypted at rest with an application-managed AES-256 key.
• Secret scanning runs against the repository, and pushes containing detected secrets are blocked.
• Secrets are rotated on personnel change, on suspected exposure, and at least annually for long-lived keys.
• Customers may revoke any connector grant at any time from the integrations surface; revocation stops further ingestion for that source.

7. Infrastructure, network, and cryptography

• In transit: TLS 1.2 or higher is required for all external traffic; HTTPS is force-enforced at the gateway. Browser origins are restricted by an explicit CORS allowlist.
• At rest: database, backups, and volume storage are encrypted with AES-256 by the underlying platform providers.
• Segmentation: the frontend, the gateway API, and the database are separate services; the database is not exposed to the public internet except through the managed provider’s authenticated endpoints.
• Agent sandbox: agent-executed code runs in a constrained sandbox with database access limited to the RLS-gated sandbox roles for the calling tenant. The current single-machine deployment shares a kernel between the gateway and the sandbox; this is a known, documented limitation tracked in the risk register with per-session microVM isolation as the planned mitigation. It is disclosed here rather than papered over.
• Availability: the gateway runs a continuous health check and a minimum running instance. Database backups are taken by the managed provider with point-in-time recovery; restore is tested at least annually.
• Business continuity: target RTO 24 hours, RPO 24 hours.

8. Secure development lifecycle

• Branching: production ships only from main, and only via pull request from dev. Direct pushes to main are not permitted.
• Review: every change is peer-reviewed before merge. Reviews cover authorization and tenant scoping on new endpoints, RLS coverage on new tables, and the handling of any Restricted data.
• Automated checks: type checking and the test suite run on the branch before merge; dependency vulnerability alerts are enabled on the repository and triaged by the CTO.
• Fail-loud requirement: the codebase carries an explicit engineering rule that a surface which stops receiving data must fail visibly rather than continue rendering stale results. Silent-failure defects are treated as security-relevant, because a customer acting on stale data is a real harm and an invisible one.
• Change management: production deploys are logged (commit, deployer, time) by the hosting platform. Migrations are versioned and applied through the repository, never ad hoc against production.
• Dependencies: third-party packages are pinned via lockfile and updated on a regular cadence; a vulnerability rated High or Critical in a reachable dependency is remediated per the timelines in §12.
• Penetration testing: an independent application penetration test is performed annually. Findings are entered in the risk register and remediated per the timelines in §12.

9. AI and agent-specific controls

Curator runs LLM-driven agents over customer data, which creates risks a generic policy does not cover:

• Model providers are treated as subprocessors (§11) and are contracted on terms that prohibit training on customer data.
• Prompt injection: content ingested from third-party systems (emails, tickets, web pages, documents) is treated as untrusted data, not as instructions. Agent tools that perform outbound or irreversible actions — sending messages, writing to external systems — are gated behind explicit allowlists and, where appropriate, human-in-the-loop approval.
• Tool scope: agents operate through a defined tool surface with database access constrained to the RLS-gated tenant roles; they do not hold provider credentials directly.
• Data minimization: only the data required for the requested task is assembled into agent context.
• Auditability: agent runs, tool calls, and outbound actions are logged and reviewable per tenant.

10. Logging and monitoring

• Application, sync, and agent-run logs are collected centrally and retained for 90 days.
• Sync failures, failed agent runs, and gateway health-check failures generate alerts to the engineering channel.
• Product analytics and error tracking (PostHog) are used to detect anomalies and user-facing errors.
• Logs must not contain Restricted data. Credentials, tokens, and full request bodies containing personal data are excluded or redacted at the logging boundary.
• The CTO reviews the alerting surface quarterly to confirm that alerts still fire and are still being read.

11. Third parties and subprocessors

A register of subprocessors is maintained by the CTO and includes, at minimum: vendor, purpose, data categories processed, hosting region, and the security assurance relied on (SOC 2 report, ISO 27001 certificate, or a completed security review).

Current subprocessor categories:

Onboarding a new subprocessor requires: documented business need, review of the vendor’s security posture and DPA, CTO approval, and addition to the register. Customers are notified of new subprocessors that process their data in accordance with the DPA.

12. Risk management

The CTO maintains a risk register recording each identified risk with its likelihood, impact, owner, treatment decision (mitigate / accept / transfer / avoid), and target date. It is reviewed quarterly and on any material change — a new subprocessor, a new data category, a new deployment model, or a significant incident.

Risks are identified from: architecture and design review, code review findings, dependency and secret scanning, incident post-mortems, penetration test findings, and customer security questionnaires.

Remediation targets for confirmed vulnerabilities, measured from confirmation:

Any risk accepted rather than mitigated requires a written rationale and founder sign-off, with a re-review date.

13. Incident response

Definition. A security incident is any confirmed or suspected event compromising the confidentiality, integrity, or availability of customer data or Curator systems — including unauthorized access, credential exposure, data loss, tenant isolation failure, or malicious code.

Severity levels

Procedure

1. Report — anyone noticing a suspected incident notifies the CTO within 1 hour. There is no penalty for a false alarm; failing to report is the failure.
2. Triage — the CTO assigns severity and appoints an incident lead.
3. Contain — revoke sessions and credentials, disable the affected path, isolate the affected component. Containment precedes root-cause analysis.
4. Eradicate and recover — remove the cause, restore from a known-good state, verify integrity before restoring service.
5. Notify — affected customers are notified without undue delay and within 72 hours of confirming an incident involving their data, with what happened, what data was affected, what has been done, and what they should do. Regulatory and contractual notification obligations are assessed by the CTO with counsel where applicable.
6. Post-mortem — a written, blameless post-mortem within 5 business days of resolution, with corrective actions tracked to completion in the risk register.

Incident records are retained for at least 3 years.

14. Data lifecycle, retention, and deletion

• Collection is limited to what the connected sources provide and what the product requires.
• Retention: customer business data is retained for the life of the account. Agent session workdirs are expired automatically on a defined TTL. Logs are retained per §10.
• Deletion: on termination, customer data is deleted within 30 days of the request or of contract end, and purged from backups within the backup retention window (30 days). Deletion respects referential order so that no orphaned records survive the process.
• Customer rights: customers may request export or deletion of their data, and Curator responds within the timelines in the applicable DPA. Where the customer is a data controller under GDPR/CCPA, Curator acts as processor and assists with data subject requests.
• Portability: customers can export their data in a machine-readable format on request.

15. Physical security

Curator has no data centers of its own. All production infrastructure is hosted with providers that maintain independently audited physical security controls; their reports are held in the subprocessor register. Personnel work from company-managed, encrypted devices; devices are not left unattended and unlocked in public settings.

16. Policy compliance and exceptions

• Compliance is mandatory. Violations are handled through the normal disciplinary process, up to and including termination and, where warranted, legal action.
• Exceptions require a written request stating the business need, the risk, the compensating control, and an expiry date, approved by the CTO and recorded in the risk register. There are no undocumented exceptions.
• This policy is reviewed and re-approved at least annually. The version history below records each revision.

17. Version history

18. Contact

Questions about this policy, or reports of a suspected vulnerability, go to:

Commerce Intelligence Inc. (d/b/a Curator)
Email: team@curator.to
Website: https://curator.to