legal / security

how sneka handles your data.

last updated: 2026-05-22

Sneka AB takes security seriously. This page describes how we think about security, the high-level commitments we make to Private Preview customers, the responsibilities you keep, and the responsibilities that sit with third parties whose services participate in the experience.

This page is a plain-language summary of practice, not a technical specification. We deliberately do not publish implementation details — that lets us evolve our controls without rewriting our promises, and it keeps detail that would help an attacker out of public view. If you need something more specific for a security review, contact us using the details at the bottom of this page.

1. Our approach

Sneka's security posture is built on a small number of principles. We return to them when we make trade-offs between speed, cost, and risk:

  • Security is not an SLA-eligible feature. Section 2 of the Terms of Service makes clear that uptime, multi-node resilience, and multi-site resilience are best-effort during the Private Preview. Security is explicitly carved out of that disclaimer. We treat security regressions as launch-blocking, even when they would not block a functional release.
  • Least privilege, everywhere. Each Sneka service runs under its own identity, holds only the secrets it needs, and can only reach the systems it must reach. A compromise in one service does not hand an attacker access to the others.
  • Encrypt by default, in transit and at rest. Connections between customers and Sneka, and between Sneka services, are encrypted. Long-lived credentials and customer data are protected at rest using modern, widely-reviewed cryptography. We do not store production secrets in plaintext on disk.
  • Boring identity. We do not run our own password database. Customers authenticate through established identity providers (currently GitHub; others as we add them) and Sneka brokers those identities through its own OIDC service. This pushes the most attacked surface — credential storage and reset — onto providers that specialise in it.
  • Defence in depth. We assume any one control will eventually fail and layer controls so that no single failure exposes customer data. That includes network segmentation, restricted operator access paths, encrypted bundles, narrowly-scoped service identities, and audit logging.
  • Investigate, do not paper over. We monitor for fraudulent, abusive, or anomalous use of the Service, and we investigate rather than rate-limit-and-ignore. The Terms reserve our right to suspend access while an investigation is ongoing.

2. What we commit to

The commitments in this section are intentionally phrased at the level of what a customer can rely on, not how it is implemented. Implementation will change over time; these commitments will not regress without notice.

2.1 Transport security

All connections between Sneka services and the public internet — web, API, and Git access — are served over TLS using current, industry-accepted cipher suites. We do not accept unencrypted connections on production endpoints, and we do not downgrade.

2.2 No plaintext secrets at rest

Production credentials and other long-lived secrets used by Sneka are encrypted at rest using modern public-key cryptography. The decryption material lives on a separate, dedicated control surface that does not run customer workloads. Backups of secret material are encrypted before they leave the system that produced them.

2.3 Customer data protection

Customer data we operate on is encrypted at rest on the underlying storage layer and in transit between Sneka services. Access to customer data inside Sneka is restricted to the service that owns it and to narrowly-scoped operator pathways used for support and incident response. We log operator access for after-the-fact review.

2.4 Identity and authentication

Sneka authenticates customers through established external identity providers (today: GitHub; additional providers are added on a case-by-case basis). Sneka does not store, transmit, or have access to your identity-provider password. We rely on tokens issued by those providers, which we treat as sensitive credentials.

2.5 Service isolation

Each Sneka product runs as its own service identity with its own database, its own secrets, and its own runtime files. A compromise of one service does not, by design, expose the data or credentials of another.

2.6 Operator access

Production systems are reached through a restricted operator path with keyed authentication. We treat operator access as a privileged operation: keys are scoped, rotated, and revocable, and routine work does not run as a superuser. We do not permit interactive production access from unmanaged devices.

2.7 Active security tracking

We maintain an internal log of open security work items and address them on a priority basis. Items that materially change the security posture described on this page are completed before the change ships. As part of this, automated checks run in our build pipeline to surface known vulnerabilities and security advisories in the third-party software we depend on, so they are caught before a release rather than after.

2.8 Supply-chain and dependency integrity

Modern software is assembled from many third-party components, and the way those components are pulled in is itself a target. We take a deliberate, conservative approach:

  • We pin our dependencies. Every third-party component we build on is locked to an exact, recorded version, and our builds are produced from those committed records. This makes our builds reproducible and makes any unexpected change to what we ship easy to detect.
  • We wait before adopting brand-new releases. Rather than pulling in a third-party package the moment it is published, we apply a cooldown window before a new release is eligible to enter our builds. Compromised or hijacked package releases are most often caught and pulled in the first days after they appear; the delay reduces our exposure to them.
  • We scan for known issues. As described in Section 2.7, our build pipeline automatically checks our dependencies against published vulnerability and advisory data, so problems in components we rely on are surfaced before they reach you.

2.9 Incident handling and disclosure

If we identify a security incident that affects your data or access, we will inform you in a timely manner, in line with applicable law. We welcome reports from researchers and customers — see Section 6.

2.10 Backups and recovery

Customer-impacting state (databases, repositories, audit material) is backed up to storage independent of the system that produced it. Backups are encrypted, retained according to internal retention policy, and periodically test-restored. Backup capability is held to the same encryption standard as live data.

Important: as called out in the Terms of Service, the Private Preview does not offer a recovery point or recovery time objective. We do not guarantee that any specific item of customer data can be recovered after loss. Section 2.10 describes the controls we maintain; it does not promise an outcome.

2.11 Data retention for the preview waitlist

When you sign up for the Sneka preview at sneka.ai, we store your email address, the confirmation timestamp, and your Sneka account admit state. We use this data only to (a) send you the confirmation magic link and account access notice, and (b) remember that you accepted the Private Preview Terms.

  • Active rows (you signed up but the preview has not closed) are kept for the duration of the Private Preview window.
  • Inactive rows (unconfirmed signups older than 30 days, or admits revoked more than 18 months ago) are anonymized: the email column is replaced with redacted:<sha256-prefix> and any free-text metadata is dropped. We retain the anonymized row so audit logs remain referentially intact.
  • You can request immediate erasure by emailing unsubscribe@sneka.ai from the address on the waitlist. We will delete the row (not just anonymize it) within 30 days and confirm by reply.

Every transactional email we send during the preview — confirmation, admit notice, launch blast — carries an unsubscribe@sneka.ai footer link so the request path is one click away.

3. What you're responsible for

Security is a partnership. Even the best-secured platform leaks if the account that signs into it has a weak password. The Private Preview relies on you to take care of the things that sit on your side of the boundary.

3.1 Your identity-provider account

Because Sneka authenticates you through an external identity provider (today GitHub, others over time), the security of your Sneka account depends on the security of your IdP account. You are responsible for:

  • choosing a strong, unique password at your identity provider;
  • enabling two-factor authentication on that account (we strongly recommend a hardware key or an authenticator app, not SMS);
  • promptly revoking access for compromised or unused devices and sessions;
  • keeping the email account associated with your IdP secure, since it is typically the recovery channel.

3.2 Your devices

Sneka cannot defend against a compromised endpoint. You are responsible for:

  • keeping the operating system and browser on the devices you use to access Sneka up to date;
  • not sharing logged-in sessions with other people;
  • running your own endpoint protection appropriate to your risk profile.

3.3 What you submit to Sneka

You are responsible for the lawfulness and appropriateness of the content and code you submit to the Service, and for the consequences of submitting it. Specifically:

  • do not put third-party secrets, API keys, or production credentials into source you submit unless you understand the access implications;
  • do not submit personal data that you are not entitled to process;
  • treat the Preview environment as you would any external SaaS — assume data you submit may be processed by automated systems for the purpose of delivering the Service.

3.4 Tokens and credentials you connect

If you authorise Sneka to act on your behalf against another system (for example a Git host or a downstream service), you are responsible for:

  • granting the minimum scope required for the task;
  • reviewing and revoking those grants periodically;
  • rotating any token you believe may have been exposed.

3.5 Telling us when something looks wrong

If you see activity on your Sneka account, your linked identity provider, or your connected services that you did not initiate, tell us. Early notice is by far the most valuable input we can receive. See Section 6.

4. What third parties are responsible for

A modern stack is never one company's stack. Several third parties participate in delivering Sneka, and their security posture is, in general, out of our control. We pick providers we believe behave responsibly, but we do not, and cannot, vouch for them.

4.1 Identity providers (GitHub, and others over time)

Authentication for the Preview is brokered through external identity providers. The provider is responsible for:

  • storing and protecting your password;
  • enforcing 2FA and other account-protection features;
  • issuing and revoking the tokens Sneka receives;
  • communicating with you when your account is at risk.

A compromise of your identity-provider account is, in practical terms, a compromise of your Sneka access. We can revoke tokens on our side and sever an active session, but we cannot retroactively secure an account whose primary credentials sit elsewhere.

4.2 Source-code hosts and other systems you connect

If you connect Sneka to a third-party system — for instance a source-code host you grant repository access to — that system's security, access controls, and audit logs are its own. Sneka acts within the scope you granted; it cannot enforce policy inside the third-party system.

4.3 Email and notification providers

Notifications, password-reset flows on third-party providers, and out-of-band communications travel through email and similar transports operated by other companies. Their availability and the integrity of their delivery are outside our control.

4.4 Underlying infrastructure

Sneka runs on third-party cloud infrastructure. The physical security of data centres, network reachability between regions, and the integrity of the host hypervisor are the responsibility of those providers. We mitigate that exposure through encryption, segmentation, and backups that are independent of any single provider, but we do not own those layers and do not warrant them.

5. What the Preview does not include

To stay honest about what you are getting, the Private Preview does not currently offer:

  • a published Service Organization Control (SOC), ISO 27001, or equivalent third-party audit report;
  • customer-managed encryption keys (CMEK) or per-customer key isolation;
  • per-customer network isolation (dedicated VPC, private link, or similar);
  • guaranteed data residency in a specific jurisdiction;
  • contractual recovery-point or recovery-time objectives;
  • subprocessor lists, DPAs, or BAAs as a self-service feature.

Some of these may be added as Sneka matures. None are committed to here. If you need any of them now, talk to us — we may be able to address specific requirements on a case-by-case basis as part of the Preview relationship.

6. Reporting a security issue

If you believe you have found a security vulnerability in Sneka, or that your account or data has been compromised, please contact us as soon as possible:

Please include enough detail that we can reproduce the issue, and please give us a reasonable opportunity to investigate and remediate before publishing. We do not currently operate a paid bug bounty programme, but we acknowledge external reports and credit researchers who would like to be named.

We commit to:

  • acknowledging your report within a small number of business days;
  • keeping you informed of progress at a level appropriate to the sensitivity of the issue;
  • not pursuing legal action against good-faith security researchers who follow this process and do not access or exfiltrate customer data beyond what is necessary to demonstrate the issue.

7. Changes to this page

We will update this page as our security posture evolves. Material changes will be communicated through the same channels we use for product updates. The "Last updated" date at the top reflects the most recent revision.

Sneka AB · Private Preview · security page draft, subject to legal review.