Sign-in
Sulcus Cloud uses Firebase Authentication for Google, GitHub and email sign-in, and verifies identity on the server for every API request.
Security
Security and data handling.
How Sulcus Cloud controls access, runs your code, handles secrets and limits what it collects — and where the current limits are.
Workspace-scoped access
Every project, run and live stream is checked against your workspace.
Resource-limited containers
Each run gets its own container with fixed CPU, memory and time.
Secrets per run
Supplied when a run starts and not stored with it.
No conversation content
No prompts, model outputs or tool payloads are captured.
Access
Accounts and workspaces.
Workspace isolation
Projects and runs belong to a workspace. Reading a project, starting or stopping a run and opening a live event stream all require workspace membership, checked on the server. Unknown and unauthorized IDs return the same not-found response.
Roles
Team invitations and role-based access control aren’t available. Workspace members currently have the same run permissions.
Execution
How your code runs.
A resource-limited Docker container
Each Cloud run executes in its own container with fixed CPU, memory, process and time limits, a read-only root filesystem and a temporary working directory. Runs get outbound network access so your app can reach model providers.
A fixed kind of workload
The API accepts a validated public HTTPS repository, Git reference, Python entrypoint and framework. It doesn’t accept arbitrary Docker images, commands, host paths, flags or network names.
Trusted code only
The container restricts resources and filesystem access, but it isn’t a security sandbox for hostile code. Sulcus Cloud is intended for trusted development workloads: run repositories you trust.
Secrets
Runtime secrets.
Supplied per run, not stored
You add API keys and other secrets when you start a run, and your app reads them as environment variables. They aren’t saved with the project, the run record or its events.
Best-effort redaction
Runtime events and failure diagnostics are redacted for the secret values you supply and for common credential patterns. Redaction can’t catch everything, and it can’t stop your own code from sending a secret somewhere else.
No managed secret storage
Sulcus doesn’t offer a secret vault or rotation today. Enter secrets again for each run.
Data collected
Behavior, not content.
Recorded for each run
- Status, timestamps, outcome and duration
- Workflow steps, and which model and tool calls ran
- Reported token counts and your token limit
- Redacted logs and failure diagnostics
- Resolved commit and configuration snapshot
Event history is kept for the most recent 5,000 events per run.
Not captured
- Prompts
- Model outputs
- Tool inputs and outputs
- Runtime secret values
Developer Preview
Local Codex and Claude Code.
Privacy-reduced telemetry
The Sulcus CLI reads your prompt locally and doesn’t send it to Cloud. Command output, file diffs, model reasoning and your local environment stay on your machine. What leaves is session lifecycle and tool activity, such as which commands ran and which file paths changed, redacted before upload.
Device sign-in
You link the CLI to your account by approving the device in Sulcus Cloud. Signing out revokes the device on the server and removes the stored credential from your machine.
Observation only
Sulcus Cloud can’t stop a local session or approve or deny its actions. Codex and Claude Code keep their own permission and sandbox settings.
Reporting
Found a security issue?
Email support@sulcus.dev with details and steps to reproduce.
This page describes how Sulcus works today. It isn’t a certification or a contractual guarantee.