AISeptember 7, 2026·9 min read

Bring Your Own LLM: Why the Model Behind Your AI Should Be Your Decision

Almost every app on the Atlassian Marketplace is gaining an AI feature right now. Almost all of them follow the same pattern: the vendor picks the model, runs a server of its own in between and bakes the usage into the price. For organisations bound by an ISMS, the GDPR, NIS2 or DORA that is a problem, because they are accountable for a data flow they neither chose nor control. Bring Your Own LLM turns that relationship around.

What “bring your own LLM” actually means

In a BYO-LLM approach the app provides the interface, the tools and the permission logic, but not the model. The language model is a piece of configuration: an address, an API key and a list of allowed model names. It can be an OpenAI-compatible service (LiteLLM, OpenRouter, Groq, DeepSeek, Mistral), Azure OpenAI, Anthropic, or a self-hosted open-weight model in your own data centre. In anyLLM, administrators register up to five such connections with up to 20 models each; users simply pick from that list in the chat.

The difference from the usual pattern is not a detail. It changes who sits in the data path, who your contractual counterpart is, and who decides when the model market shifts again, as it currently does every few months.

Comparison of two data paths: with a vendor-hosted AI app, prompts travel from Atlassian through the app vendor's server to a model provider chosen by the vendor. With Bring Your Own LLM, prompts go from the Atlassian infrastructure straight to the endpoint approved by the customer. — Figure 1: One hop fewer. With BYO-LLM no vendor server sits between Atlassian and the model. Prompts reach only the address your administrators have approved.

Governance: the model is a decision, not a default

Governance starts with a simple question: who decided this? With bundled AI the answer is “the vendor, at some point, in a release”. With BYO-LLM it is “our Jira administrator, on this date, for this address”. anyLLM reaches no external address that has not been approved explicitly, the well-known providers included. There is no pre-approved list; every address goes through Atlassian's confirmation dialog, separately for Jira and for Confluence. The Endpoint approvals page is therefore also the complete, auditable register of every destination data can flow to.

The same logic protects against lock-in. Switching providers is not a migration but a new connection: enter the address, store the key, maintain the model names, approve. Because the app hard-wires no provider in its manifest, a new provider needs neither an app update nor a fresh consent round across all users. And because usage is visible per model and administrators can cap requests per person and hour, the cost side stays under control too, on the contract you already have, whether that is an Azure enterprise agreement or an EU provider with a data processing agreement.

Security: fewer parties, shorter path

Every additional party in the data path is an additional attack surface and one more place where keys and content can live. BYO-LLM shortens the path to two stations: the Atlassian infrastructure the app runs on, and the endpoint you chose. API keys are stored encrypted in the Atlassian Forge secret store, never reach the browser and do not appear in logs; even an administrator can only replace or delete a key, never read it.

Equally important is what the AI is allowed to do inside Jira and Confluence. It searches and reads exclusively with the permissions of the signed-in person. There is no elevated mode, and the app requests no admin scopes. Write actions such as creating an issue, a comment or a page can only be proposed; they run after a click, with that person's rights and in their name. Content the AI reads from pages or issues is handed to the model as plain data, and external images are never loaded automatically, two measures against prompt injection and silent exfiltration. The app itself exposes no endpoint reachable from the outside.

Flow of a request with four control points: the user's permissions when reading Jira and Confluence, endpoint approval by the administrator, the API key from the secret store, and the user's confirmation before any write action. — Figure 2: Four control points along the path of a request. Three of them apply before a prompt leaves the Atlassian infrastructure; the fourth applies before anything is written to Jira or Confluence.

Compliance: contracts you can actually sign

The GDPR requires you to know, contractually bind and audit every processor (Art. 28). With bundled AI the model provider is a sub-processor inside the app vendor's chain: you learn who it is from a list, and you hold no direct contract. With BYO-LLM the model provider is your own processor: you hold the data processing agreement, you pick the region, you decide whether training on your data is excluded. The app's sub-processor list then equals your configuration.

Data residency works the same way. Everything anyLLM stores, conversations, agents and settings, lives in Forge storage and therefore follows the data residency of your Atlassian site in one of eleven regions, Germany and the EU among them. The only thing that leaves storage is the prompt to the endpoint of your choice; a self-hosted model in Frankfurt keeps that part in the country as well. Closed Atlassian accounts are cleaned up automatically every week (Art. 17), temporary chats are never stored, and maplee runs no telemetry.

The same transparency pays into ISO 27001, where Annex A.5.19 to A.5.23 require you to know and manage suppliers and cloud services, into the supply-chain requirements of NIS2, and into DORA's register of ICT third-party providers. In all three cases the precondition is identical: you must know which third party processes your data. With BYO-LLM that answer is part of your own settings rather than a footnote in somebody else's contract. And where the EU AI Act asks for transparency and AI literacy, being able to name which model runs where helps.

Comparison matrix with three columns, vendor-hosted AI app, platform-bundled AI, Bring Your Own LLM, and six rows: who picks the model, who picks provider and region, where the keys live, who holds the contract with the model provider, who sees the list of reachable addresses, switching models without an app update. — Figure 3: What changes for governance, security and compliance. With BYO-LLM all six decisions sit with the organisation itself.

The upsides in day-to-day work

Control is one half; flexibility is the other. If you choose the model, you can choose it per task: a fast, inexpensive model for summaries and drafting, a reasoning model for analysis, an open-weight model on your own hardware for a project with particularly sensitive data. Existing contracts and quotas, an Azure enterprise agreement for instance, keep working instead of paying for the same capability a second time through the app price. And when a better model ships next month, it is an entry in the model list, not a new product.

A stable app layer with permissions, approvals and history, into which interchangeable model connections are plugged: an EU cloud provider, Azure OpenAI and a self-hosted model. Switching is a configuration change, not an app update. — Figure 4: Change the model, not the app. Permissions, approvals and history stay; the connection is interchangeable.

Honest limits

BYO-LLM means, by definition, that prompts leave the Atlassian infrastructure. They go to your endpoint, but they do leave. Atlassian's “Runs on Atlassian” badge is therefore out of reach for this approach, and we would rather say so than talk around it. Responsibility for the contract with the model provider is yours, and you need someone who maintains addresses, keys and model lists. That is the price of control: whoever decides is also in charge. For organisations that already run an ISMS this is no new duty, just the continuation of what they do for every other service provider.

How anyLLM does it

anyLLM is a Forge app by maplee: one installation for Jira and Confluence on the same site, with chat, agents, prompt templates and memory, reachable from the full-page view, the Confluence byline, the context menu, Jira issue actions and a dashboard gadget, fully bilingual in English and German. To our knowledge it is the first app on the Atlassian Marketplace that combines a complete assistant for both products with BYO-LLM while pre-approving not a single external address. The full security description, the data flow and the manual are documented publicly on maplee.de.

anyLLM is available on the Atlassian Marketplace. Try it with your own model, or talk to us about your use case.

View on Atlassian Marketplace →