CogniRunner: Jira OpenAI Key for Workflow Rules

Description and use

CogniRunner lets Jira admins attach an AI validator to workflows, supporting 11 LLM providers, including OpenAI, Azure, Gemini and Forge LLM, with secure key storage and connection testing.

Problem

Administrators need to configure an AI validator in Jira that can use multiple LLM providers while keeping sensitive keys secure and ensuring the validator behaves predictably.

Outcome

After configuration, the validator rejects a summary containing gibberish with a 400 response and accepts a valid summary with a 204 response, demonstrating successful integration.

Workflow

• Open CogniRunner Settings page
• Pick provider and enter base URL if required
• Paste API key (or skip for Forge LLM)
• Choose model or use provider default
• Press Test connection and verify "Connected" verdict
• Add CogniRunner Field Validator to a transition with a prompt
• Verify with REST calls that junk issue returns 400 and good issue returns 204

Evidence

Connecting Jira to OpenAI for a workflow validator sounds like one decision. In CogniRunner it is a choice between eleven providers in 5.0.0

Source

If you paste your own OpenAI API key, you pay OpenAI, you pick the model, and the issue text you validate leaves Atlassian for OpenAI's servers.

Source

The Test connection button is the check for this step. It maps the provider's answer to one of these verdicts, straight from OpenAIConfig.jsx

Source

If you pick a provider and never choose a model, these are the defaults the code falls back to

Source

The key is stored with an ordinary Forge KVS set, the same app storage the rest of CogniRunner's settings live in.

Source