Tenant isolation
- Every workspace is a tenant. The API layer filters every row by the tenant in your signed session.
- Every table carries the tenant key, and links between tables include it, so a row can never point at another workspace’s data.
- Tenant isolation is tested in CI against a real database with tokens for different tenants and roles.
Identity and sessions
- Sign-in is GitHub App user authorization, protected by a signed, HttpOnly state cookie.
- Sessions are signed tokens scoped to one workspace and one role, verified with a public key.
- Sessions last 15 minutes and renew through a rotating HttpOnly cookie. Replaying an old refresh token ends that session.
- The callback hands the app a 60-second one-time code. A session token never appears in a URL.
- Workspaces are created only after GitHub confirms both the install and that you are an active org admin.
GitHub access
- Read-only permissions: Metadata, Pull requests, Contents (to list commits), org Members, Deployments and Actions (workflow-run metadata).
- DevGlimpse never fetches file contents or diffs.
- All sync runs on short-lived installation tokens. Your personal token is used once at sign-in and never stored.
- Webhooks are signature-verified before anything is queued.
Other sources
- GitLab, Bitbucket, trackers and incident tools connect with an access token or OAuth grant you provide. It is stored encrypted under your workspace’s key.
- GitLab reports no line counts, so a merge request’s diff is read once to count added and removed lines. Only those two numbers are kept.
- No source code, file contents or diffs are stored from any source.
The data we keep
- Repositories, pull requests (titles, states, timestamps, sizes), reviews and review comments.
- Commit metadata: author, date, message and line counts.
- GitHub teams, org membership and your custom groups.
- From the other sources you connect: deployments, CI runs, tickets and incidents.
- AI tool usage, through an allowlist of fields. Anything the receiver does not recognise is dropped.
- Daily metric rollups computed from the above, plus workspace settings and an audit log.
Control and lifecycle
- Export contributors, pull requests, reviews and rollups as JSON at any time.
- Export or erase one person’s data on request.
- Delete the whole workspace immediately from the admin console.
- Uninstalling puts the workspace in read-only mode with a visible deletion date 30 days out; the nightly sweep then removes it for good.
- An append-only audit log records privileged actions; the database refuses edits to it.
- Stored credentials and export files are encrypted under a key that belongs to one workspace, destroyed on deletion.
- Sign out of one device or every device at once.
- Restrict access to your own IP ranges with a workspace allowlist, included by plan.
- KubeAce support can read a workspace only inside a time-boxed window an org admin grants.
On the roadmap Enterprise controls, next.
Specified and queued. Need one of these to start? Tell us and it moves up.
- SSO with OIDC and SAML, and enforced SSO
- SCIM user and group provisioning
- External penetration test, SOC 2 Type 2 and a trust page
- EU data residency and a self-hosted option
Where your data is stored
Our data-location statement is being finalised and will be published here. Until then, the
sub-processor list names every provider that stores or processes workspace data.
Found a vulnerability? Email [email protected]. We respond to
every report.
View our sub-processor list and receive change notifications.