How we protect your data
This page describes how we secure Kirak Studio and the open-source Kirak runtime. To report a vulnerability, see Reporting a security issue below.
Encryption. Data is encrypted in transit with TLS, and at rest in databases, object storage, and backups.
Where your data lives. Your Kirak Studio account, billing, and platform data is hosted in the UK or EU. Your backend runs on an Instance in the region you choose, currently the US or the EU. See International transfers in our Privacy Policy.
Isolation. Each customer backend runs on a dedicated Instance, isolated at the network and compute level from other customers.
Access to production. Our staff get the least access they need to do their jobs. Administrative access requires multi-factor authentication, access is reviewed regularly, and it is revoked promptly when someone changes role or leaves.
Backups and deletion. We take regular encrypted backups of the platform. When you delete a project or close your account, the data is removed from our active systems, and residual copies in encrypted backups are purged within 30 days.
Secure development. Every change to the open-source runtime goes through code review. Its continuous integration runs a dependency vulnerability audit (pip-audit), static security analysis (bandit), and CodeQL code scanning. The runtime’s source is public, so anyone can inspect how authentication, access rules, and encryption work.
Incident response. We have a documented process for detecting, assessing, and responding to security incidents. If a personal data breach affects your data, we will notify you as set out in our Data Processing Addendum.
Sub-processors. The third parties that process personal data for the Service are listed on our Sub-processors page.
Compliance
SOC 2. Kirak Studio is not SOC 2 certified. The Kirak runtime is built to help the APIs it serves pass a SOC 2 review, with audit logging, access controls, and encryption at rest.
Data protection. We process personal data under UK GDPR. Customers who process personal data in their backends are covered by our Data Processing Addendum, which includes our technical and organisational measures and the safeguards for international transfers.
Health data. Kirak Studio is not HIPAA-eligible. Do not use it to store or process Protected Health Information.
Shared responsibility
Security on Kirak Studio is shared between us and you.
| We are responsible for | You are responsible for |
|---|---|
| The security of the Studio platform and its infrastructure | Your application’s declarations, hooks, and custom endpoints |
| Isolating your Instance from other customers | The access rules you declare for your data |
| Encrypting data in transit and at rest | Who you give access to your Studio account and projects |
| Patching the platform and the Kirak runtime | Keeping your own secrets and provider keys safe |
| Backups of the platform | Your own backups of data you cannot afford to lose |
If you self-host the open-source runtime, you are responsible for the infrastructure you run it on.
Vulnerability disclosure policy
Reporting a security issue
If you believe you’ve found a security vulnerability in Kirak, please report it to security@kirak.io.
Please do not open a public GitHub issue, discussion, or pull request for a suspected vulnerability.
Include as much as you can:
- the component affected (the runtime, a specific module, kirak.io) and the version or commit;
- a description of the issue and its impact;
- clear steps to reproduce, and a proof of concept if you have one;
- any suggested remediation.
Our commitments to you
- We will acknowledge your report, normally within 3 business days.
- We will give you an initial assessment (validity and rough severity), normally within 10 business days.
- We will keep you updated on our progress toward a fix.
- We will credit you in the release notes for the fix, if you would like to be named.
- We will not pursue or support legal action against you for security research carried out in good faith and in line with this policy (see Safe harbour below).
We do not offer monetary rewards at this time.
Scope
In scope
- The Kirak open-source runtime: the
github.com/kirak-io/kirakrepository and the publishedkirakpackage – all modules (auth, core engine, payments, storage, notifications, ai, scheduler, monitoring, mcp). - The Kirak website:
kirak.ioand its subdomains exceptstudio.kirak.io.
Vulnerability classes we’re especially interested in for the runtime: authentication and authorisation bypass (JWT, OAuth2, OTP, password reset), SQL/query injection, path traversal in storage backends, webhook signature verification bypass, privilege escalation via role manipulation, and cryptographic weaknesses (weak algorithms, hardcoded secrets, key derivation).
Out of scope
studio.kirak.ioand the Kirak Studio service. Do not test against production Studio, and do not attempt to access, or actually access, any account, project, instance, database, or data that is not your own.- Applications and backends that customers build and run on Kirak.
- Third-party services, infrastructure, and vendors we rely on (report those to the relevant vendor).
- Findings that require an already-compromised device, a rogue network position (MITM), or physical access.
- Denial of service, volumetric testing, spam, and social engineering of Sizmic staff, users, or vendors.
Safe harbour
If you make a good-faith effort to comply with this policy during your research, we will consider your research to be authorised, we will not initiate or recommend legal action against you (including under the UK Computer Misuse Act 1990, the US Computer Fraud and Abuse Act, or anti-circumvention provisions such as the DMCA), and we will take steps to make known that your actions were authorised if a third party brings a claim against you.
You are expected to:
- test only against your own self-hosted or local installation of the runtime, and against
kirak.io(notstudio.kirak.io); - avoid privacy violations, data destruction, and any degradation of our services or others’;
- stop testing and report immediately if you encounter personal data belonging to anyone, and not access, store, or share more of it than is necessary to demonstrate the issue;
- keep the details of any vulnerability confidential until we have had a reasonable time to fix it (see Coordinated disclosure); and
- comply with all applicable laws.
If in doubt about whether an action is authorised, email security@kirak.io and ask first.
Coordinated disclosure
We ask that you give us a reasonable opportunity to fix an issue before you disclose it publicly. Our default is 90 days from the date you report it, or the date a fix is released, whichever comes first. We are happy to agree a different timeline with you where a fix is complex or an issue is being actively exploited, and we will credit you when we publish.
Once a vulnerability is fixed, we publish a patch release with a changelog entry describing the issue category (not exploit details), and file a GitHub Security Advisory.
What we usually don’t consider actionable
Reports of the following, without a demonstrated security impact, are generally not treated as vulnerabilities: missing security headers or cookie flags; missing SPF/DKIM/DMARC records; self-XSS; clickjacking on pages with no sensitive action; rate-limiting on non-authentication endpoints; disclosure of software versions or public files; output of automated scanners with no proof of concept; and general “best practice” suggestions.
Also out of scope for a report: issues in upstream dependencies (report those to the upstream project), and issues in user-written application code – Kirak is a runtime, not the application built on it.
Supported Versions
| Version | Supported |
|---|---|
| 0.1.x (latest) | Yes |
| < 0.1 | No |
Recognition
With your permission, we credit researchers who have responsibly reported valid issues in the release notes for the fix.
Deploying Kirak securely
This policy covers reporting vulnerabilities in Kirak. If you’re looking for guidance on configuring a Kirak application securely (secrets, password policy, HTTPS, security headers, and more), see Security Hardening in the documentation.
The safe-harbour language is adapted from the disclose.io project’s open templates.