Data Handling

Transparency about data handling is essential. Here's exactly what the hosted StarSling product and GitHub App access and how we handle it.

ci-speedup, ci-score, and ci-secure

The ci-speedup skill runs locally through your coding agent and authenticated gh CLI. The ci-score skill runs locally against your checkout; once installed, scoring uses no network access at all. The ci-secure skill runs locally against your workflow files; it calls the GitHub API through your own authenticated gh CLI for four checks, and runs without them if gh is unavailable. None of the three sends your code or CI data to StarSling, and none requires the StarSling GitHub App. Your coding-agent provider's own data policy applies separately.

Data Access Summary

The table separates the ephemeral runner filesystem, data used for analysis, and files your workflows deliberately persist with StarSling Disks. A source file or credential written into a published disk follows the Disks retention policy.

Detailed Breakdown

Repository Metadata

What: Repository name, owner, installation ID

Why: To route webhooks and manage runner registration

Stored: Yes, in our database

Retention: Until you uninstall the GitHub App

Account Email

What: The email addresses on your GitHub account

When: Read when you sign in to StarSling with GitHub

Why: To create your StarSling account, send account email such as the welcome message, and match your GitHub commit author email to your Slack user if you enable pull request notifications

Stored: Yes, in our database

Retention: Until you delete your account

Workflow Events

What: Webhook payloads for workflow_job events

Why: To provision runners when jobs start

Stored: No (processed in memory)

Retention: None

Workflow Definitions (Optimizations)

What: Your .github/workflows/*.yml files

When: Periodically scanned by StarSling's AI agents to identify optimization opportunities

Why: To suggest caching improvements, faster install strategies, build step optimizations, and workflow restructuring

Stored: No (processed in memory during analysis)

Retention: None

Source Code (AI Analysis)

What: Source code files in your repository

When: Accessed for AI-powered optimizations

Why: To provide context for optimization suggestions

Stored: Yes, temporarily during analysis

Retention: Deleted within 24 hours

Workflow Job Logs

What: The console output of workflow jobs that run on StarSling runners — the same log GitHub shows you under the Actions tab

When: Retrieved after a job completes

Why: Log output is where CI time is actually spent. Our optimization agents read it to find stalls, redundant work, and cache misses that job timings alone do not reveal, and to measure whether a proposed change worked

Stored: Yes

Retention: We retain job logs for no longer than 12 months, so analysis can compare a job against your own history. Deleted sooner on request — see Data Deletion

StarSling Disks

What: Files your workflow writes into a mounted disk directory, such as dependency stores, build output, toolchains, datasets, or source files. The workflow chooses what goes into that directory. Credentials or other sensitive files written there can become part of a published disk too.

Why: To reuse filesystem data across jobs without downloading and extracting an archive.

Stored: Yes, as encrypted, immutable layers. A successful default-branch publisher makes its changes available to later authorized jobs of the same repository. Other jobs' writes remain private and are discarded at job end. Failed or cancelled jobs do not publish.

Retention: Published data persists across runner destruction until the disk is deleted or retires. A disk retires after a publication over its size cap, 30 days without a step naming it, or replacement by a new name at its path. Retirement stops new jobs mounting the old contents; an already running job keeps its selected generation until it ends. See Disk lifetime and changes.

Deletion: Deleted Disks data is removed within 48 hours. Account deletion includes all of the account's stored Disks. See Disks deletion to request deletion or offboarding.

Protection: File contents and filenames are encrypted at rest, with a separate key for each immutable layer. See Disks at rest for encryption details.

Repository Activity & Context

What: Read-only repository signals such as deployments, issues, discussions, pages, and code scanning alerts

When: Accessed alongside workflow and source analysis

Why: To give optimization suggestions broader context about your repository

Stored: No (processed in memory during analysis)

Retention: None

How Your Data Is Used

Your job logs and CI history are used for one purpose: producing optimization analysis for your own organization.

• Never pooled across customers. Analysis for your organization runs against your organization's data only, and no other customer's analysis draws on yours. The single exception is aggregate usage counting for billing integrity, which sums job counts across the fleet and reads no log content.
• Never used to train models. StarSling does not train, fine-tune, or otherwise build models on customer data.
• Never sold or shared. Your data is not sold, licensed, or shared with third parties for their own purposes.

Language model providers

Our optimization agents are built on commercial language models, so analysis sends the specific log windows and timings a given analysis needs to that provider's API. Those providers are sub-processors, not recipients of your data for their own use, and we send only what the analysis requires — never a bulk export of your logs. If your security review needs the current provider list and their contractual terms, request it at founders@starsling.dev.

What We Never Access

Secrets

GitHub secrets are passed directly from GitHub to the runner. The GitHub App does not fetch secret values from GitHub. The runner necessarily receives them while the job runs. A workflow that prints a secret to its log or writes it into a published disk can persist that value; those copies follow the destination's retention policy.

Environment Variables

Custom environment variables are injected by GitHub, not StarSling.

Their values can appear in retained logs or Disks if the workflow writes them there.

Build Artifacts

Artifacts uploaded via actions/upload-artifact go directly to GitHub's artifact storage.

Build output deliberately written into a published disk is stored by StarSling under the Disks policy above.

Changes We Make

StarSling's AI agents propose optimizations by opening pull requests. This requires write access to Contents and Workflows, scoped to changes the GitHub App commits on new pull request branches.

What we do:

• Create a new branch and commit proposed changes
• Open a pull request with an explanation for your review

What we don't do:

• Push to your default branch or any existing branch
• Merge or approve pull requests

See GitHub App Permissions for the full list of permissions and why each is requested.

Isolation

Every job runs on its own dedicated, single-use virtual machine. No machine is ever shared between jobs, and no machine is ever shared between customers.

One machine per job. A machine is dedicated to your job when it is queued and destroyed when the job finishes. No machine is ever reused across jobs. Its ephemeral filesystem, processes, and credentials do not pass to a later job.

Disks are an explicit persistence feature: authorized jobs of the same repository can mount and decrypt a specific disk on a new machine with the Disks action. Disks are isolated per namespace within each repository.

Single-use, organization-scoped credentials. Each runner registers with GitHub using a just-in-time token minted for one organization's app installation. The token is single-use, and the runner deregisters itself when it exits. A runner can therefore only ever be assigned work from the organization it was minted for.

A machine boundary between customers. No two customers' jobs ever share a host. On our sandbox providers a CPU job runs in a microVM; on our EC2 fleet a job gets a dedicated instance that terminates when the job ends. In both cases the boundary between two customers is a whole machine, not a container on a shared host.

Being precise about what that does and does not mean: on the EC2 path your job runs in a privileged container on its own dedicated instance, so it shares a kernel with nothing but itself — the container is a packaging boundary, and the instance is the security boundary. Our GPU tiers are container-class on a dedicated machine on the same basis. The claim we make is the machine boundary between customers; we do not claim a microVM boundary on every path.

Disks adds a repository-level data boundary. Each customer organization has a separate logical storage volume. Customer jobs receive decryption keys only after StarSling verifies the exact executing job and its repository using GitHub identity and OIDC. A trusted job receives only the layers it may read for its own repository. Fork pull requests, Dependabot pull requests, and events outside the read allow-list receive no decryption keys. StarSling-managed maintenance services also receive keys to repack storage layers. Shared storage does not give another repository authority to decrypt your files.

Operator Access

No StarSling employee can reach your account data through the application without opening a session that expires and is recorded. Direct access to production infrastructure is a separate, narrower path, described at the end of this section. Two categories are unreachable regardless of role:

• Secrets, credentials, and environment variables — never received by our control plane, so there is no stored copy to grant access to.
• Build artifacts — uploaded by GitHub directly to GitHub's storage.

For everything else, support access is a named, deliberate path rather than a default:

• Administrator rights are granted individually. They are a per-person grant held on the user record. No environment variable, job title, or organization role confers them, and holding an admin role inside your GitHub organization confers nothing on StarSling's side. To be exact about the shape of this: the administrator role itself is standing, held by a small number of people, and an existing administrator can grant it to another employee. What is not standing is reaching your data — that requires opening a support session, and that session is what expires and is audited.
• Support sessions are time-boxed. When an administrator opens a session against an account to resolve a support request, it expires automatically (one hour by default) and can be revoked before then.
• A support session is a real session, not a read-only view. It is granted so an administrator can reproduce and resolve what you are reporting, and it carries the permissions of the account it was opened against. Every request made within it is audited under both identities, which is the control — not a technical restriction to reading.
• Every action is attributable. The session records the administrator behind it, so support activity is never indistinguishable from your own.
• Production infrastructure access requires MFA and is limited to on-call engineers. This is a separate path from the support session above: it is direct access to the systems that store the data, it is not captured as API audit records, and it is governed by the on-call rotation and access review described under Access Control.

Audit Logging

Authenticated requests to the StarSling API write an audit record capturing:

Records are stored independently of the accounts they reference, so removing a user does not erase the history of what was done with that account. Support access is covered by the same trail as ordinary traffic, with both identities — the account viewed and the administrator viewing it — on the record.

On immutability, precisely: the application only ever inserts into this trail — no code path updates or deletes an audit record. That is an application-level guarantee, not a storage-level one; the table does not currently sit behind a database constraint or write-once storage that would stop someone holding production database credentials from altering it. Treat it as a complete record of application activity, not as tamper-proof evidence against an insider with infrastructure access.

The scope of this trail, stated exactly: it covers authenticated requests to the application API. Requests rejected before an identity is established are not recorded as audit rows, and direct infrastructure access by on-call engineers is a separate path governed by Access Control rather than by this trail.

Audit log export is available to Enterprise customers as part of an agreement with us; see Enterprise Security Features.

Data Location

Runner compute runs in multiple regions. See Sandbox Router.

Encryption

In Transit

• All communications use TLS 1.3
• Webhook payloads verified with GitHub signatures
• Runner-to-GitHub communication encrypted

At Rest

• Databases encrypted at rest with managed keys
• Logs encrypted at rest

Disks at rest

Disks use AES-256-XTS for file contents and AES-256-CTS for filenames. Data is encrypted before it is transferred to persistent storage.

What encryption protects: File contents and filenames are encrypted. Filesystem metadata such as sizes, permissions, timestamps, file counts, and directory structure remains visible to infrastructure with access to the encrypted volume.

Encryption at rest does not protect data from code the repository authorizes to run with access to it. Do not publish credentials or sensitive files that later authorized jobs should not read.

StarSling manages these keys. Access to the production systems that hold encrypted data and key material is governed by Operator Access; per-layer encryption does not remove that infrastructure access path.

Data Deletion

Disks deletion

Deleted Disks data is removed within 48 hours. Deleting your account also deletes its stored Disks. Contact support@starsling.dev to arrange deletion or offboarding.

The up-to-48-hour billing delay after deletion describes when daily usage measurements stop charging for deleted storage. It is separate from the deletion process and does not grant a later job access to deleted data.

On Uninstall

When you uninstall the StarSling GitHub App:

1. All runners are immediately deregistered.
2. Disks layer keys are immediately destroyed, and stored Disks data is deleted within 48 hours.
3. Account metadata is deleted within 7 days.

Uninstalling does not delete your retained job logs. They stay under the 12-month window above unless you request their deletion. To remove retained logs or other account data as well, request deletion below.

On Request

Contact support@starsling.dev to request deletion of your job logs, account data, and stored Disks. Disks deletion completes within the 48-hour window above.

The audit trail is the one exception, and deliberately so: the records described under Audit Logging are stored independently of the accounts they reference and are not removed by a deletion request. That is what makes the trail evidence — a log the party it describes can delete cannot answer the question a security review is asking.