Anomity Integrates with Zapier

Anomity now integrates with Zapier, in both directions. The Anomity app on Zapier starts a Zap when Anomity raises a new finding, sees a new MCP server or AI tool in the fleet, or blocks an agent action, and lets a Zap update, comment on or look up a finding with the connected person's own Anomity role. Zapier AI automations discovery points the other way: Anomity reads the Zaps in your Zapier account and finds the ones that feed company data, or input from anyone on the internet, to an AI model. Both live on one card under Settings, Integrations, Automation in the Anomity console.

This post covers both halves: what the app does, how it authenticates and how delivery works, then what discovery reads, what it flags, and what is still to come.

Why Zapier, and why now

Anomity already sends findings to a lot of places: Slack for the team channel, Jira, ClickUp and Zendesk for tickets, SIEMs such as Datadog Cloud SIEM or any OpenTelemetry collector, and a generic outbound webhook for everything else. Each is a fixed destination. Security teams keep asking for the long tail: Microsoft Teams, PagerDuty, Linear, ServiceNow, a Google Sheet. Zapier already connects to thousands of apps, so one Zapier app covers that tail without a native integration for each.

Zapier is also an AI surface in its own right, and one that sits outside the usual controls. A Zap can take a new lead from a CRM, send it to a model, and write the model's answer back into the CRM, every time it runs, with no person in between. It can take its input from a webhook URL or an inbound email address that anyone can send to. Put those together and you have a close cousin of the lethal trifecta: private data, untrusted content and the ability to act, assembled by a business user in a browser rather than deployed by an engineer. So the integration had to work both ways.

The Anomity app on Zapier

The Finding ID field offers a dropdown of recent open findings, so a Zap author does not copy IDs by hand. Trigger samples in the Zap editor are built from your own recent data by the same code that builds live events, so the fields you map are the fields a live event carries. The API behind the app, including every endpoint and every field, is documented in the Anomity Zapier API reference.

Typical Zaps

• New critical finding to Microsoft Teams or PagerDuty.
• New finding to a Linear or ServiceNow ticket, then Add Comment to Finding to write the ticket link back onto the finding.
• Ticket closed in that tool, then Update Finding Status to resolved in Anomity.
• New AI tool detected to a row in a Google Sheet, as a running log of what is arriving on the fleet.
• New blocked agent action to the on-call channel, as the first step of an AI agent incident response playbook.

What a trigger sends, and how it gets there

Every event carries the same allowlisted field set Anomity's SIEM integrations publish, with a schema version, plus a unique event ID, the time it occurred, a one-sentence description, the device hostname where there is one, and a link to the finding or item in the console. Fields that do not apply are absent rather than empty. A field is never renamed or removed without a new schema version, because customers' Zaps map those names.

Events are queued and delivered within about a minute, in batches of up to 100 events, and Zapier starts one run per event. Delivery is at least once, so the event ID is the key for recognising a repeat. Each Zap has its own queue, so one failing Zap never holds back another. Timeouts, rate limits and server errors are retried, honouring Retry-After, up to 10 attempts; if Zapier answers that a Zap no longer exists, Anomity deletes the subscription; and events that cannot be delivered within 7 days are discarded.

How it authenticates: your own role, nothing more

1. In a Zap, add an Anomity step and connect an account. Zapier opens the Anomity sign-in, the same login a person uses for the console.
2. Anomity issues a token for the Zapier API only. The API verifies it itself and accepts no token minted for any other purpose. A suspended person or organization is refused on the next call.
3. Turn the Zap on. Subscribing a trigger needs an Anomity admin, because it is the decision that the organization's events leave for a third party: the same bar as connecting a SIEM.

There is no separate API key. A connection can never do more than the person who connected it can do in the console: viewers read findings and samples, analysts update a status or comment, and below admin, ignoring or dismissing a finding needs a reason and an end date at most 90 days away, exactly as on the Findings page. A Zap and the console run the same rules and write the same audit rows, and every change a Zap makes appears in the Audit Log marked via Zapier. That keeps the record intact for an AI agent audit trail when the hands on the finding belong to an automation.

The hook address Zapier generates is a capability: anyone holding it can start that Zap. Anomity stores it encrypted, never returns it in a listing, audit row or error message, and only ever sends to Zapier's own hook host, checked when the Zap subscribes and again before every send. At most 25 Zaps per organization receive events at once, and Settings, Integrations, Automation lists every one of them: its trigger and filters, who turned it on and when, the last delivery, delivered, dropped and queued counts, and the last error. An admin can disconnect one Zap or all of them, which gives a straight answer to a question auditors ask: where do our security findings go?

Discovering AI automations in Zapier

None of Anomity's other collectors sees what a Zap does. The Endpoint Sensor sees the Zapier MCP server configured in a developer's agent, and the Browser Sensor sees a sign-in to zapier.com. Cloud discovery reads the OAuth grants AI apps hold in Google Workspace and GitHub, and the AI settings of code hosts such as GitLab. The automation itself, which apps feed which model and where the output goes, lives in Zapier, and it is exactly the kind of quiet adoption we described in shadow AI detection.

The discovery source, Zapier (AI automations), reads one list: the Zaps visible to the connected user, including shared ones, with their steps, the apps behind them and the connections they use. Only Zaps with at least one AI step, such as OpenAI, Anthropic or AI by Zapier, become rows. The rest are counted on the account row.

What it never reads: the values inside a step, which hold prompts and mapped customer data, and Zap run history, which is the data itself. A test in the product asserts that no step value reaches an Anomity row. The connector never creates, edits, turns off or runs a Zap.

Zapier exposes no API for its MCP servers, so the endpoint is the only place that half of the picture can come from. The account row joins Zapier to the managed fleet, as notes: devices with the Zapier MCP server configured, and the AI tools that reach it; devices where the Endpoint Sensor already found a Zapier AI Actions key, which raises its own finding (the pattern is covered in our guide to secrets management for AI agents); and sign-ins to zapier.com on a personal or external account, from the Browser Sensor.

What it flags

Zapier findings run through Anomity's cloud AI posture policy type, with a seeded template, Zapier automations that feed AI. Only Zaps that are switched on raise findings; a Zap that is off keeps its inventory and notes. On by default:

• Untrusted input to AI. The Zap starts from an inbound webhook or email and passes it to an AI step. There is no sign-in in front of either, so anyone who knows the address writes the prompt.
• Untrusted input, AI, then a write. The same, followed by a write into another app. An injected instruction in that input can change company data with no person in between, the textbook case of indirect prompt injection.
• Sensitive source to AI. Data from a business system that holds customer or company records goes to a model provider every time the Zap runs.

Off by default, to turn on where your policy calls for it: AI output written into another app without review, an AI vendor not on your allowlist, a connection signed in outside your domains, which offboarding does not reach, and API by Zapier. Findings route like every other Anomity finding, to the SIEM, Slack, Jira or straight back into a Zap through the Anomity app.

How it connects

1. In Anomity, an admin opens the Zapier card under Settings, Integrations, Automation and chooses Inventory AI automations.
2. Sign in to Zapier and approve two scopes: your profile, so the inventory can say whose view it is, and read access to the Zaps you can see in the account. Connect as a Zapier owner or super admin for the widest view.
3. Anomity reads the Zaps, and the first sync starts in the background.

A grant without the account-wide Zap read is refused. Tokens are stored encrypted. Reconnecting as the same Zapier user replaces the stored tokens rather than creating a second connector. If the first page of Zaps cannot be read, the sync fails with the fix in the message and the last good inventory stays in place.

Current limits

• Discovery cannot be connected yet. Zapier issues credentials for the API it reads only to integrations that are public in its App Directory, and the Anomity app is in that review. Until it is public, the source shows as coming soon and the connect flow refuses. Nothing is wrong with your account: the credentials do not exist yet, and the source turns on when they do.
• The app is not yet in Zapier's public App Directory either. Until the listing review completes, ask your Anomity contact for access.
• Instant triggers only. There are no polling triggers, no 'finding resolved' trigger yet, and no triggers for audit events, new skills or discovered cloud apps. Each is a small addition, and we will add them as customers ask.
• Deliveries are not signed. Zapier offers no signature check for this kind of hook. The hook address is the secret, which is why Anomity encrypts it and pins delivery to Zapier's host.
• Discovery was built from Zapier's published API reference without a live account behind it, so some facts stay open until the first real connection, such as whether an owner's token sees members' private-folder Zaps. Each is coded to fail quietly: where Anomity is unsure, it raises nothing rather than a false finding, and the account row says 'Zaps visible to' the connected user, never 'all Zaps'.
• Some things have no public API at all: Zapier Agents, Zapier MCP servers and their tool calls, app restrictions, the Zapier audit log and who owns a Zap. The account row says so in a 'Not checked' note.

How Anomity and Zapier fit together

Zapier owns the automation platform and its controls, and it is good plumbing: it takes an Anomity event to wherever a team already works. Anomity is where the events come from, and it answers the security question about the automations themselves: which ones put company data, or input from anyone on the internet, in front of a model, and what do they do with the answer? 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 AI apps and platforms in your cloud tenants, now including Zapier. On agents that expose a hook, Anomity decides allow, deny or log before a tool call runs, and New Blocked Agent Action is that decision arriving in your Zap.

For high-volume streaming into a security data lake, a SIEM integration such as Rapid7 InsightIDR is still the better fit. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see the Zapier integration against your own fleet and Zapier account, book a 30-minute demo.