Privacy Notice

1. Information we process

When you use Sulcus Cloud, the current implementation processes:

• Authentication and profile information: a Firebase user identifier and, when provided by the authentication flow, an email address and display name. Sulcus also maintains internal user, workspace, membership, role, and timestamp records needed to authorize access.
• Project configuration: project name and description, public repository URL and Git reference, relative Python entrypoint, supported framework, dependency mode, network setting, and timestamps.
• Run information: workspace and Project associations, name, workload configuration snapshot, runner type, lifecycle status, timestamps, token-usage totals or limits when available, and sanitized error information.
• Runtime activity and diagnostics: ordered runtime events and metadata from supported framework and tool integrations, including lifecycle, model/tool, and token-usage activity when surfaced by instrumentation, plus bounded diagnostics needed to show failures.

If you contact support, we receive the information you choose to send in that message.

2. How we use information

Sulcus uses this information to authenticate users, authorize workspace access, operate Sulcus Cloud, create and execute Projects and Runs, display runtime status and history, apply supported runtime controls, validate workload inputs, troubleshoot failures, protect the service, and respond to support requests.

3. Authentication and service providers

The current Cloud implementation uses Firebase Authentication for sign-in and server-side identity verification. The Cloud frontend initializes Firebase App and Auth only; Cloud application state is stored in a Sulcus-owned SQLite database. The implementation reviewed does not initialize Firebase Analytics, Firestore, or Firebase Storage for Cloud application data.

4. Repository and Run data

Sulcus currently accepts public HTTPS Git repositories without credentials in the URL. Private repository authentication is not currently supported. For a Git Run, Sulcus may retrieve the repository content required for the selected reference, prepare dependencies, run the configured relative Python entrypoint, and collect the execution metadata, runtime events, and bounded diagnostics needed to provide the Cloud experience. Project-backed Runs keep a workload snapshot so later Project edits do not rewrite historical Run configuration.

5. Secrets and sensitive values

Optional secret values are supplied per Run for that execution. They are not Project fields and are not persisted as Run records, response fields, or event payloads. Sulcus Cloud does not currently provide a Project Secrets vault or managed secret-storage product. Runtime events and bounded stdout/stderr diagnostics pass through best-effort redaction for supplied values and common credential shapes. Redaction is not guaranteed and cannot prevent a workload from intentionally exfiltrating a value.

6. Data retention

Cloud stores account, workspace, Project, and Run information, together with a bounded event history, as needed to operate the service. Event history is limited to the 5,000 most recent events per Run by default. The current product has no finalized public time-based retention period or automatic deletion schedule; general retention and deletion controls are still evolving. Projects with historical Runs cannot currently be deleted.

7. Security

Sulcus uses authenticated API access, workspace-membership authorization, repository validation, best-effort redaction, and container and resource controls for Cloud executions. Cloud Runs are intended for trusted development repositories; Docker execution is not presented as a hostile-code security sandbox.

8. Your choices and contact

For privacy or support questions, contact support@sulcus.dev.