Anomity Integrates with Jira

Anomity now integrates with Jira. Connect a Jira Cloud site and Anomity files its findings as Jira issues in the project you choose, one issue per problem across the fleet, and keeps each issue in step with the finding: resolved when every device is clean, reopened if it comes back. It is available today to every organization, from the Jira card in the Integrations section of Settings in the Anomity console, alongside ClickUp, which shipped in the same release.

This post covers what Anomity files and when, what an issue looks like, how setup works, and the per-organization SLA response windows that shipped with it.

Why Jira, and why now

An alert gets attention; a ticket gets an owner. The findings Anomity raises on the endpoint, an MCP server nobody vetted, a secret sitting in an agent config, an extension with more reach than it needs, are rarely fixed by the security team itself. They are fixed by a platform team, an IT team or the developer whose laptop it is, and those teams plan their work in a tracker. Until now the only way across was to copy a finding into Jira by hand.

The Jira card had said coming soon in the Integrations catalog for a while. This release gives it a backend, and gives ticketing as a whole a shape every later tracker reuses, which is how Zendesk followed two days later.

What Anomity files, and when

There are two ways in, and both go through the same create path.

Ticketing files findings. A rule that matches hook decisions or audit events has no finding to open an issue for, and the channel row reports that rather than failing silently.

One issue is one problem, not one row

Anomity stores findings one row per device, because that is what remediation needs. A tracker needs the opposite. If an unvetted MCP server is configured on 37 laptops, the useful ticket is one issue that lists 37 machines, not 37 issues that bury the backlog. Anomity derives a device-independent identity for each finding and groups on it, so the same configuration problem across the fleet becomes one issue. The work of approving or removing that server is the subject of our guide to building an MCP server registry.

Grouping is refused where it would mislead. A secret pasted into an AI site, a session that bypassed a guard or an agent modifying its own configuration is an incident, not a state, and two people pasting two different secrets are two incidents. Those stay one issue each.

What an issue contains

• A title prefixed with Anomity, with the device count when the issue spans the fleet.
• The facts: severity, policy, finding type, and the agent, MCP server and attack path where they apply.
• Affected devices, listed by name up to 20, then a count.
• Details from a reviewed allowlist of fields, such as the file path, server name, transport, permission or CVE. Anything not on the list is dropped, because a ticket body leaves Anomity entirely. Secret values never appear: they are redacted on the endpoint, and the allowlist is tested against secret-shaped fields. Our write-up on how MCP servers expose enterprise secrets shows why that line matters.
• Remediation steps, numbered, with links that work from outside the console, and a link back to the finding.
• Labels: anomity, one for the finding type, any extra labels you set on the connection, and a unique marker label Anomity uses to find its own issue again.

What it does with ticket state

Filing is half of it. An issue that stays open after the problem is fixed, or stays closed after it comes back, teaches people to ignore the tracker. Every hour, Anomity reconciles each issue against its findings:

• Resolves the issue once every finding in its group has cleared across the fleet. Jira workflows are per project, so Anomity reads the transitions the issue actually offers and picks one into a done status. If the workflow has no route to done, Anomity comments on the issue saying so, rather than leaving it silently open.
• Reopens it if the finding returns.
• Comments when the affected device list grows or shrinks, so the assignee sees progress without opening Anomity.

The sync runs one way. Closing the Jira issue does not clear the finding: a finding clears when the device stops showing the problem, which is the only signal Anomity trusts.

Queued, and never duplicated

Ticket work is queued and delivered every minute, so a Jira outage never slows the path that receives device snapshots, and a rate limit never drops a finding. Creating an issue is not idempotent, and a timeout is exactly the moment you cannot know whether it landed. So Anomity claims the group before it creates, stamps the issue with its marker label, and recovers an uncertain create by searching Jira for that marker, never by posting again. Concurrent workers on one group produce one issue.

How setup works

1. Create a dedicated Jira service account with access to the project Anomity will file into, and create an API token for it in your Atlassian account settings, under Security and API tokens.
2. In Anomity, open Settings, go to the Integrations section and choose Manage on the Jira card. Enter the site URL (your-team.atlassian.net), the account email and the token.
3. Anomity verifies the credential against Jira before storing anything. Once it is accepted, pick the project and the issue type from lists Jira returns, and optionally add extra labels.
4. File a first issue with Create ticket on any finding, then select the Jira destination on the notification rules that should file automatically.

The token is encrypted with AES-256-GCM and is never returned by any API, not even masked. A Jira API token cannot be scoped: it carries every permission of the account that created it, which is why the first step is a service account and not a person. Anomity re-validates the connection every six hours, and only an authorization failure changes the card to show that it needs reconnecting. If that happens, queued work is held for up to seven days, and reconnecting delivers it.

Two limits to know: Jira Cloud only, on atlassian.net, with Jira Data Center and Server not supported; and no bulk create from the findings list yet, so automatic filing goes through rules.

Per-organization SLA response windows

A ticket needs a clock. Anomity has always measured how long a finding stays open against a response window per severity, but every organization ran on the same hardcoded set. Now an organization owner can set its own in Settings.

Overrides are partial: tightening critical to 24 hours leaves the other three on the defaults, and they keep following any future change to those defaults. Values run from one hour to one year. The windows are resolved on the server, so the findings page, the queue and the scheduled digest can no longer disagree about what is past SLA. My Queue was rebuilt around them: findings assigned to you are ordered by time left in their window, with how long ago a breached one passed it, next to the open critical and high findings nobody owns.

How Anomity and Jira fit together

Jira is where remediation gets planned, assigned and tracked. Anomity is where the AI on the fleet becomes visible: the Endpoint Sensor inventories agents, MCPs, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes; the Browser Sensor covers AI web services and the accounts used in them; and cloud discovery reads the OAuth grants held by AI applications. On agents that expose a hook, Anomity decides allow, deny or log before a tool call runs. The integration hands the findings that need a person to the place that person already works, and keeps the record honest as the fleet changes. If Atlassian is also part of your AI estate, the Atlassian integration reads the other direction: the AI inside your Atlassian organization.

Anomity complements the network, EDR, DLP, GRC and SIEM stack rather than replacing any of it, collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see your own findings become Jira issues, book a 30-minute demo.