Security Policy

01 Platform & infrastructure security

TextToJQL runs entirely on Atlassian's Forge platform. We don't operate, patch, or manage any servers, databases, or hosting infrastructure of our own — every part of the app executes inside Atlassian's own cloud, under Atlassian's infrastructure security, encryption, and monitoring commitments. There is no separate backend, VPS, or third-party hosting provider in the picture for an attacker to target. Data at rest is encrypted by the Forge platform itself, and all traffic between your Jira site and the app runs over Atlassian's own HTTPS-secured channels.

02 Least-privilege access

The app requests only the specific Jira Cloud permissions each feature genuinely needs, nothing broader:

• read:jira-work — to validate generated JQL against your site's own search parser and to read your site's custom field list.
• storage:app — to cache the custom-field mapping, one per-user tab preference, and a brief per-user request timestamp used for rate limiting.
• read:jira-user — to confirm, in real time and acting as the person themselves rather than as the app, whether they hold Jira's "Administer Jira" permission (gating "Refresh field cache") or have their own visibility into a query's results (gating JQL validation).

The app never requests, collects, or stores your Atlassian password, API tokens, or any other authentication credential — all access to your Jira data happens through Forge's own managed authentication, on your behalf, at the time of each request.

03 Tenant isolation

TextToJQL is installed independently on each Jira site that uses it. Every piece of cached data — the custom-field mapping, per-user preferences, per-user rate-limit timestamps — is scoped to that individual installation by the Forge platform itself. Nothing cached for one Jira site is ever readable from a different site's installation of the app.

04 How the app is built

• No third-party AI vendor. Natural-language requests are sent only to Atlassian's own Forge-hosted AI model. They never leave Atlassian's infrastructure to reach an external AI provider.
• Every generated query is validated as you, not trusted blindly. Before any JQL is shown to a user, it's checked against your Jira site's own JQL parser (/rest/api/3/jql/parse, in strict-validation mode) using Forge's asUser() API — running as that specific person, not as the app. This means the check reflects that person's own Jira permissions, not a broader view the app itself might otherwise have.
• Abuse and cost guards. Requests are capped at 500 characters, and each signed-in user is limited to roughly one request every few seconds. These are cost and abuse guards rather than access-control boundaries — they govern how fast one user can spend LLM calls, not what data anyone can see.
• No debug data left behind in production. Diagnostic logging used during development is stripped before release; nothing sensitive is written to logs in normal operation.
• Dependencies tracked deliberately. The app is built against stable, published releases of Atlassian's own @forge/bridge and @forge/react libraries, not prerelease builds, to avoid inheriting unvetted changes.
• Uninstall cleans up after itself. Removing the app triggers automatic deletion of that site's cached field mapping and every user's saved preference — nothing lingers after uninstall.

05 Compliance

TextToJQL is built to Atlassian's baseline security requirements for cloud Marketplace apps, and operates under Atlassian's Forge Data Processing Addendum. Because the app runs entirely on Atlassian-hosted compute and storage with no data egress to infrastructure of our own, it qualifies for Atlassian's Runs on Atlassian program.

06 Reporting a security issue

If you believe you've found a security vulnerability in TextToJQL, please report it to us privately rather than opening a public issue or discussing it publicly, so we have a chance to investigate and fix it first.

We aim to acknowledge reports within 2 business days. Please include as much detail as you can — steps to reproduce, the Jira site/app version involved, and the potential impact — so we can investigate quickly. We don't currently run a formal paid bug bounty program, but we take every genuine report seriously and will keep you informed as we work through it.

07 Incident response

If a security incident is ever found to have affected customer data, we will notify affected Jira site administrators without undue delay, alongside meeting any notification obligations Atlassian itself has as the platform operator.

We may update this policy from time to time as the app evolves. Material changes will be reflected in the "Last updated" date above.