Anomity Integrates with ClickUp
- Anomity now files findings into ClickUp. Connect a workspace with an API token, pick a List, and findings become ClickUp tasks, by hand from the finding panel or automatically from any notification rule.
- One task per problem across the fleet. The same unvetted MCP server on many laptops is one task with a device list; per-incident events such as a pasted secret stay one task each.
- Tasks follow the finding: Anomity completes the task when every affected device is clean, reopens it if the finding returns, and comments as the device list changes.
- Task bodies are markdown: the facts, the affected devices, a reviewed set of details, numbered remediation steps and a link back to the finding. Secret values never reach ClickUp.
- Delivery is queued and duplicate-safe, and the token is verified before it is stored, encrypted and never returned.
- ClickUp shipped in the same release as Jira and shares its whole pipeline, so the two behave the same way.
Anomity now integrates with ClickUp. Connect a ClickUp workspace and Anomity files its findings as tasks in the List you choose, one task per problem across the fleet, and keeps each task in step with the finding. It is available today to every organization, from the ClickUp card in the Integrations section of Settings in the Anomity console. It shipped in the same release as the Jira integration, and the two share one pipeline.
Why ClickUp, and why now
Not every team that fixes an AI security finding lives in Jira. Plenty of IT and platform teams plan their week in ClickUp, and a finding that arrives there as a task, with the machines, the steps and a link, gets picked up the same way as everything else on the board. ClickUp was one of two ticketing cards marked coming soon in the Anomity catalog. This release makes both of them real.
What Anomity files, and when
Admins can create a task from any finding with the Create ticket button on the finding panel. For automatic filing, connecting ClickUp adds a ticketing destination that any notification rule can select, next to Slack channels and webhooks, so the existing triggers, severity filters and device-tag filters decide what gets filed. Ticketing files findings only; a rule matching hook decisions or audit events has nothing to open a task for and says so on the channel row.
Tasks are grouped by problem, not by device. An unvetted MCP server configured on many laptops is one task listing those machines, which is the shape of the work: approve the server or remove it, as our guide to building an MCP server registry describes. Events that are incidents in their own right, such as a secret pasted into an AI site or an agent modifying its own configuration, are kept as one task each.
| In the task | What it holds |
|---|---|
| Name | Prefixed with Anomity, with the device count when the task spans the fleet. |
| Description (markdown) | Severity, policy, finding type, the agent, MCP server and attack path where they apply, the affected devices (up to 20 by name, then a count), a reviewed allowlist of technical details, numbered remediation steps and a link back to the finding. |
| Tags | anomity, one for the finding type, any extra tags you set on the connection, and a unique marker tag. |
The description is built from an allowlist of fields because a task body leaves Anomity entirely. Anything not on the list is dropped, and secret values never appear: they are redacted on the endpoint before they reach Anomity at all.
What it does with task state
- Completes the task, using ClickUp's default complete status, once every finding behind it has cleared across the fleet.
- Reopens it, to open, if the finding returns.
- Comments when the affected device list grows or shrinks, without notifying everyone on the task.
Reconciliation runs every hour. The sync is one way: completing the task in ClickUp does not clear the finding, which clears only when the device stops showing the problem. Statuses in ClickUp are plain names defined per List rather than a workflow graph, which is why Anomity writes the default names rather than guessing at custom ones.
Delivery is queued and runs every minute, so a ClickUp outage never slows Anomity and a rate limit never drops a finding. Creating a task is not idempotent, so Anomity claims the problem before it creates the task and, if a create times out, searches the List for its marker tag rather than creating a second one. ClickUp tags must exist in the Space before they stick, so Anomity creates the Space tags first; without that, the marker would be silently dropped and the recovery would have nothing to find.
How setup works
- In ClickUp, open Settings, then Apps, and copy your API Token. It acts as the member who created it, so use an account whose access matches the Lists Anomity should file into.
- In Anomity, open Settings, go to the Integrations section and choose Manage on the ClickUp card. Paste the token.
- Anomity verifies it against ClickUp before storing anything. Once it is accepted, pick the List from a dropdown that covers every Space, Folder and folderless List, and optionally add extra tags.
- Create a first task with Create ticket on any finding, then select the ClickUp destination on the notification rules that should file automatically.
The token is encrypted with AES-256-GCM and never returned by any API, not even masked. Anomity only ever calls ClickUp's own API host, re-validates the connection every six hours, and changes the card to show that it needs reconnecting only on an authorization failure. While it does, queued work is held for up to seven days and delivered on reconnect. Bulk creation from the findings list is not available yet, so automatic filing goes through rules. The same findings can also open tickets in Zendesk, or start a Zapier automation for anything else.
How Anomity and ClickUp fit together
ClickUp is where the work gets owned and scheduled. 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. A skill that needs a review before it is allowed, the process in our playbook for vetting agent skills, is exactly the kind of finding that belongs on someone's board.
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 land in ClickUp, book a 30-minute demo.
Frequently asked questions
What does the Anomity ClickUp integration do?
It turns Anomity findings into ClickUp tasks in a List you choose and keeps each task in step with the finding. Admins can create a task from any finding with the Create ticket button, and any notification rule can select the ClickUp destination so matching findings are filed automatically. Anomity then completes, reopens and comments on the task as the finding changes across the fleet.
What credentials does Anomity need from ClickUp?
A ClickUp API token, which you find in ClickUp under Settings, Apps, API Token. Anomity verifies it against ClickUp before saving, stores it encrypted with AES-256-GCM, and never returns it through any API, not even masked. The token acts with the access of the ClickUp member who created it, so it is worth creating it from an account whose access matches the Lists Anomity should file into.
Where in ClickUp do tasks go?
Into one List you pick from a dropdown after the token is accepted. The picker walks every Space in the workspace, including Lists inside Folders and Lists that sit directly in a Space, so none are left out.
Will Anomity create a task for every laptop?
No. Findings are stored per device, but Anomity files one task per problem across the fleet, so an MCP server nobody vetted on dozens of laptops is one task listing those machines. Events that are incidents in their own right, such as two people pasting two different secrets into an AI site, stay separate tasks.
What happens to the task when the finding is fixed?
Anomity checks every hour. Once every finding behind a task has cleared, it sets the task to ClickUp's default complete status. If the finding returns, it sets the task back to open. When the list of affected devices grows or shrinks, it adds a comment, without notifying everyone on the task. The sync is one way: completing the task in ClickUp does not clear the finding in Anomity, because a finding clears when the device stops showing the problem.
Why does Anomity add tags to the List's Space?
Each task carries an anomity tag, a tag for the finding type, any extra tags you configure and a unique marker tag. ClickUp tags live at the Space level and are dropped if they do not exist there yet, so Anomity creates them in the Space first. The marker tag is how Anomity finds its own task again after an uncertain create, instead of creating a duplicate.
