Security & Trust Center
Kraken is built to meet the security and compliance requirements of enterprise engineering teams. This page documents how we handle your data, protect credentials, and ensure that Kraken never acts without appropriate oversight.
Last reviewed: June 2026 · Questions? [email protected]
Human-in-the-loop design
Kraken's most important security property is architectural: no irreversible or sensitive action happens without explicit human approval. Every action is classified before execution:
| Category | Examples | Execution path |
|---|---|---|
| Auto-execute | Add user to project, create custom field, move issue to sprint | Executes immediately. Comment posted on Jira ticket confirming action and outcome. |
| Requires approval | Delete project, remove all users, change permission schemes, bulk transitions | Staged. Admin receives signed approval link via Jira comment. Nothing runs until explicitly approved. |
Approval links are time-limited and signed with HMAC-SHA256. They cannot be forged, replayed after expiry, or approved by anyone who does not hold the link.
Encryption & transport security
All traffic is served over HTTPS (TLS 1.2+). Cloudflare enforces HTTPS; HTTP requests redirect automatically.
API tokens and webhook secrets are stored as server-side environment variables. They are never stored in the database, source control, or client responses.
Passwords are hashed with bcrypt (cost 12). Plain-text passwords are never stored or logged.
JWT session tokens are stored in HTTP-only cookies to prevent JavaScript access and XSS token theft.
Authentication & access control
Kraken supports two authentication methods:
- Email/password — bcrypt-hashed, JWT sessions, rate-limited login endpoint (10 attempts/15 min)
- Atlassian OAuth 2.0 (3LO) — users authenticate via their Atlassian account. Tokens are refreshed automatically before expiry.
Role-based access control is enforced on every route. Admin capabilities require the is_admin role. Standard users can only access data scoped to their own account. The admin panel is inaccessible to non-admins regardless of URL manipulation.
Credential handling
Jira API tokens and OAuth tokens are never:
- Stored in the database in plain text
- Returned to the client in API responses (masked values only:
sk••••1234) - Committed to source control
- Logged in application logs
- Transmitted to the AI model during ticket analysis
Tenant isolation
Every data object — Jira instances, decisions, playbook rules, users, and pending actions — is scoped to a user_id in the database. All queries are parameterized and include a hard filter on the authenticated user's ID. There is no mechanism by which a logged-in user can access another user's data.
Webhook & API security
Each Jira instance has its own randomly-generated webhook secret (256-bit). Inbound webhooks are rejected if the secret does not match.
Webhook, login, and all API routes are rate-limited by IP. HTTP 429 is returned on breach.
Webhook events are deduplicated by issue key and timestamp to prevent double-execution.
OAuth-registered webhooks are automatically refreshed before Atlassian's 30-day expiry with proactive alerts.
Audit logging
Every action is recorded in the decisions table with: ticket key, instance ID, action category, full action list with descriptions, per-action execution results, approval status, AI confidence score, and UTC timestamp. The full log is viewable in the dashboard and exportable. Logs are retained for the lifetime of the account.
AI data handling
Kraken uses Anthropic's Claude API. The following is transmitted per ticket: issue summary, description (text only), reporter display name, current status, and existing comments.
The following is never transmitted to Anthropic: Jira API tokens, OAuth tokens, webhook secrets, session tokens, passwords, or data from other tenants.
Enterprise customers may request a Data Processing Addendum covering this data flow. Contact [email protected].
Infrastructure & hosting
- Hosting: Dedicated VPS (Hetzner) behind Cloudflare's global network with DDoS mitigation
- Process management: PM2 with auto-restart, graceful zero-downtime reloads, and smoke-test-gated deploys with automatic rollback
- Database: SQLite with file-system permissions restricted to the application user
- Deploy pipeline: GitHub push → deploy watcher detects → smoke test gate → graceful reload. Failed tests roll back automatically.
- Source code: Private GitHub repository. Secrets are never committed.
Incident response
In the event of a confirmed security incident: affected accounts notified within 72 hours; compromised sessions invalidated immediately; postmortem published within 30 days for data-affecting incidents. To report a suspected incident: [email protected].
Compliance posture
| Standard | Status | Notes |
|---|---|---|
| GDPR | In progress | Privacy policy published. DPA available for Enterprise on request. Deletion rights supported. |
| CCPA | In progress | Privacy policy covers CCPA. No sale of personal data. |
| SOC 2 Type II | Planned | Controls and policies being put in place to support future audit. |
| ISO 27001 | Planned | Information security practices align with ISO 27001 principles. |
| HIPAA | N/A | Kraken does not process Protected Health Information. |
| PCI DSS | N/A | Payments via Stripe. Kraken does not store cardholder data. |
Vulnerability disclosure
Found a security issue? Email [email protected] with a description, reproduction steps, and any PoC. We acknowledge within 2 business days and aim to resolve confirmed issues within 30 days. Please do not publicly disclose until we've addressed the issue.