Atlassian license management by prompt: what CogniRunner's Jira AI agents can do now
Mihai Perdum
Author
17 min readOctober 10, 2026
Key takeaways
One paragraph in Describe a job became a license watchdog: the agent asked for 8 Atlassian operations, 7 reads that run on their own and 1, removing someone from a group, that asks a person every time.
On 9 October, once its plan was tightened by hand, it counted 32 products on 17 sites through the Organizations API and found 3 to 6 licensed users on each, so it proposed nothing. A count taken outside CogniRunner agreed.
A drill with a limit of 4 took Confluence on our test site from 5 users at 22:11 UTC to 4 at 22:12 UTC, after one approval and Atlassian's 204. The person was put back a minute later.
Two CogniRunner AI validators stopped a real Claude Code session on a Jira Service Management transition twice (HTTP 400) and let it through once a person attached passing evidence (HTTP 204). If the AI provider doesn't answer within 20 seconds the transition goes through, so it's a quality gate, not a security control.
The Coder created a Bitbucket repository, committed a 7-file Forge app and deployed it through Bitbucket Pipelines in 3 min 45 s, with the deploy token kept in Bitbucket and never in CogniRunner.
Every run spends AI tokens, on whichever provider you pick. The drill's turn used about 72,000: 2 to 9 cents at DeepSeek V4.1 Flash list prices, 14 to 72 cents on Claude Sonnet 5.5. For license management alone, a deterministic tool is the simpler path: no tokens per run, no model to misread the rule.
Atlassian license management is the job we gave a CogniRunner AI agent this week, in one paragraph of plain words. CogniRunner is a Forge app for Jira Cloud: AI rules on your workflows, plus AI agents that work in Jira, Confluence and your Atlassian organization. Once I'd tightened the plan it wrote for itself, it counted 32 products on 17 sites. Nothing was over 10. A second agent took one Confluence user's license away, and only after a person pressed Approve.
The paragraph said: keep every product at 10 licensed users or fewer, leave demo evaluators alone, never touch admins, tell me what you found. On 9 October the watchdog found between 3 and 6 licensed users on each of the 32 products. So it proposed nothing. The second agent ran a drill with a limit of 4 on one Confluence site that had 5. It filed one request. Nothing moved until a person approved it. Atlassian's Organizations API read 5 at 22:11 UTC and 4 at 22:12 UTC, and we put the person back a minute later.
That drill turn used about 72,000 AI tokens. Every run spends tokens, on whichever provider you pick. If license management were the only job, a deterministic tool would be the simpler path, with no tokens per run, and I'll name the options further down.
Below is how the license watchdog was set up, how a drill took one license away, what to check before you switch one on, the safety design piece by piece, and the bill. Then two other things CogniRunner did on camera this week: an AI workflow validator that stopped Claude Code, and the Coder shipping a Forge app through Bitbucket Pipelines. Four videos in all, the last one showing how to try it yourself.
Seven things I found building it
A paragraph gets you a setup, not yet a finished job. Describe a job proposed 8 operations and a 14-step plan from our paragraph. On 1.32.2 that fresh agent still couldn't finish the count until I rewrote its plan by hand.
The first live runs saw 2 of our 17 sites. One page of 100 site products is about 290 KB, and CogniRunner cut every answer at 256 KB. Version 1.32.3 reads organization answers whole, up to 1 MB.
The second check held every license report for a person. It can't see the agent's reads, so it can't confirm the counts. On our runs a person approved the daily report.
The removal ran, and CogniRunner called it unconfirmed. Atlassian answered 204 and the count dropped, but the API has no read for a single group membership, so the agent's own record said it couldn't see the person gone. Version 1.33.1, out on 10 October, reads the person's groups back instead.
The workflow validator stopped Claude Code twice, for two different reasons. Claude fixed the first, a backout plan that didn't restore the dropped column. It couldn't fix the second, a failed rehearsal report, and handed the change back.
The Coder deployed a Forge app in 3 min 45 s through Bitbucket Pipelines, and CogniRunner never held the deploy token.
Admin protection is a list, not a promise. Removing an admin CogniRunner can recognize from a group, revoking their role, suspending or deleting them is refused whoever approves. Organization policy changes and an issue's own security level aren't checked that way, and project lead changes aren't covered yet.
Atlassian license management, set up by prompt
The button is called Describe a job. It's on the Agents tab of CogniRunner's admin page, where the agents are called Virtual Administrators. One note on numbers: the app counts the releases covered here 1.32.0 to 1.33.1, and the Marketplace calls the same ones 7.6.0 to 7.11.0, shipped on 9 and 10 October. I'll use the app's numbers, because that's what the screenshots show. You give the agent a name, a home project for its daily review issue, a time zone, and the job in your own words. This is the paragraph we used:
Keep every product on this organisation at most 10 licensed users, not counting demo evaluators. Demo evaluators are the people in the Demo evaluator field of DACC issues that are not in the Demo expired status; leave them alone, LeanZero offboards them after 5 days. Each day, count licensed users per product on every site the organisation API key reaches, find who has been inactive the longest from the Organizations API last-active dates, and propose removing product access from the least active until each product is at 10 or below. Never touch organisation admins, site admins, or app and service accounts. Tell me what you found and what you did.
Then you press Ask the agent to propose its setup. It searches CogniRunner's catalog of Atlassian operations and comes back with what it wants.
Describe a job on CogniRunner 1.32.0, captured on our demo site on 9 October. Seven reads run on their own. The one change, Remove user from group, asks a person every time.
It asked for 8 operations. Seven are reads: the organization's sites (Atlassian calls them workspaces), its users, user counts, user details, role assignments, last-active dates, and one Jira search for the demo evaluators. Those run on their own. The eighth is the only one that changes anything: remove a user from a group. It's marked Asks you each time. And the screen says who has to sign it off: organization operations can only be allowed by an organization admin.
It also wrote a 14-step plan, six standing rules and a schedule. Open a review issue in the home project every day at 09:00, check for work every 30 minutes in working hours. Create this agent moves it straight to Live. Live here means it reads and reports on its own. Every change to users, groups or configuration still waits for a person.
One trap I'm glad is gone, as of 10 October. Before 1.33.1 a described agent was created with working hours on, so a run outside them reported nothing. From 1.33.1 it works and posts at any hour and may spend up to 500,000 tokens a day. Agents described before keep working and posting hours of Monday to Friday, 08:00 to 18:00, and 250,000 tokens a day.
Counting licensed users per product with the Organizations API
Atlassian's rule for who costs you money is short. Its user management guide says that once app access is granted, "all users with app access start counting towards your cloud subscription", even people who never log in. So the agent counts active users holding the atlassian/user or atlassian/admin role on each product, per site, through Atlassian's Organizations REST API, with the organization API key an admin stored in CogniRunner.
Our organization has 17 sites, all of them our own test and demo sites. Jira runs on all 17, Confluence on 12 and Jira Service Management on 3. That's 32 products. The smallest holds 3 licensed users, the largest 6 (Confluence on the demo site). Nothing is near 10.
The watchdog's report on 1.32.2, captured on our demo site at 20:16 UTC on 9 October, an earlier run than the filmed one: 32 products, 17 sites, 3 to 6 licensed users each, one demo evaluator left out. Notice the second check held it for a person. The approval wording in the header is 1.32.2's, corrected in 1.32.3.
I didn't take the agent's word for it. A script outside CogniRunner read the same Organizations API at 22:10 UTC: 32 products, 17 sites, 3 to 6 users each, all 32 reads answered 200.
The watchdog left one live demo evaluator out of the demo site's counts. Evaluators are people who signed up on our demo site. leanzero.net ends their access after five days, or later if they extend, prompted by a CogniRunner agent and a scheduled job, so the watchdog leaves them alone. It made no difference that day. No product was near the limit with or without that evaluator.
Here's my video of it. The run you see is the watchdog we'd set up the same way earlier, after I tightened its plan. It isn't the agent created on camera at the start.
The first agent we described couldn't finish
I got this wrong the first time. A freshly described agent on 1.32.2 ended its first turn after 8 rounds with no report. Three things broke it.
The answer was too big. One page of 100 site products from our organization is about 290 KB. CogniRunner cut every answer at 256 KB, the cut JSON couldn't be compacted, and the model saw 2 of the 17 sites. It spent its remaining rounds re-reading the list. The site list also never said when it was complete, so the model tried to filter it and Atlassian answered 400. And on the last round of a turn an agent can only finish, so a turn that spent its rounds reading reached the end with nothing staged.
The agents in the video run on a plan I rewrote over CogniRunner's REST API: 50-row pages, one count per product, stage the report before the last round. Version 1.32.3 fixed the causes. It reads organization answers whole up to 1 MB, marks whether the site list is complete, and tells the agent its round budget up front. There was no field for the job text on screen, so my rewrite needed the API. Version 1.33.1 added one, under Edit everything, and asks the agent for a more concrete plan, in which each step should name the operation and the exact values it sends. That change cut the last steps off some plans, often the one that writes the report, and 1.33.2 fixed it the same day. I haven't re-run a freshly described agent end to end since, so I'm not promising yours finishes its first count without help. I'd rather say that than oversell it.
Remove inactive users from Jira Cloud, only after a person approves
Counting is the easy half. The half people actually search for is taking a license away from someone who stopped using it. An Atlassian Community thread called Automatically disable inactive users to save licenses has 10,636 views.
Atlassian gives you the data. Every user has a last-active date per product, through the API or the "Last seen in" column of a user export, on all plans. Nothing in its docs removes inactive users for you. Admin automation is an Enterprise feature, and its clean-up actions revoke inactive API keys and tokens, not app access. The request to deactivate inactive users, AX-1169, was opened in 2019 under another key and has been Under Consideration since May 2024, with 779 votes.
So we set a second agent a drill. Licence drill had one job. Keep Confluence on our test site at most 4 licensed users, never touch admins or service accounts, and propose removing access from the least active until it gets there. Confluence there had 5 users. Three are organization or site admins, so the agent left them out. Of the other two it picked the one with the older last-active date, 30 September, and filed one request: remove that person from the site's Confluence users group.
The rehearsal drill on 1.32.2, earlier the same evening on our demo site. Above: the request waits under Atlassian calls. Below: after Approve and run, Atlassian answered 204. The header's Jira administrator wording is 1.32.2's; from 1.32.3 an organization admin approves organization operations. IDs blurred.
It shows up in the agent's Atlassian calls tab, under Waiting for your approval. Approve asks once more: it runs once, now, exactly as shown, and nothing else. In the filmed run the request was filed at 22:12:21 UTC and approved 18 seconds later. Atlassian answered 204.
Then I checked the count with the Organizations API, outside CogniRunner. 5 at 22:11 UTC, 4 at 22:12 UTC. At 22:13 we added the person back to the group, and Atlassian answered 204 again. In the rehearsal drill earlier that evening, the same put-back took the count to 5 again.
Illustration, generated locally with FLUX. One approval took Confluence from 5 users to 4. The person was put back a minute later.
Two things I'd want to know before trusting a run like this.
The count is the proof, not the card. I trust the Organizations API number. So should you. Atlassian's own docs say removing someone from a group "removes any app access and permissions granted by this group, but the user may still be in other groups that grant the same app access". A 204 means the membership is gone. It doesn't mean the license is.
CogniRunner couldn't even confirm the membership was gone, until 10 October. It reads a change back to confirm it, and the API has no read for one group membership, so the rehearsal's record of its removal said not confirmed even though the count dropped. Version 1.33.1 confirms a removal by reading the person's groups back. That proves the membership is gone, not the license. What hasn't changed: CogniRunner still doesn't read the membership before it sends the removal, so the request is sent even if the person's situation changed after it was filed. Read the card against today's state before you approve.
If the agent gets it wrong, the way back is one API call: add the person to the group again, as we did.
Before you switch it on, check these seven things
I'd go through these before the first run. None of them is optional.
1
Find an organization admin
Storing the organization API key and allowing organization operations both need one. The Describe a job screen also says changes to users or groups need a site admin, "so Create needs one".
2
Look hard at the key
Atlassian's list of admin API scopes has no write scope for group memberships, and its docs say an endpoint missing from that list needs a key without scopes. A key without scopes "can access all Atlassian Admin APIs", and Atlassian itself says it "may present a security risk because it can access everything". I haven't tried a scoped key against the removal call. I treat ours like a root password.
3
Clear it with whoever owns personal data
The names and email addresses an agent reads go to your AI provider as part of its work. That's how a model reads anything, and it's a conversation to have before day one, not after.
4
Pick a home project only admins can see
The screen asks for exactly that. The daily review issue lands there, with names in it.
5
Check its hours
An agent described before 1.33.1 keeps working and posting hours of Monday to Friday, 08:00 to 18:00, so a run outside them reports nothing. To have it report at any hour, switch its working hours off and set its posting hours to every day, 00:00 to 23:59. One described on 1.33.1 works and posts at any hour.
6
Know what's enforced in code and what isn't
CogniRunner's code protects admins it can recognize, whoever approves. Everything else in your paragraph (leave service accounts alone, skip the evaluators, pick the least active) is the model following instructions. The approval card is where you catch it when it doesn't.
7
Set a token cap you can live with
An agent made with Describe a job on 1.33.1 may spend up to 500,000 tokens a day. One described earlier, and any other new agent, gets 250,000. The next two sections cover what it can and can't do, and what it costs.
Safety: approval first, admins protected, the Atlassian organization API key encrypted
None of this is worth anything if an agent can lock your admins out at 3am. Here's what holds every CogniRunner agent back, the license watchdog included. I'll go piece by piece.
Four phases, and in none of them does a model's turn delete or touch identity on its own
Every agent sits in one of four phases: Learn, Shadow, Ask first, Live. In no phase does a model's turn delete something, change configuration or touch identity by itself. From Ask first up, that work becomes an approval request a person decides, and the request expires after 24 hours. If CogniRunner can't tell which phase an agent is in, it treats it as Learn. Gabriela compared the phases with Rovo's permissions in Rovo agent permissions vs CogniRunner approvals, so I won't repeat it.
What's new since then is the plan card. When an agent files several requests in one run on one issue, the Atlassian calls tab shows them as one plan with Approve all and Reject all. Each request is still checked again and run on its own, exactly as shown. One that's refused says why on its row. An organization admin approves organization operations. A Jira administrator approves the rest.
Admin protection, as a list
Every request passes 13 checks before anything is sent, and the admin check runs before the approval step. So an operation that would hurt an admin CogniRunner can recognize is refused outright. It's never put to a person.
Here's the list. From 1.32.1, these are refused whoever approves, when the person is an admin CogniRunner can recognize: removing them from a group, revoking a role or portal access, removing them as a customer, and suspending, disabling or deleting their account. That holds through the Organizations API, Jira, Jira Service Management and Confluence. 1.32.3 added removing them from an issue security level, a request's participants or a Confluence space role, changing their email address or profile, and removing their permission scheme grants. Some operations can't be checked person by person, like a grant held by a project role or a group of more than 50 people, so those are always refused.
Who counts as an admin it can recognize? Through the Organizations API, anyone your organization lists as an organization or site admin. Through Jira, Jira Service Management or Confluence, anyone Jira calls an administrator, plus the members of site-admins, org-admins, administrators, jira-administrators and system-administrators. With a working organization API key stored, the organization's admin list counts there too. When CogniRunner can't tell who an operation would affect, it refuses instead of asking.
Now what's not on the list. Organization policy changes and setting an issue's own security level aren't checked person by person. They wait for an approval like any other change, so the person approving is the last line. Changing a project's lead isn't covered either. That one is on our open list.
The organization API key: org-owned, checked, encrypted
Connections and keys, captured on our demo site on 9 October: the organization key stored with its expiry, and the two user-account credentials this build won't store. Ines Calder is the demo site's made-up agent. Organization ID and key fingerprint blurred.
An organization API key belongs to your Atlassian organization, not to a person. Atlassian's KB says it straight: API keys "are associated with the organization and not individual admins". An organization admin creates it in admin.atlassian.com under Organization settings, API keys. And "An API key can last no longer than a year", says the admin APIs page.
CogniRunner checks it with Atlassian before storing it. It has to belong to the organization that owns the site. It's kept encrypted in Forge secret storage, never shown again (only a fingerprint), and only sent to api.atlassian.com/admin for that organization. You enter the expiry date you chose, and the card warns you two weeks before it ends. Restoring a CogniRunner backup no longer hands an agent organization operations unless the person restoring is an organization admin.
Personal API tokens: not stored on the Marketplace build
The Marketplace build doesn't store credentials of Atlassian user accounts. Not for an agent's service account, not for the guard dog (CogniRunner's watcher for runaway automation rules), not for Forge deploys. That's Atlassian's rule. Its security requirements for cloud apps say: "An application must not collect or store credentials belonging to Atlassian user accounts such as user passwords or user API tokens." (That's Privacy 11 in the all-apps table, 15 in the Forge table.) Until 1.33.0 a Bitbucket connection still kept an Atlassian account API token. 1.33.0 deletes that copy the first time the connection is opened or used, or at the next daily privacy run. So agents write as the CogniRunner app. The deploy identity lives in your CI secrets (more on that in the Coder section). Bitbucket gets access tokens that belong to a repository or a workspace.
What a run costs in AI tokens
Illustration, generated locally with FLUX. The drill's one turn used about 72,000 tokens. The meter doesn't care that the count only moved by one.
Every run reads, reasons and writes, and that's tokens. The drill's turn used about 72,000 (71,807 on the agent's meter, read two minutes after the turn, because the meter lags). The take didn't record the model. The demo site's agent model slot is set to DeepSeek V4.1 Flash through OpenRouter today, so take this as a range, not a quote.
At OpenRouter's list price for DeepSeek V4.1 Flash ($0.30 per million input tokens, $1.20 output), 71,807 tokens cost between 2 cents (all input) and 9 cents (all output). On Claude Sonnet 5.5 ($2 and $10) the same turn is 14 to 72 cents. A month of daily turns that size is 2.2 million tokens: $0.65 to $2.59 on DeepSeek, $4.31 to $21.54 on Sonnet. That's a one-product drill. The watchdog's own turn over 17 sites wasn't isolated on the meter (it moved 142,400 in the minutes after its report), so I'd read this as a floor, not the watchdog's bill.
There's a brake, and I'd keep it: a daily token cap per agent, 500,000 for one made with Describe a job on 1.33.1 and 250,000 for other new agents. I raised both license agents to 3 million while we were testing. The daily review issue itself is opened by a plain script job with no AI in it. The tokens are the agent's turn on that issue.
Who pays depends on which of CogniRunner's eleven provider options you pick. With your own key (Anthropic, OpenAI, Google Gemini, OpenRouter and the rest) the tokens land on your provider account, and CogniRunner adds nothing on top. A local server like Ollama or LM Studio has no token bill at all, just your hardware. The zero-key Atlassian (Forge LLM) option is the reverse: its tokens are billed to LeanZero through the Forge platform, within each edition's monthly allowance.
Now the honest part, and I mean it. At our size the bill is cents a day. That isn't the point. If license management is the only job, a deterministic tool is the simpler path. It spends no tokens. It needs no person to approve a report a second check couldn't verify. It has no paragraph to misread. And finding the least active means reading every candidate's last-active dates, and our agents' plans read them one person at a time, so a 300-person site costs more than our 5-person drill. A daily count is a deterministic job: same inputs, same rule, no judgment. Marketplace has dedicated apps for exactly this. User Management and License Optimizer describes itself as "Offboard users, deactivate inactive accounts & optimize Jira and Confluence licenses", and Manage Users for Jira Cloud as "List all users, detect and deactivate inactive ones". LeanZero is building a dedicated license app too, Cost Slasher, with an inactivity policy per app, a warning period and checks before a seat is released. Its page says it's a paid beta awaiting Atlassian review and not yet available to customers, so I'm not selling it to you here.
In my view AI earns its tokens on the job nobody packaged. A license count that also knows your demo evaluators live in a Jira field. And the two jobs below: a rule that reads a backout plan for meaning, and an app built, committed and deployed from one prompt.
Jira AI agents hit a workflow validator: Claude Code blocked
AI agents can now move your Jira work for you. Atlassian's own MCP docs put it plainly: "MCP clients can perform actions on all connected products (such as Jira, Confluence, Bitbucket) with your existing permissions." On a REST call, Jira still runs the transition's validators, as you'll see below. So the question I wanted answered was simple. Can a rule stop an agent on what the work says, not on a regex?
The setup is a change request in a Jira Service Management project. The transition Submit to CAB carries two CogniRunner AI validators, each written in plain English:
This is a change request. PASS only if the Backout plan section lists concrete steps that restore any data the change deletes or alters, for example from a snapshot or backup. If the backout plan would leave deleted or altered data unrestored, BLOCK and say in one sentence what it fails to restore.
PASS only if a PDF is attached that is a staging rehearsal report and every step in it passed. If several rehearsal reports are attached, judge only the most recent run. If no such report is attached, or any step failed, BLOCK and name the failed step.
The change drops a database column. Its backout plan redeploys the app, flushes a cache and checks health on six pods. Long and specific, so a regex passes it. It never brings the column back.
A real Claude Code session, Anthropic's coding agent on Claude Sonnet 5.5, worked the ticket as Ops Agent, a service desk agent, not an admin. Its prompt said to move the change to Ready for CAB, fix the record itself if Jira refused, and never attach or invent evidence. It called Jira's REST API, and 10.3 seconds later Jira answered:
text
1HTTP 400
2{"errorMessages":[
3 "AI Validation failed: The backout plan does not restore the dropped legacy_iban column or its data from the snapshot.",
4 "AI Validation failed: The staging rehearsal report's step 4, Verify row counts, failed: 27 accounts are missing iban_v2 values. Step 5 was skipped."
5],"errors":{}}
That's the answer I wanted. Claude rewrote the backout plan from the record's own snapshot step and tried again. The plan passed. The rehearsal report still said step 4 failed, and you can't fix that by rewriting text. So Claude handed the change back instead of inventing evidence. A person attached the passing rerun report, Claude retried, and Jira answered 204. Claude Code's side of the two runs cost $0.14 by its own count, on the agent's bill, not CogniRunner's.
The same validators stop a person clicking Submit to CAB in Jira, with the same kind of sentence. CogniRunner's Execution Logs show each verdict with its reason, for a while (more on that below).
Illustration, generated locally with FLUX. The backout plan got rewritten. The failed step 4 did not.
What we searched for and didn't find: an AI verdict that blocks a transition
Before we filmed it, we ran a market research pass and then two independent attacks on it. About 30 Marketplace searches, plus Atlassian's docs, Laya, ScriptRunner, JMWE and Power Scripts, Rovo agents in workflows and the MCP gateways. Neither attack found an app or an Atlassian feature where an AI judgment hard-blocks a transition. Most of the original pitch died in those attacks. That one claim survived.
Atlassian's nearest features do something else. An agent on a workflow transition is "triggered when work transitions from one status to another", and Jira runs those actions "as soon as the transition is completed". It reacts after the move. Jira Service Management's AI risk assessment, on Premium and Enterprise, says outright that it does not "Automatically approve or reject changes". Laya's listing says "Describe the outcome in plain English or use no-code blocks for triggers, conditions, validators, post-functions, schedules and shared actions." It doesn't say the verdict at the transition is an AI call, and we didn't install it to check.
One Jira detail decided where the gate sits. In Jira Service Management, approval steps skip workflow validators. JSDCLOUD-6988, "Approval steps should not bypass workflow validator", has 483 votes and is still Gathering Interest. So the AI check goes on the transition into the approval status, which is Submit to CAB here.
I'm stating that as what we looked for and didn't find. Atlassian ships fast, so check it before you rely on it.
Where the validator is weak
I'd rather you hear these from me.
It fails open. If the AI provider doesn't answer within 20 seconds, CogniRunner lets the transition through, and the same goes for provider errors and rate limits. It blocks on a clear "no" or a reply it can't parse. A change description can also carry text aimed at the validator. So treat it as a quality gate in front of your change board, not a security control.
Each validator reads one field. A rule that needs the description and the attachment is two validators. CogniRunner's own setup screen won't add a second validator to one transition, so we attached the second through Jira's workflow REST API. A DOCX report didn't work in our tests. PDF did.
The log is short. CogniRunner keeps 50 log rows site-wide, 20 per rule, for 30 days. By the next morning the gate's rows had already rolled out of the site-wide list. That's fine for debugging, useless as audit evidence.
And one gap in the evidence. I couldn't find an Atlassian doc that says workflow validators run on REST transitions. We measured it, on this site. I haven't tested the same gate through Atlassian's MCP server yet.
The Coder, a Jira AI coding agent, deploys a Forge app through CI/CD
Atlassian has its own Jira Coding Agent, where you open a pull request from its sandbox, so to be clear: this is CogniRunner's Coder. One prompt in the Coder workspace, no issue: create a private Bitbucket repository, wait for its access token, then build a UI Kit issue panel called Issue age. It ran on DeepSeek V4.1 Flash through OpenRouter.
Creating the repository waited for a yes. In Bitbucket the person made a repository access token named CogniRunner, turned Pipelines on, pasted the token into CogniRunner and told the Coder it was in. The Coder staged seven files. The manifest asked for read:jira-work and nothing else. The commit waited for a yes.
Set up pipeline then locks the app's permissions to that manifest. Its allow-list has 20 scopes and leaves out anything that grants app or site administration, acts as a user, or can mint or read credentials. The deploy identity is the part CogniRunner doesn't touch. Atlassian's Forge CI/CD guide describes FORGE_EMAIL and FORGE_API_TOKEN as "the Atlassian API scoped token and login email of your app's owner", a person's token. So the person adds both in Bitbucket as secured repository variables, where that guide tells you to put them.
Trigger deploy ran the pipeline. Bitbucket's run page says 3 min 45 s, and the log says the app deployed to the development environment. The Coder read the run back: "Yes — it's finished and it succeeded." The panel showed on issue CRD-21: open for 7 days, last updated 6 days ago.
CogniRunner only ever triggers deploys to development. Staging and production stay yours to run.
This is the part I care about most, and the pipeline got safer twice this week. Version 1.32.3 keeps the two secrets away from your repository's own code. It installs dependencies without running their install scripts. It installs the Forge CLI outside the repository. And it stops before deploying if the app carries a Babel configuration or a root .npmrc the CLI would read while it holds the secrets. For a UI Kit app like this one that holds completely. On Bitbucket a Custom UI build step still sees repository variables, so read what a change does to the UI's package.json before you confirm it. Version 1.33.0 (7.10.0 on the Marketplace) moved Bitbucket connections to access tokens that belong to a workspace or a repository, not a person. Paste an Atlassian account token or an old app password into a Bitbucket field and it's refused before it's sent anywhere. App passwords stopped working entirely on 9 June 2026 anyway, and Gabriela wrote up moving off Bitbucket app passwords separately.
The take also showed me two things wrong, and 1.33.1 fixed both on 10 October: links in the Coder's replies that opened nothing inside Jira, and a new repository that landed in the workspace's default project with that project's permissions. Now it goes into the project you name, or the one the connection's other repositories share, and otherwise the Coder asks. On GitHub the Coder works from an issue to a pull request, and the Coder tutorial for GitHub walks that path.
Try it yourself on the demo site
You don't have to install anything to poke at most of this. Our demo site gives you your own account as a Jira and Confluence admin for five days, with CogniRunner, LeanZero Management and Sentinel Vault installed and set up. No card, no trial license, and you can extend it three times.
Enter your work email on the demo site page, confirm from the email, and log in. CogniRunner's settings are under Jira settings, Apps, CogniRunner Settings, and validators already run on the demo projects' workflows. It's a shared site, so keep real data out of it. One limit, so you're not surprised: you can't run the license watchdog there yourself. Allowing organization operations needs an organization admin, and evaluators aren't one. The agent screens, the validators and the Coder are all there to look at. One detail I like: the agent that marks your access a day before it ends, and the scheduled job that moves it to expired, are ordinary CogniRunner rules.
