AI, Jira, Forge, and Data Security: Let’s Talk About Apps Builder

[Mariia_Domska_SaaSJet]

Today, Jira teams work in a new reality. Tight deadlines, limited resources, and growing pressure to adopt AI have become almost standard. More and more often, teams hear: “We need to do something with AI”—whether they feel ready or not.

This trend is clearly visible in the Atlassian ecosystem as well. For example, in November, Atlassian launched the AI Hub—a new section of the Atlassian Marketplace dedicated to AI-powered apps. AI Hub already includes 90 add-ons, and this number keeps growing. The signal is clear: demand for AI solutions exists and will continue to increase.

However, for many enterprise teams, the real question is not whether to use AI, but how to use it—and how AI adoption affects data security. This concern becomes especially important when Jira data is involved.

Where Does the Tension Come From?

At SaaSJet, we actively work with AI. We build Rovo agents for our apps, and one of our products is an AI-powered app builder. When we talk to Jira users, we often hear the same concerns:

• “Our company policy does not allow AI tools.”

• “We cannot risk Jira data.”

• “We don’t understand where our data goes.”

These concerns are especially common in enterprise companies—and they are completely valid. Therefore, some companies reject new tools at a very early stage, referring to company policy or a general restriction on AI usage.

That is why this post is an attempt to explain, in a simple and calm way, how data security works with our AI product, No-Code Apps Creator. And also discuss all points with the Atlassian Community.

AI Builder ≠ Data Access

As mentioned earlier, our team built No-Code Apps Creator, an AI-powered platform that helps Jira teams create dashboards, reports, gadgets, and custom apps—without writing code, through chatting with AI. Along with interest, we often face the same blocker: “We can’t use this because it’s AI.”

Here, it is vital to understand two things clearly:

👉 No-Code Apps Creator, as a builder, does not read Jira data
👉 The AI does not analyze issues, comments, worklogs, or users

In practice:

• The LLM does not connect to Jira

• The LLM does not have access to Jira APIs

• The LLM does not receive any real Jira data.

So What Does the AI Actually Do?

In No-Code Apps Creator, AI is used to generate code, not to process data.

What does No-Code Apps Creator do?

• Generates Forge app code

• Uses public Forge documentation

• Describes which types of data are needed (for example: issue key, summary, due date)

• Builds the manifest.yml, UI, and business logic

Key point: The AI works with structure and logic, not with real Jira data.

When Does Jira Data Appear at All?

No-Code Apps Creator generates a Forge app. Only after the app is deployed to a Jira Cloud site does it start receiving Jira data for processing and display. This is the most important part from a security perspective.

How Forge Works with Jira Data

The Forge app runs entirely inside Atlassian Cloud.
✔️ Forge provides several strong guarantees:

• The app runs only in Atlassian infrastructure

• Granular permission scopes are enforced

• Users explicitly grant Allow Access

• Standard Jira permissions apply

• Admins can see all granted permissions

✔️ Jira data:

• Do not leave Atlassian Cloud

• Are not sent to SaaSJet

• Are not sent to the LLM

• Are not sent to third-party services

❌ There are no:

• External servers

• Third-party backends

• Proxies

• Hidden API calls

This means that even the vendor does not have access to real Jira data.

An Important Note About the API Token

Using the No-Code Apps Creator to build a custom Forge app, the user provides an API token during deployment. This often raises questions.

The token is used only for deployment, to:

• Register the Forge app

• Deploy the code to a specific Jira site

The token is not used:

• To read issues

• For runtime data access

• For analytics

After deployment, the token is no longer involved in how the app works.

Why This Matters for Jira Teams

Jira teams often need small but critical customizations: a specific dashboard, a workflow button, or an internal tool. Usually, teams face two options: wait for developers or try to adapt existing marketplace apps that don’t fully fit. AI-powered No-Code Apps Creator offers a third option: build a solution quickly, test a hypothesis, and validate value—without coding and without data risk.

After that, teams can:

• Scale the solution

• Or share the generated code with developers.

Invitation to Discussion

AI in the Atlassian ecosystem is no longer the future—it is the present. At the same time, every company has the right to decide how and under what conditions AI is used.

We would love to hear your perspective:

• Which security requirements are critical in your organization?

• What questions about AI and Jira remain open for you?

Let’s discuss this together. 👇

[Calogero Bonasia]

Thank you for this clear and necessary article. The issue you raise aligns perfectly with what I observe daily in my work with enterprise organizations.

I have been a consultant for over twenty years on Jira and Confluence, and I've had the opportunity to experience these dynamics firsthand across various sectors – luxury, banking, aerospace, public administration – and I can confirm that resistance to adopting AI tools almost never stems from technological ignorance, but from legitimate concerns about data governance.

Your central point is crucial: distinguishing between "building with AI" and "giving AI access to data." In the case of No-Code Apps Creator, the AI generates code based on public Forge documentation, never accessing actual Jira data. This is a distinction that corporate policies often fail to grasp, because they tend to treat "AI" as a monolithic category.

What I find particularly relevant is the role of the Forge architecture in this scenario. The fact that the generated app runs entirely within Atlassian Cloud infrastructure, with no external servers, third-party backends, or hidden API calls, answers one of the most recurring questions I receive from CISOs: "where does our data end up?"

An open question: how do you document the code generation process to allow for internal audits? Many enterprise organizations require complete traceability, even for automatically generated code.

Ultimately, I see No-Code Apps Creator as a sensible response to a real problem: the need for rapid customizations without compromising security. The real obstacle remains effectively communicating this architecture to non-technical decision-makers.

[Mariia_Domska_SaaSJet]

Hi, @Calogero Bonasia 

Thank you for sharing your experience and expertise. Your comment is very valuable to my team and me. You are right about the need to clearly separate “building with AI” from “giving AI access to data.” This difference is often missed at the policy or decision-making level, even though it is critical for security and compliance.

About your question on documentation and audits: when users ask for materials to support internal reviews or audits, we are always ready to help and provide the needed explanations and artifacts. Your feedback has also started internal discussions for us. We are now looking at ways to make the code generation process and architectural guarantees more visible and easier to understand.

Your point about communicating this clearly to non-technical stakeholders is especially important, and it is something we need to keep working on. Thank you again for taking the time to share your thoughts so clearly. Feedback like this truly helps us improve the product.