Anomity Integrates with Google Chat
- Anomity now integrates with Google Chat. Add the Anomity app to a Chat space, enter the code it posts there in Settings, Integrations, and findings and digests that match your notification rules arrive in that space as cards.
- Every rule, filter and digest you already have works unchanged. Linking a space creates its notification channel for you, so there is no second step.
- Findings arrive as cards with the severity, what was found, the device where relevant, and a button straight into the right console view. A burst of findings from one rule becomes one message in a thread, and daily or weekly digests summarise new findings, SLA breaches and first-seen MCP servers, AI tools and skills.
- A space is linked by a claim code written only into that space, never by the installer's email domain, because one Anomity Chat app serves every customer and a domain proves nothing.
- Ownership of the space is re-checked immediately before every post, inbound events from Google are verified down to the audience of the signed token, and the app never reads messages in the space.
- It is the same notification pipeline that drives the Slack app and webhooks, now reaching teams that work in Google Workspace.
Anomity now integrates with Google Chat. Add the Anomity app to a Chat space, enter the short code it posts there, and the findings and digests your notification rules select start arriving in that space as cards. The Google Chat card is under Settings, Integrations in the Anomity console. One step remains before every customer can add the app to their own spaces: Google reviews the Anomity app for its Google Workspace Marketplace listing, and the app reaches workspaces outside Anomity once that listing is live.
This post covers what arrives in the space, why linking a space takes a code, and the checks that keep one organization's findings out of another's space.
Why Google Chat, and why now
Plenty of security teams live in Google Workspace rather than Slack. For them, the option until now was a generic webhook with a relay in front of it, which is not a first-class place for a finding to land. Google Chat is where those teams already coordinate, so it is where an alert about a new MCP server or a blocked tool call should show up.
Google Chat joins the same notification pipeline as the Slack app. The rules, filters and digests you have already written work unchanged; a Chat space is simply another destination they can point at.
What arrives in the space
| Message | When | What it shows |
|---|---|---|
| Finding card | A notification rule matches one event | Severity icon and policy name, severity, the description, the device where relevant, a button to the matching console view, and the rule that sent it |
| Roll-up card | One rule matches a burst of events at once | A count with a severity breakdown and a capped list of findings, posted in a thread keyed to that rule so repeat bursts collect in one place |
| Digest card | A digest rule's daily or weekly schedule | New findings by severity, total open, how many are past SLA, MCP servers, AI tools and skills first seen on the fleet, enrolled devices and the change since the last digest, and a button to review |
The button goes where the reader needs to be: a policy finding opens the findings page, a first-seen MCP server opens the MCP inventory, a new AI tool opens the agent registry, and a guardrail decision at the agent hook opens the audit trail. Every value that reaches a card is escaped first, because finding descriptions carry file paths, MCP command lines and policy names that can contain angle brackets.
The design problem: one app, every customer
Google Chat works differently from Slack in one way that shaped the whole integration. When a Slack workspace installs an app, Slack mints a token for that workspace, so the token itself says which customer a channel belongs to. A Google Chat app has no such token: one Anomity Chat app identity serves every customer, and nothing about it says which customer a given space belongs to.
So the link between a space and an Anomity organization has to be established explicitly and proved. The shortcut would be to match the email domain of whoever added the app. We do not, and the reason is general enough to be worth stating: an email domain is not proof of anything. It is unverified, it can collide, and subdomains and vanity domains make 'exactly one matching organization' false. The installer's domain is recorded only as a hint the administrator can recognise, never as authorization.
How setup works
- In Google Chat, open the space your team uses for security alerts and add the Anomity app to it.
- Anomity posts an eight-character code into the space. The alphabet leaves out look-alike characters such as O and 0, so a code read off a phone is not mistyped. Until the code is entered, nothing else is posted there.
- Within 24 hours, an Anomity administrator opens Settings, Integrations, Google Chat and enters the code. Possession of the code proves membership of the space, because the only place it was ever written is the space itself.
- The space is linked, and Anomity creates its notification channel automatically. A linked space is the destination, so choosing one would be a step with exactly one answer. Point any rule or digest at it.
An expired code is fixed by removing the app from the space and adding it again. A wrong, expired or already-used code all get the same answer, so someone guessing codes cannot learn whether a space exists or who owns it. Re-adding the app to a space that is already linked does not reset it, so nobody who can remove and re-add the app can detach a space from its organization and claim it themselves.
The checks behind every post
- Ownership is re-checked immediately before every post, as well as when a channel is created or tested. A notification that started before an administrator unlinked a space cannot land in it afterwards.
- Inbound events from Google are verified before anything in them is read: the signed bearer token, its issuer and its audience. Google signs events for every Chat app with the same keys, so the audience check is what distinguishes Anomity's app from any other developer's.
- The app never reads your conversations. It posts as itself with Google's bot scope for Chat apps, acts only on being added to or removed from a space, and acknowledges and ignores messages and card clicks.
- Each space belongs to one organization. A space can be linked once, and the console only ever lists your own organization's spaces.
- Unlinking is clean. Unlinking a space stops the posts and removes its channel; the app stays until you remove it in Chat. Removing the app in Chat drops the link and its channels on our side.
How Anomity and Google Chat fit together
Google Chat is where your team talks; Anomity is what tells it something on the fleet needs attention. The Endpoint Sensor inventories agents, MCP servers, extensions, plugins, skills, secrets, hooks, CLIs and local LLM runtimes on every managed device; the Browser Sensor covers AI web services and the accounts and secrets used in them; and cloud discovery reads the AI applications holding OAuth grants in Google Workspace and GitHub. On agents that expose a hook, Anomity decides allow, deny or log before a tool call runs. The Chat integration puts the part your rules select in front of the people who act on it, which in the first minutes of an AI agent incident is the difference between a finding and a response.
Chat is for people, so it carries what your rules choose. A finding that needs an owner can open a ticket in Jira, and a SIEM that should see every event gets a firehose of its own through Datadog Cloud SIEM forwarding, Rapid7 InsightIDR, or any collector over OpenTelemetry. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see your own fleet's findings land in a Chat space, book a 30-minute demo.
Frequently asked questions
What does the Anomity Google Chat integration do?
It makes a Google Chat space a destination for Anomity notifications. Once a space is linked, any notification rule that targets it posts matching findings there as cards, and scheduled digest rules post their daily or weekly summary there. It covers the same events as Anomity's other notification channels: policy findings, first-seen MCP servers, skills and AI tools, AI applications found by cloud discovery, guardrail decisions and console audit events, whichever your rules select.
How do I connect a Google Chat space?
Add the Anomity app to the space in Google Chat. Anomity posts an eight-character code into the space. An Anomity administrator enters that code under Settings, Integrations, Google Chat within 24 hours, and the space is linked. Linking creates the space's notification channel automatically, so your rules can route to it straight away.
Can every customer add the Anomity app to Google Chat today?
Not yet. Google Chat apps reach customers through a Google Workspace Marketplace listing, which Google reviews before it is published. The integration itself has shipped in the Anomity console; the listing is the remaining step, and until it is live the app cannot be added to spaces in workspaces outside Anomity. Customers who need findings in Google Chat before then can route them through a webhook in the meantime.
Why a claim code instead of linking automatically?
Because one Anomity Chat app serves every customer, so nothing about the app itself says which customer a space belongs to. Matching the installer's email domain would be one step shorter, but a domain is unverified, it can collide, and subdomains and vanity domains break the assumption of exactly one match. The code is written only into the space itself, so entering it proves the person linking it can see that space.
What do the messages look like?
A single finding is a card headed with a severity icon and the policy name, the severity as subtitle, the description, the device when there is one, a button to the matching console view (the finding, the MCP server or skills inventory, the AI tools registry, or the audit trail), and the rule that sent it. When one rule matches several findings at once, they are grouped into one card with a severity breakdown and threaded under that rule, so a noisy rule does not fill the space.
What is in a digest?
A digest rule posts on a daily or weekly cadence: the number of new findings by severity, the total still open, how many are past SLA, the MCP servers, AI tools and skills seen for the first time on the fleet, the number of enrolled devices and how that changed, and a button to review the new findings.
Can the Anomity app read our Chat conversations?
No. The app posts as itself using Google's bot scope for Chat apps, and the only inbound events it acts on are being added to or removed from a space. Messages and card clicks are acknowledged and ignored. Card content is escaped before posting, so a file path or command line in a finding cannot inject markup into the space.
What happens when a space is unlinked or the app is removed?
Unlinking a space in Anomity stops the posts and removes the notification channel pointing at it; the app stays in the space until someone removes it in Google Chat. Removing the app from the space in Google Chat drops the link and its channels on Anomity's side. Either way, the next post is refused because ownership is checked immediately before every message.
Does Google Chat replace a SIEM feed?
No. Chat is for people, so it receives what your notification rules select. A SIEM should receive every event without depending on rules, which is what Anomity's SIEM forwarding does.
