--- title: "Anomity Integrates with Zendesk | Anomity Blog" description: "Anomity now opens Zendesk tickets for AI security findings as internal notes, over OAuth client credentials, and solves or reopens them as findings change." url: "https://anomity.ai/blog/anomity-zendesk-integration/" source: html --- Anomity Integrates with Zendesk Contents - Why Zendesk, and why now - What Anomity files, and when - What it does with ticket state - How setup works: an OAuth client in your own Zendesk What Anomity keeps, and what it does not - How Anomity and Zendesk fit together - Frequently asked questions 0% 6 min read Share - X.com - LinkedIn - Email - Copy URL - Copy markdown [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Anomity Integrates with Zendesk ![Anomity robot illustrating Anomity Integrates with Zendesk] Company # Anomity Integrates with Zendesk Anomity Research Anomity Research · Sep 10, 2026 · 6 min read Share: Copied TL;DR - Anomity now files findings into Zendesk . Connect with an OAuth client you create in your own Zendesk, pick a group, and findings become Zendesk tickets, by hand from the finding panel or automatically from any notification rule. - It is Anomity's first ticketing integration on OAuth , using the client credentials grant Zendesk recommends for server-to-server work. There is no API-token path, and no long-lived Zendesk token is stored: Anomity mints short-lived access tokens on demand. - Finding details go into the ticket as an internal note , never a public comment, so nothing is emailed to a requester. - One ticket per problem across the fleet , kept in step with the finding: solved when every device is clean, reopened if it returns, with an internal note when the device list changes. - Anomity sets tickets to solved, never closed , because a closed Zendesk ticket can no longer be changed. Once Zendesk closes a solved ticket on its own, a returning finding reopens in Anomity but not on that ticket. - Zendesk joins Jira and ClickUp on the same queued, duplicate-safe pipeline. Anomity now integrates with **Zendesk**. Connect your Zendesk with an OAuth client and Anomity files its findings as tickets in the group you choose, writes the details as an internal note, and keeps each ticket in step with the finding. It is available today to every organization, from the Zendesk card in the Integrations section of Settings in the Anomity console, the third ticketing integration after [Jira](https://anomity.ai/blog/anomity-jira-integration/) and [ClickUp](https://anomity.ai/blog/anomity-clickup-integration/), and the first on OAuth. ## Why Zendesk, and why now For many IT teams, Zendesk is where internal requests are worked: laptop problems, access requests, software approvals. A lot of AI security remediation looks exactly like that work. Remove an extension, rotate a key someone left in an agent config, approve or retire an MCP server on a few machines. Putting those findings in the queue the IT desk already triages gets them owned without asking anyone to learn a new tool. It also let us settle how Anomity should authenticate to a tracker when there is a better option than a pasted token. Jira and ClickUp take an API token that acts as the person who created it. For Zendesk we used OAuth from the start. ## What Anomity files, and when Admins can open a ticket from any finding with the **Create ticket** button on the finding panel. For automatic filing, connecting Zendesk adds a ticketing destination that any notification rule can select, so the existing triggers, severity filters and device-tag filters decide what is filed. Ticketing files findings only; a rule matching hook decisions or audit events has nothing to open a ticket for. When a finding needs a ping rather than an owner, the same rule can post it to [Slack](https://anomity.ai/blog/anomity-slack-app-integration/) or [Google Chat](https://anomity.ai/blog/anomity-google-chat-integration/) instead, or as well. Anything else, from an on-call page to a spreadsheet row, can run through the [Zapier app](https://anomity.ai/blog/anomity-zapier-integration/). Tickets are grouped by problem, not by device. The same unvetted MCP server on many laptops is one ticket listing those machines. Events that are incidents in their own right, such as a secret pasted into an AI site, stay one ticket each. In the ticket What it holds **Subject** Prefixed with Anomity, with the device count when the ticket spans the fleet. **Internal note** 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. Internal, so the requester is never emailed. **Group** The Zendesk group you picked when connecting. **Tags and external ID** anomity, one for the finding type, any extra tags you configure, and a unique marker, which is also set as the ticket's external ID. The note is built from an allowlist of fields because it 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. The case for keeping credentials out of every downstream system is the one we made in [secrets management for AI agents](https://anomity.ai/blog/secrets-management-for-ai-agents/). ## What it does with ticket state - Solves the ticket once every finding behind it has cleared across the fleet. - Reopens it, to open, if the finding returns. - Adds an internal note when the affected device list grows or shrinks. Anomity stops at **solved** and refuses to set **closed**, however the connection is configured. A closed Zendesk ticket can no longer be commented on, reopened or changed, so closing it would break every later update for that problem. The limit to know is that Zendesk closes solved tickets by itself once your account's retention window passes. After that, a finding that returns reopens in Anomity, but its closed ticket is left as it is and no new ticket is opened for it. A ticket a person closed by hand is treated the same way, and is not mistaken for a broken connection. Delivery is queued and runs every minute, so a Zendesk outage never slows Anomity and a rate limit never drops a finding. Each create carries an idempotency key, and an uncertain create is recovered by an exact lookup on the ticket's external ID rather than by posting again, so a timeout does not produce a duplicate. The sync is one way: solving the ticket in Zendesk does not clear the finding, which clears only when the device stops showing the problem. ## How setup works: an OAuth client in your own Zendesk This is not an app Anomity registers on your behalf. You create the OAuth client in your own Zendesk, so it is visible, rotatable and deletable there. - In Zendesk Admin Center, go to Apps and integrations, then APIs, then OAuth clients , and add a client. Create it while signed in as a dedicated service account: tokens minted for the client act with that user's permissions. - Change Client kind to Confidential . It defaults to Public, and a public client has no usable secret for this grant. - Set the scopes to tickets:read tickets:write groups:read . Copy the secret now: Zendesk shows it in full only once. - In Anomity, open Settings, go to the Integrations section and choose Manage on the Zendesk card. Enter your subdomain, the client identifier and the secret. - Anomity verifies the credential by minting a token before storing anything. Once it is accepted, pick the group tickets should go to, and optionally add extra tags. The step-two trap is the one we hit ourselves when we verified the connector end to end against a real Zendesk account: Zendesk answers a public client with a flat invalid_client, which reads exactly like a mistyped secret. Anomity's setup form now walks through the steps in order and names the likely cause when Zendesk rejects the credential. ### What Anomity keeps, and what it does not Anomity stores the client identifier and the secret, encrypted with AES-256-GCM, and never returns the secret through any API. It does not store an access token. The grant returns no refresh token, so Anomity mints a short-lived access token when it needs one and holds it in memory only. When you rotate the secret, Anomity validates the new one with a fresh token rather than a cached one, so a wrong secret is caught at save time instead of failing later. To cut Anomity off, delete the OAuth client in Zendesk or disconnect in Anomity. Anomity re-validates the connection every six hours, and only an authorization failure marks the card as needing to reconnect; queued work is held for up to seven days and delivered on reconnect. It is the same principle behind the [Okta integration](https://anomity.ai/blog/anomity-okta-for-ai-agents-integration/), which signs with a key instead of asking for an API token: a machine that acts on your behalf should have a credential you can see, scope and revoke, as our [guide to non-human identity governance](https://anomity.ai/blog/non-human-identity-governance-guide/) argues. ## How Anomity and Zendesk fit together Zendesk is where the IT desk owns and closes work. 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 turns the findings that need a hand on a keyboard into tickets the desk already knows how to work, and keeps them honest as the fleet changes. 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 arrive in your Zendesk, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What does the Anomity Zendesk integration do? It opens Zendesk tickets for Anomity findings in a group you choose and keeps each ticket in step with the finding. Admins can open a ticket from any finding with the Create ticket button, and any notification rule can select the Zendesk destination so matching findings are filed automatically. Anomity then solves, reopens and adds internal notes to the ticket as the finding changes across the fleet. What does Anomity need from Zendesk? Your Zendesk subdomain and an OAuth client created in your own Zendesk Admin Center, under Apps and integrations, APIs, OAuth clients. You paste the client identifier and secret into Anomity. The client must be set to Confidential, and it needs the tickets:read, tickets:write and groups:read scopes. Anomity verifies the credential by minting a token before saving, stores the client secret encrypted with AES-256-GCM, and never returns it through any API. Why OAuth client credentials instead of a Zendesk API token? Client credentials is the grant Zendesk recommends for server-to-server integrations, and it means no long-lived bearer token sits in Anomity. Access tokens are minted on demand, kept in memory only and expire on their own. The OAuth client is registered in your Zendesk, not by Anomity, so you can see it, rotate its secret and delete it there. We did not build an API-token path. Why does setup fail with invalid_client even though I copied the secret correctly? The most common cause is that the OAuth client's Client kind is still set to Public, which is Zendesk's default. A public client has no usable secret for the client credentials grant, and Zendesk reports it with the same invalid_client error as a mistyped secret. Change Client kind to Confidential. Anomity's setup form calls this out and names the likely cause when Zendesk rejects the credential. Can requesters or customers see the finding? No. Anomity writes the finding into the ticket as an internal note, not a public comment, because a public comment emails the ticket's requester. Later updates, such as a change in the affected device list, are internal notes too. Why does Anomity set tickets to solved and never closed? Because a closed Zendesk ticket is permanent: it cannot be commented on, reopened or changed. If Anomity closed tickets, a finding that came back could never be reflected on its ticket. Anomity therefore stops at solved, even if a different status is configured. Zendesk itself closes solved tickets after your account's retention window, and once that happens, a finding that returns reopens in Anomity but its closed ticket is left as it is. Does the integration change anything else in Zendesk? It creates tickets in the group you chose, sets their status, adds internal notes and applies tags, and it reads groups to populate the picker. It does not touch users, organizations, macros or settings. Each ticket carries an anomity tag, a tag for the finding type, any extra tags you configure, a unique marker tag, and a matching external ID that Anomity uses to find its own ticket again. ## Related posts [Company ### Anomity Integrates with ClickUp Anomity now opens ClickUp tasks for AI security findings, one per issue across the fleet, and completes or reopens them as the finding clears or returns. Anomity Research · Sep 8, 2026 · 5 min](https://anomity.ai/blog/anomity-clickup-integration/) [Company ### Anomity Integrates with Jira Anomity now opens Jira issues for AI security findings, one per issue across the fleet, and closes or reopens them as findings clear or return. Plus SLA windows. Anomity Research · Sep 8, 2026 · 7 min](https://anomity.ai/blog/anomity-jira-integration/) [Company ### Anomity Integrates with Slack The Anomity Slack app: install it once, pick channels from a list, and get AI security findings and digests in Slack, with delivery health you can see. Anomity Research · Aug 25, 2026 · 7 min](https://anomity.ai/blog/anomity-slack-app-integration/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Anomity Integrates with Zendesk", "description": "Anomity now opens Zendesk tickets for AI security findings as internal notes, over OAuth client credentials, and solves or reopens them as findings change.", "datePublished": "2026-09-10", "dateModified": "2026-09-10", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/anomity-logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/anomity-zendesk-integration/", "relatedLink": [ "https://anomity.ai/blog/anomity-clickup-integration/", "https://anomity.ai/blog/anomity-jira-integration/", "https://anomity.ai/blog/anomity-slack-app-integration/" ] }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/anomity-zendesk-integration.png", "width": 1200, "height": 630 }, "articleSection": "Company", "wordCount": 1191, "timeRequired": "PT6M", "inLanguage": "en", "url": "https://anomity.ai/blog/anomity-zendesk-integration/", "keywords": "Zendesk integration for AI security findings, Zendesk, Integrations, Ticketing, OAuth, Remediation, Security Operations, Agent Governance" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What does the Anomity Zendesk integration do?", "acceptedAnswer": { "@type": "Answer", "text": "It opens Zendesk tickets for Anomity findings in a group you choose and keeps each ticket in step with the finding. Admins can open a ticket from any finding with the Create ticket button, and any notification rule can select the Zendesk destination so matching findings are filed automatically. Anomity then solves, reopens and adds internal notes to the ticket as the finding changes across the fleet." } }, { "@type": "Question", "name": "What does Anomity need from Zendesk?", "acceptedAnswer": { "@type": "Answer", "text": "Your Zendesk subdomain and an OAuth client created in your own Zendesk Admin Center, under Apps and integrations, APIs, OAuth clients. You paste the client identifier and secret into Anomity. The client must be set to Confidential, and it needs the tickets:read, tickets:write and groups:read scopes. Anomity verifies the credential by minting a token before saving, stores the client secret encrypted with AES-256-GCM, and never returns it through any API." } }, { "@type": "Question", "name": "Why OAuth client credentials instead of a Zendesk API token?", "acceptedAnswer": { "@type": "Answer", "text": "Client credentials is the grant Zendesk recommends for server-to-server integrations, and it means no long-lived bearer token sits in Anomity. Access tokens are minted on demand, kept in memory only and expire on their own. The OAuth client is registered in your Zendesk, not by Anomity, so you can see it, rotate its secret and delete it there. We did not build an API-token path." } }, { "@type": "Question", "name": "Why does setup fail with invalid_client even though I copied the secret correctly?", "acceptedAnswer": { "@type": "Answer", "text": "The most common cause is that the OAuth client's Client kind is still set to Public, which is Zendesk's default. A public client has no usable secret for the client credentials grant, and Zendesk reports it with the same invalid_client error as a mistyped secret. Change Client kind to Confidential. Anomity's setup form calls this out and names the likely cause when Zendesk rejects the credential." } }, { "@type": "Question", "name": "Can requesters or customers see the finding?", "acceptedAnswer": { "@type": "Answer", "text": "No. Anomity writes the finding into the ticket as an internal note, not a public comment, because a public comment emails the ticket's requester. Later updates, such as a change in the affected device list, are internal notes too." } }, { "@type": "Question", "name": "Why does Anomity set tickets to solved and never closed?", "acceptedAnswer": { "@type": "Answer", "text": "Because a closed Zendesk ticket is permanent: it cannot be commented on, reopened or changed. If Anomity closed tickets, a finding that came back could never be reflected on its ticket. Anomity therefore stops at solved, even if a different status is configured. Zendesk itself closes solved tickets after your account's retention window, and once that happens, a finding that returns reopens in Anomity but its closed ticket is left as it is." } }, { "@type": "Question", "name": "Does the integration change anything else in Zendesk?", "acceptedAnswer": { "@type": "Answer", "text": "It creates tickets in the group you chose, sets their status, adds internal notes and applies tags, and it reads groups to populate the picker. It does not touch users, organizations, macros or settings. Each ticket carries an anomity tag, a tag for the finding type, any extra tags you configure, a unique marker tag, and a matching external ID that Anomity uses to find its own ticket again." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Anomity Integrates with Zendesk", "item": "https://anomity.ai/blog/anomity-zendesk-integration/" } ] } ```