You're about to hand over a Jira admin token. Here's exactly what happens to it.

Your Jira API token is encrypted at rest with AES-256-GCM — an authenticated cipher, so tampering with the stored ciphertext is detected, not just hidden. Each encryption uses a fresh random nonce.

The encryption key isn't shared across users. It's derived per-account from the server's master key via HKDF-SHA256, so the master key itself is never used to encrypt your data directly, and one account's derived key can't decrypt another account's blob.

When you connect, you can also choose "session-only": your token never enters our database. It stays in your browser — encrypted at rest with AES-GCM under a non-extractable key held in your browser's own key store, decrypted only into page memory — and is sent to the server with each request that needs it. The server uses it for that one request and never writes it to disk. Closing the tab or ending the session clears it. Uncheck "save token securely" on the connect form to use it.

This choice is available on every plan, including Free: save the token securely so it persists across sessions, or keep it session-only and re-enter it each login.

The admin assistant defaults to Plan mode: it can read your configuration, but every proposed change is written out as a plan for you to review first. It cannot write to Jira in Plan mode — that's enforced in server code, not left to the AI to decide.

Switching to Execute only runs the specific plan you approved. If the assistant tries to run a change that wasn't part of what you approved, the server rejects it before it reaches Jira, independent of anything the model itself intends to do. Execute mode is also one-shot: once a run finishes, the app automatically drops back to Plan mode, so a later, unrelated conversation can't inherit a stale "yes, go ahead."

• Argon2id password hashing (the current OWASP-recommended algorithm — memory-hard and deliberately slow to brute-force), never plaintext.
• Login timing doesn't leak whether an email is registered: a failed login against an unknown address spends the same computation as a real password check.
• An account locks itself out for 15 minutes after 5 failed login attempts.
• Sessions use a short-lived JWT access token plus a separate refresh token stored in an httpOnly cookie — invisible to page JavaScript, so it can't be read by an injected script.

Login, registration, credential, and AI-agent endpoints are all rate-limited server-side (keyed to your account when signed in, to your IP otherwise), to blunt credential-stuffing and scraping attempts.

Checkout runs through Paddle, the merchant of record: card details are entered into Paddle-hosted fields, so card numbers never reach our code or our database. What we store is your subscription status and payment outcomes — nothing more. Invoices and payment records live with Paddle.