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

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

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. StarSling's infrastructure never sees secret values.

Environment Variables

Custom environment variables are injected by GitHub, not StarSling.

Build Artifacts

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

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, so no job inherits a filesystem, an image cache, a process, or a credential from an earlier one — including from a fork pull request. (We keep a pool of pre-built, stopped machines so a job does not wait on a cold boot; an instance is claimed from it for exactly one job and destroyed afterwards, never returned to the pool.)

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.

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

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

Data Deletion

On Uninstall

When you uninstall the StarSling GitHub App:

1. All runners immediately deregistered
2. Account metadata deleted (within 7 days)
3. No backups retained

Uninstalling does not delete your retained job logs. They stay under the 12-month window above unless you ask for them. If your intent in uninstalling is to have your data removed, say so — see below.

On Request

Contact support@starsling.dev to request immediate deletion of your job logs and account data.

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.