jiraagents

Findings
become
tickets.

Security scanners find problems in your code. jiraagents files one Jira ticket per finding, and running it again files nothing new. When you ask, an agent can propose the fix as a draft pull request for your team to review.

It runs on your own machines, with the Jira and GitHub accounts you choose. Nothing goes to Jadex, the company that makes it, and it never merges a change: a person does.

Book a walkthrough How it works

Yours
Your machines

Your repositoryread in place; scan writes nothing to it

jiraagentson a laptop, in CI or in a container, with your tokens

127.0.0.1:4330the dashboard, on loopback

Your Jira sitetickets, with code capped at 50 lines and 4 KB

api.github.com and your git remotepull request state; one draft pull request per fix

api.anthropic.comonly with your key; it receives source code

Public sourcesthe semgrep.dev ruleset, fetched at initscanner databases: not yet documented

Jadexnothingno request, no token, no telemetry

Nothing goes to Jadex. Every request the tool makes goes to a machine you run, an account you hold or a public source. The orange line is the path a finding takes to a ticket. Off until you turn them on: TypeSafe triage, and Strix, which attacks a target you name. What is sent to each, and when: the security page.

How a ticket becomes a draft pull request.

One finding from the real run further down, in each bay of the board. The plan found it and the apply filed it as WP-297: that much happened. It has not been given to an agent, so the last three bays show the board’s own words for each later stage, not something that has happened to it.

  1. Found

    NewMedium

    GitHub actions mutable action tag

    .github/workflows/ci.yml

    Not filed yet. Would be filed in WP.

  2. Ticket in Jira

    WP-297Medium

    GitHub actions mutable action tag

    .github/workflows/ci.yml

    An agent can take this.

  3. With an agent

    WP-297Medium

    GitHub actions mutable action tag

    .github/workflows/ci.yml

    Working on it. Writing the change.

  4. Pull request

    WP-297Medium

    GitHub actions mutable action tag

    .github/workflows/ci.yml

    Draft pull request open. Waiting for a person to review it.

  5. Fixed

    WP-297Medium

    GitHub actions mutable action tag

    .github/workflows/ci.yml

    Fix verified. Its pull request merged, and a later scan no longer finds the problem.

Step by step, and who does each step. The agent only edits files in a copy of its own. The command line tool makes every change to Jira and GitHub, and a person merges.

  1. Scanners find a problem. jiraagents files one ticket.

    On the board: Found

    A scanner (semgrep, osv-scanner, trivy or Strix) finds a problem in your code, or you hand jiraagents a written report. jiraagents first works out which tickets should exist, writing nothing (plan), then files one Jira ticket per finding (apply).

    Each ticket carries a fingerprint: a label worked out from the finding itself, not from its line number. That is how it knows a finding it has already filed, so running it again files nothing new.

  2. A person hands the ticket to an agent.

    On the board: Ticket in Jira

    Somebody on your team chooses which ticket an agent works on, from the dashboard or from the command line:

    jiraagents solve --ticket KEY

    not yet Changing a ticket’s assignee in Jira does not start an agent.

  3. jiraagents claims the ticket in Jira.

    On the board: With an agent

    While the agent works, the ticket carries the label agent-claimed, is assigned to the account jiraagents runs as, and has a comment saying it is claimed. Anybody looking at the board can see it is taken.

  4. The agent writes a fix in a copy of its own.

    On the board: With an agent

    Its copy is a git worktree: a separate working copy of your repository. In it, the agent can read a file, write a file and say it is done, and nothing else: it has no shell and no network of its own.

    Today it can fix three kinds of finding: pinning a GitHub Action to one exact commit, upgrading a vulnerable package and setting npm’s minimum release age, so a newly published version waits before it can be installed. For any other ticket it declines, and says why on the ticket.

  5. jiraagents checks the change at seventeen gates (ten run in this release), then opens a draft pull request.

    On the board: With an agent

    The command line tool, not the agent, checks the change at seventeen gates, G0 to G16, and only then opens a pull request, as a draft: GitHub will not merge a draft until a person marks it ready. The seven gates it cannot verify in this release are listed in the pull request itself, under “What I could not verify”.

  6. The ticket hears back.

    On the board: Pull request

    jiraagents comments on the ticket with the link to the draft pull request, removes the agent-claimed label and clears the assignee.

  7. A person merges, and the ticket closes on evidence.

    On the board: Fixed

    Your team reviews the draft like any other pull request: jiraagents never merges. The ticket is closed as fixed only after the pull request is merged and a later scan no longer finds the problem. If the agent finds the problem already gone from the code, it says so on the ticket and tries to close it, with no pull request.

What it means for you.

The same tool, from four seats. Each answer links to where you can check it.

  • Security lead

    Where do our code and our tokens go?

    Only to places you choose, and never to Jadex. Ticket excerpts, capped at 50 lines and 4 KB, go to your Jira site; fixes go to your GitHub as draft pull requests; source code goes to api.anthropic.com only if you give it your own key. TypeSafe triage and Strix are off until you turn them on. Jadex runs no server the tool talks to and holds none of your tokens. The agent that writes code has no shell and no network of its own.

    See the drawing at the top, and the hosts it reaches, one by one with what is still not documented, on the security page.

  • Engineering manager

    Will it bury our backlog, and can I trust a closed ticket?

    One finding becomes one ticket, in the Jira project you name, and running it again files nothing new. A ticket is closed as fixed only after its fix is merged and a later scan no longer finds the problem; if an agent finds the problem already gone, it says so on the ticket and tries to close it. Where something has not been measured, such as how many findings are real, it says “not measured” instead of showing a number.

    See a real run, twice and what has not been measured.

  • Platform or DevOps team

    What do we have to run, and where?

    A command line tool from npm, with no install scripts. A pull request check that needs no secret and files nothing, and a nightly job that files into Jira with three Jira secrets. The dashboard, if you want it, runs on loopback or in a container you build from the Dockerfile. There is no Jadex service to sign up to and no Jadex host to let through a firewall.

    See where it runs.

  • Developer

    What lands on my desk, and what stays my call?

    Tickets that name the tool, the problem and the file, with the matching code. A fix from an agent arrives as a draft pull request you review like a colleague’s, listing what it could not verify, and only a person merges it. Outside the three kinds of fix it knows, the agent declines and says why on the ticket, so the work stays with you.

    See the steps above and the seventeen gates.

Run it twice. The second run files nothing.

A pipeline turns input into output, so running it twice doubles the output. That is the wrong shape for anything that writes to a board other people use. jiraagents is a reconciler: it works out what should exist, reads what does, and files only the difference.

  1. scanworks out the tickets that should exist
  2. Jira and GitHubare what does exist
  3. planis the difference, from a pure function: code that reads and cannot write
  4. applyfiles the difference, and nothing else
A real run on the demo repository dhillonvo/jiraagents-demo, 12 October 2026. Excerpts, with ... where lines are left out; no line shown is changed. The orange line follows one finding from the plan, to the ticket it became, to the next plan.
First plan

jiraagents plan

  1. plan run-20261012-074359-d26968 · project WP · head d96cf95
  2. createfpv1-05c26e6d1129c071f8cfe118SEC: [semgrep] run-shell-injection in .github/workflows/ci.yml
  3. ...
  4. createfpv1-d730198d1484c796d671211bSEC: [semgrep] express-session-hardcoded-secret in src/server.js
  5. createfpv1-f762b47d6a76767248338f71SEC: [semgrep] hardcoded-jwt-secret in src/server.js
  6. createfpv1-0fba442fd89bcd4705063580SEC: [semgrep] express-open-redirect in src/server.js
  7. ...
  8. 10 to create · 2 corroborate · 7 folded into a ticket for the same package · 0 unchanged · 0 provisional · 7 candidates (model-only, not filed)
Apply

jiraagents apply --from run-20261012-074359-d26968 --yes

  1. createdWP-292← fpv1-05c26e6d
  2. ...
  3. createdWP-299← fpv1-d730198d
  4. createdWP-300← fpv1-f762b47d
  5. createdWP-301← fpv1-0fba442f
  6. ...
  7. 10 created · 9 updated · 7 skipped · 0 failed
Second plan, same commit

jiraagents plan

  1. plan run-20261012-074446-1ab423 · project WP · head d96cf95
  2. noopfpv1-05c26e6d1129c071f8cfe118unchanged: WP-292 (issue 12866) already tracks this finding
  3. ...
  4. noopfpv1-d730198d1484c796d671211bunchanged: WP-299 (issue 12873) already tracks this finding
  5. noopfpv1-f762b47d6a76767248338f71unchanged: WP-300 (issue 12874) already tracks this finding
  6. noopfpv1-0fba442fd89bcd4705063580unchanged: WP-301 (issue 12875) already tracks this finding
  7. ...
  8. 0 to create · 19 unchanged · 0 provisional · 7 candidates (model-only, not filed)

Both plans ran on the same commit. The first had 10 to create. After the apply, the second had 0 to create and 19 unchanged, the open redirect among them, already tracked by WP-301. A run that stops halfway is finished by the next one, never doubled.

One finding, one ticket
The fingerprint comes from the tool, the rule, the path and the matched code, not the line number. Add an import at the top of a file and nothing refiles.
Drift is refused, not hidden
If a scanner or its rules no longer match the versions your repository pinned, every finding is marked provisional, and a provisional finding never becomes a ticket.
Closed only on evidence
A ticket closes as fixed on a merged pull request and the finding's absence from the next scan. An agent closes one only when its own scan of the code cannot find the problem, and it says so on the ticket. Never on a model's say so.

The review screen, before anything is filed.

The dashboard runs on your machine or in your cluster and shows what the plan would file. It files nothing on its own: creating tickets is a button, and the button works only on loopback, the machine’s own address.

The jiraagents dashboard reviewing a real plan that would file two findings as Jira tickets in project WP, and the panel that creates them only after you confirm.
The dashboard's review screen, from a real run of jiraagents on its deliberately vulnerable demo repository, 12 October 2026. It comes from a later plan than the two above: commit 8e191c8 added src/export.js with two new weaknesses, so the 2 to create are those new findings, not repeats of tickets already filed.

Seventeen gates stand between an agent and a draft pull request.

A solver agent can read a file, write a file and say it is done. It has no shell and no network of its own, and it works in a disposable worktree. The command line tool takes every irreversible step, and only after the gates.

  1. G0Broad-ruleset baselineunverified
  2. G1Present at basechecked
  3. G2Reproduction flipsunverified
  4. G3Absent at headchecked
  5. G4No new findingschecked
  6. G5No suppressionchecked
  7. G6Tests unchangedchecked
  8. G7Path policychecked
  9. G8No symlink or mode changechecked
  10. G9Diff budgetchecked
  11. G10Suites no worseunverified
  12. G11Semantic scopeunverified
  13. G12Egress scanchecked
  14. G13Typecheck and buildunverified
  15. G14Base freshnessunverified
  16. G15Claim heldchecked
  17. G16Arbiter reviewunverified
  18. Draft pull requestopened by the command line tool; never ready to merge

Ten are checked. Seven say unverified in this release: each is written into the pull request under “What I could not verify”, and none counts as a pass.

Where it runs: on machines you already run.

There is no service in the middle. Jadex runs no host this tool talks to and holds none of your tokens.

  1. The command line

    npm install -g @jadex-consulting/jiraagents --ignore-scripts

    Public on npm, with no install-time scripts: a test fails the build if one appears. scan, sarif export, explain and audit export need no Jira and no credential.

    doctor runs eighteen checks on a default config. FAIL means it cannot do its job; WARN names the one feature you lose.

  2. CI, on every pull request and nightly

    The pull request gate scans the head and the merge base and reports only what the pull request introduced. It needs no secret and files nothing. The nightly run files into Jira, with three Jira secrets scoped to that one workflow. solve does not run in CI.

  3. The dashboard, in your network

    jiraagents dashboard

    It serves 127.0.0.1:4330 and loads nothing from the internet. Bound to a reachable address it will not start without a token, and it refuses every job that writes, because a shared token cannot say which person made the change.

  4. A container you build

    docker compose up -d

    The image is built in your environment from the Dockerfile; Jadex publishes no image and runs no registry. The repository being audited is mounted read-only.

Works with Jira Cloud and github.com; semgrep, osv-scanner, trivy and anything that writes SARIF.

Not supported: Jira Data Center, and native Windows (WSL, Docker and CI work).

What has not been measured, said plainly.

Where another tool would print a reassuring zero, this one prints “not measured” and the reason. So does this page.

  • not measured

    Precision

    How many findings are real has never been measured on a real project, so nothing here claims a number for it.

  • not measured

    Outcomes

    There is no count of tickets fixed and no merge rate for the pull requests agents open.

  • not measured

    Two machines, one ticket

    The claim fence that stops two agents working the same ticket has never been raced on two real machines.

  • unverified

    Your test suite

    solve does not run your tests in this release. Its gate for them, G10, says unverified on every pull request.

  • not yet documented

    A hostile repository

    What the scanners and package managers load from a repository you do not trust is not yet written down. Until it is, scan one in a container with no credentials.

  • not yet documented

    Other setups

    GitHub Enterprise Server, Atlassian scoped tokens and fine-grained GitHub tokens have not been exercised.

An excerpt of jiraagents status on a repository with no plan run yet

jiraagents status

not measured:

  1. raw findings: no plan run has been recorded for this repository; run jiraagents plan
  2. came back within 30 days: no pull requests were observed, so no fix is known to have shipped

Bring the questions your security review will ask.

A walkthrough covers the boundary, a plan against a repository and the gates. A company uses jiraagents under a written agreement with Jadex Management Ltd. Write to:

dhillon.vo@jadexconsulting.com

Each opens a new message with the subject “jiraagents walkthrough”. If none of them is how you read mail, copy the address: one click selects all of it.