{"slug": "atlassian-license-management-with-cognirunner-ai", "title": "Atlassian License Management with CogniRunner AI", "summary": "A developer set up a CogniRunner AI agent in Jira Cloud to manage Atlassian licenses, giving it a plain-language job description that capped each of 32 products at 10 licensed users across 17 sites. The agent's read-only operations ran autonomously while the single write operation — removing a user from a group — required human approval, and a drill that removed one Confluence license consumed roughly 72,000 AI tokens. The developer notes that a deterministic tool would be simpler and token-free if license management were the only task.", "body_md": "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.\n\nThe 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.\n\nThat 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.\n\nBelow 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.\n\nThe 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:\n\nKeep 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.\n\nThen you press Ask the agent to propose its setup. It searches CogniRunner's catalog of Atlassian operations and comes back with what it wants.\n\nIt 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.\n\nIt 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.\n\nOne 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.\n\nAtlassian'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](https://developer.atlassian.com/cloud/admin/organization/rest/intro/), with the organization API key an admin stored in CogniRunner.\n\nOur 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.\n\nI 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.\n\nThe 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.\n\nHere'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.\n\nI 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.\n\nThe 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.\n\nThe 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.\n\nCounting 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](https://community.atlassian.com/forums/discussion/614778/automatically-disable-inactive-users-to-save-licenses) has 10,636 views.\n\nAtlassian 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](https://jira.atlassian.com/browse/AX-1169), was opened in 2019 under another key and has been Under Consideration since May 2024, with 779 votes.\n\nSo 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.\n\nIt 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.\n\nThen 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.\n\nTwo things I'd want to know before trusting a run like this.\n\nThe 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.\n\nCogniRunner 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.\n\nIf the agent gets it wrong, the way back is one API call: add the person to the group again, as we did.\n\nI'd go through these before the first run. None of them is optional.\n\n[[steps]]\n\nNone 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.\n\nEvery 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](https://leanzero.net/blog/rovo-agent-permissions-cognirunner-approvals?utm_source=devto&utm_medium=referral&utm_campaign=crosspost), so I won't repeat it.\n\nWhat'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.\n\nEvery 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.\n\nHere'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.\n\nWho 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.\n\nNow 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.\n\nAn 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.\n\nCogniRunner 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.\n\nThe 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](https://developer.atlassian.com/platform/marketplace/security-requirements/) 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.\n\nEvery 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.\n\nAt 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.\n\nThere'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.\n\nWho 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.\n\nNow 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](https://marketplace.atlassian.com/apps/1211109/user-management-and-license-optimizer-for-jira-confluence) describes itself as \"Offboard users, deactivate inactive accounts & optimize Jira and Confluence licenses\", and [Manage Users for Jira Cloud](https://marketplace.atlassian.com/apps/1224410/manage-users-for-jira-cloud) as \"List all users, detect and deactivate inactive ones\". LeanZero is building a dedicated license app too, [Cost Slasher](https://leanzero.net/portfolio/cost-slasher?utm_source=devto&utm_medium=referral&utm_campaign=crosspost), 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.\n\nIn 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.\n\nAI 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?\n\nThe 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:\n\nThis 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.\n\nPASS 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.\n\nThe 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.\n\nA 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:\n\n```\nHTTP 400\n{\"errorMessages\":[\n  \"AI Validation failed: The backout plan does not restore the dropped legacy_iban column or its data from the snapshot.\",\n  \"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.\"\n],\"errors\":{}}\n```\n\nThat'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.\n\nThe 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).\n\nBefore 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.\n\nAtlassian'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.\n\nOne Jira detail decided where the gate sits. In Jira Service Management, approval steps skip workflow validators. [JSDCLOUD-6988](https://jira.atlassian.com/browse/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.\n\nI'm stating that as what we looked for and didn't find. Atlassian ships fast, so check it before you rely on it.\n\nI'd rather you hear these from me.\n\nIt 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.\n\nEach 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.\n\nThe 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.\n\nAnd 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.\n\nAtlassian 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.\n\nCreating 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.\n\nSet 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](https://developer.atlassian.com/platform/forge/set-up-cicd/) 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.\n\nTrigger 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.\n\nCogniRunner only ever triggers deploys to development. Staging and production stay yours to run.\n\nThis 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](https://leanzero.net/tutorials/migrate-off-bitbucket-app-passwords?utm_source=devto&utm_medium=referral&utm_campaign=crosspost) separately.\n\nThe 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](https://leanzero.net/tutorials/cognirunner-coder-jira-coding-agent-github?utm_source=devto&utm_medium=referral&utm_campaign=crosspost) walks that path.\n\nYou 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.\n\nEnter your work email on [the demo site page](https://leanzero.net/portfolio/demo-site?utm_source=devto&utm_medium=referral&utm_campaign=crosspost), 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.\n\nCogniRunner is on the [Atlassian Marketplace](https://marketplace.atlassian.com/apps/298437877/cognirunner?hosting=cloud), and everything here is in version 7.11.0 or later. The [CogniRunner manual](https://leanzero.net/portfolio/cognirunner#agents-overview?utm_source=devto&utm_medium=referral&utm_campaign=crosspost) has the agents chapter by chapter, and if workflow validators are new to you, start with [how a CogniRunner AI validator works](https://leanzero.net/blog/cognirunner-jira?utm_source=devto&utm_medium=referral&utm_campaign=crosspost).\n\nMy advice: start the license watchdog on a home project only admins can see, and read a week of its reports before you approve its first removal.\n\nOriginally published on [leanzero.net](https://leanzero.net/blog/atlassian-license-management-cognirunner-ai-agent?utm_source=devto&utm_medium=referral&utm_campaign=crosspost). More Atlassian, Forge and local-AI write-ups at [leanzero.net/blog](https://leanzero.net/blog?utm_source=devto&utm_medium=referral&utm_campaign=crosspost), and if you're planning a migration or a Forge app, that's what we do: [leanzero.net/services](https://leanzero.net/services?utm_source=devto&utm_medium=referral&utm_campaign=crosspost).", "url": "https://wpnews.pro/news/atlassian-license-management-with-cognirunner-ai", "canonical_source": "https://dev.to/mihai_leanzero/atlassian-license-management-with-cognirunner-ai-14b3", "published_at": "2026-10-10 14:12:01+00:00", "updated_at": "2026-10-10 14:18:16.277724+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "ai-products"], "entities": ["Atlassian", "CogniRunner", "Jira Cloud", "Confluence", "Forge", "Bitbucket Pipelines", "Claude Code", "Atlassian Marketplace"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/atlassian-license-management-with-cognirunner-ai", "markdown": "https://wpnews.pro/news/atlassian-license-management-with-cognirunner-ai.md", "text": "https://wpnews.pro/news/atlassian-license-management-with-cognirunner-ai.txt", "jsonld": "https://wpnews.pro/news/atlassian-license-management-with-cognirunner-ai.jsonld"}}