Google Chat Hardening Guide

Productivity Last updated: 2026-05-29

Security hardening for Google Chat — app & webhook controls, external chat & spaces, file sharing, history & retention, and audit logging & content reporting.

Product Docs API Docs Hardening Guide

Code Packs: Terraform CLI Scripts SDK Database

View:

Google Chat — Requirements Cheat Sheet

All controls condensed. Click any requirement to jump to full implementation details.

Requirement	Description	Rationale

Overview

Google Chat is the messaging surface of Google Workspace, and an increasingly common path for data exfiltration, phishing, and malware delivery that is monitored less rigorously than email. This guide hardens Chat-specific surfaces: which apps and webhooks can run inside conversations, whether users can chat or share spaces externally, file-sharing posture, history/retention for traceability, and the audit + content-reporting controls that turn Chat into a detection sensor.

This is a product guide within the Google Workspace platform. Platform-wide controls (authentication, OAuth app allowlisting, DLP engine, admin audit logging) live in the Google Workspace Common Controls hub and are referenced here rather than duplicated.

Intended Audience

Security engineers managing Google Workspace / Google Chat
IT administrators configuring Admin Console Chat settings
GRC professionals assessing collaboration-tool compliance (CISA SCuBA, SOC 2)
Incident responders monitoring messaging-based exfiltration

How to Use This Guide

L1 (Crawl): Essential controls for all organizations
L2 (Walk): Enhanced controls for security-sensitive environments
L3 (Run): Strictest controls for regulated industries

Scope

This guide covers Google Chat hardening in the Google Workspace Admin Console: Chat app & webhook installation controls, external chat and spaces restrictions, Chat file-sharing posture, history and Vault-based retention, and Chat audit logging & content reporting. Platform-wide authentication, OAuth allowlisting, the DLP engine, and admin-console audit logging are covered in the Google Workspace guide. Gmail and Drive are covered in their own product guides.

App & Integration Security
Data Security
Monitoring & Detection
Compliance Quick Reference

1. App & Integration Security

1.1 Restrict & Allowlist Google Chat Apps

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	2.5, 2.7
NIST 800-53	AC-3, CM-7
CIS Google Workspace	2.1

Description

Control which Google Chat apps (bots) and incoming webhooks users can add. Disable open installation, require an admin-curated Google Workspace Marketplace allowlist, and restrict incoming webhooks—each of which can read, post, and exfiltrate conversation content programmatically.

Rationale

Why This Matters:

Chat apps and webhooks run with delegated access to conversations and can silently forward messages or files to external endpoints
A malicious or over-permissioned Chat app is an OAuth-style data-exfiltration path that bypasses Drive/Gmail controls
Incoming webhooks post to spaces using a URL that, if leaked, lets anyone inject messages (phishing, social engineering)

Attack Prevented: Malicious Chat app installation, webhook abuse, data exfiltration via bot integrations

Prerequisites

Inventory of currently used Chat apps and webhooks
Business justification and owner for each approved app
Marketplace allowlist workflow (see Google Workspace OAuth App Allowlisting)

ClickOps Implementation

Step 1: Restrict Chat App Installation

Navigate to: Admin Console → Apps → Google Workspace → Google Chat → Chat apps
Set Allow users to install Chat apps to Off (or leave On only if paired with a Marketplace allowlist)
Set Allow users to add and use incoming webhooks to Off for the organization (enable only for a dedicated, audited OU if needed)
Click Save

Note: Chat apps must stay enabled at the top organizational unit for the Chat API to function. Use the Marketplace allowlist—not an OU block—to restrict which apps are usable.

Step 2: Curate the Marketplace Allowlist

Navigate to: Admin Console → Apps → Google Workspace Marketplace apps → Apps list
Click Google Workspace Marketplace allowlist → Add app to allowlist
Add only reviewed, business-justified Chat apps
Set the Marketplace settings so users can install allowlisted apps only

Time to Complete: ~30 minutes

Code Implementation

Code Pack: Terraform

hth-google-chat-1.01-restrict-chat-apps.tf View source on GitHub ↗

# Google Chat app installation is governed by two Admin Console settings that
# the googleworkspace provider does NOT expose directly:
#
#   1. Apps > Google Workspace > Google Chat > Chat apps
#      - "Allow users to install Chat apps" (On/Off)
#      - "Allow users to add and use incoming webhooks" (On/Off)
#   2. Apps > Google Workspace Marketplace apps > Apps list >
#      Google Workspace Marketplace allowlist  ("Add app to allowlist")
#
# This file creates the governance infrastructure that supports an allowlist
# workflow: a group whose members review and approve Chat app requests.

# Group that owns the Chat app review/approval workflow.
resource "googleworkspace_group" "chat_app_approvers" {
  email       = "chat-app-approvers@${var.primary_domain}"
  name        = "Chat App Approvers"
  description = "HTH 3.3 -- Members review and approve Google Chat app + webhook requests before they are added to the Marketplace allowlist"
}

# OU for users permitted to add incoming webhooks (L2: restrict webhooks to a
# small, audited population rather than the whole organization).
resource "googleworkspace_org_unit" "chat_webhooks_allowed" {
  count = var.profile_level >= 2 ? 1 : 0

  name                 = "Chat Webhooks Allowed"
  description          = "HTH 3.3 L2 -- Only users in this OU may add incoming webhooks in Chat; disable webhooks for the parent OU"
  parent_org_unit_path = var.target_org_unit_path
}

Validation & Testing

As a standard user, confirm a non-allowlisted Chat app cannot be installed
Confirm incoming webhook creation is blocked outside the approved OU
Review Reporting → Audit and investigation → Chat log events for app-related activity

Expected result: Only allowlisted Chat apps are usable; webhooks limited to approved users.

Compliance Mappings

Framework	Control ID	Control Description
SOC 2	CC6.1	Logical access security
NIST 800-53	CM-7	Least functionality
CIS Google Workspace	2.1	Control third-party apps and add-ons

2. Data Security

2.1 Restrict External Google Chat & Spaces

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	3.3
NIST 800-53	AC-3, AC-20
CISA SCuBA	GWS.CHAT.4.1v1
CIS Google Workspace	3.1.4.2.2

Description

Restrict Google Chat and spaces with people outside your organization. Either turn external chat off, or—if external collaboration is required—allow it only for allowlisted (trusted) domains, and apply the same restriction to externally shared spaces.

Rationale

Why This Matters:

Unrestricted external chat is a low-friction data-exfiltration channel that is monitored less rigorously than email
“Auto-accept chat invites from familiar contacts” can pull users into external conversations without an explicit decision
External spaces let outside members persist in a shared room with access to its files and history

Attack Prevented: Data exfiltration over Chat, social engineering via external messaging, unauthorized external collaboration

Real-World Incidents:

Messaging apps are an increasingly common exfiltration path (MITRE ATT&CK T1213.005, Data from Information Repositories: Messaging Applications)

Prerequisites

Defined list of trusted external domains
The shared Workspace Allowlisted domains list configured (Account → Domains)

ClickOps Implementation

Step 1: Restrict External Chat

Navigate to: Admin Console → Apps → Google Workspace → Google Chat → External chat settings
For Allow users to send messages outside your organization (a.k.a. Chat externally):
- To disable entirely: select Off
- To allow trusted partners only: select On, then check Only allow this for allowlisted domains
Uncheck Auto-accept chat invites from familiar contacts (L2+)
Click Save

Step 2: Restrict External Spaces

Navigate to: Apps → Google Workspace → Google Chat → External spaces
For Allow users to create & join spaces with people outside their organization: select Off, or On with Only allow users to add people from allowlisted domains checked
Click Save

Step 3: Manage the Allowlisted Domains

The Chat allowlist is the shared Workspace trusted-domains allowlist (also used by Drive, Sites, Classroom, Looker Studio)
Navigate to: Account → Domains → Allowlisted domains to add/remove trusted domains
Apply external-chat exceptions per organizational unit, not org-wide

Time to Complete: ~30 minutes

Code Implementation

Code Pack: Terraform

hth-google-chat-2.01-restrict-external-chat.tf View source on GitHub ↗

# External Google Chat is governed by Admin Console settings the googleworkspace
# provider does NOT expose directly:
#
#   Apps > Google Workspace > Google Chat > External chat settings
#     - "Allow users to send messages outside your organization" (On/Off)
#     - "Only allow this for allowlisted domains"
#     - "Auto-accept chat invites from familiar contacts"  (disable for L2+)
#   Apps > Google Workspace > Google Chat > External spaces
#     - "Allow users to create & join spaces with people outside their organization"
#     - "Only allow users to add people from allowlisted domains"
#
# The allowlist itself is the SHARED Workspace trusted-domains allowlist
# (Account > Domains > Allowlisted domains) -- the same allowlist used by Drive,
# Sites, Classroom, Chat, and Looker Studio.
#
# This file builds the supporting OU/group structure so external-chat access is
# an explicit, auditable exception rather than an org-wide default.

# Default OU: members are internal-only (configure "Chat externally = Off" here).
resource "googleworkspace_org_unit" "chat_internal_only" {
  name                 = "Chat Internal Only"
  description          = "HTH 4.3 -- External Chat and external spaces are OFF for this OU (organization default)"
  parent_org_unit_path = var.target_org_unit_path
}

# Exception OU: members may chat externally, but ONLY with allowlisted domains.
resource "googleworkspace_org_unit" "chat_external_allowlisted" {
  name                 = "Chat External Allowlisted"
  description          = "HTH 4.3 -- External Chat = On with 'Only allow this for allowlisted domains' for this OU"
  parent_org_unit_path = var.target_org_unit_path
}

# Group that approves which OUs/users receive the external-chat exception.
resource "googleworkspace_group" "chat_external_approvers" {
  email       = "chat-external-approvers@${var.primary_domain}"
  name        = "Chat External Approvers"
  description = "HTH 4.3 -- Members approve external Chat exceptions and curate the shared allowlisted-domains list"
}

Validation & Testing

As a standard user, attempt to message a non-allowlisted external address—delivery should be blocked
Attempt to add a non-allowlisted external user to a space—should fail
Confirm an allowlisted-domain partner can still chat

Expected result: External chat/spaces work only with allowlisted domains (or are fully disabled).

Compliance Mappings

Framework	Control ID	Control Description
CISA SCuBA	GWS.CHAT.4.1v1	External chat restricted to allowlisted domains
NIST 800-53	AC-20	Use of external systems
SOC 2	CC6.6	Boundary protection / external access
CIS Google Workspace	3.1.4.2.2	Ensure Google Chat externally is restricted to allowlisted domains

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	3.3
NIST 800-53	AC-3
CISA SCuBA	GWS.CHAT.2.1v1

Description

Limit which files users can share in Google Chat, separately for internal and external conversations. Per the CISA SCuBA baseline, external file sharing in Chat should be set to No files.

Rationale

Why This Matters:

File sharing in Chat is a data-loss avenue that is monitored less rigorously than email or Drive
Disabling external Chat file sharing removes an exfiltration path that DLP alone may not fully cover
Restricting internal sharing to Images only for sensitive OUs reduces accidental document leakage

Attack Prevented: Data exfiltration via Chat attachments, malware delivery through shared files

Prerequisites

Decision on internal sharing posture per organizational unit
DLP for Chat configured for residual risk (Google Workspace DLP)

ClickOps Implementation

Step 1: Configure Chat File Sharing

Navigate to: Admin Console → Apps → Google Workspace → Google Chat → Chat file sharing
Set External filesharing to No files (SCuBA GWS.CHAT.2.1v1)
Set Internal filesharing to Allow all files or, for sensitive OUs, Images only
Click Save

Note: Files shared in Chat are automatically scanned for viruses before delivery, but malware and DLP scanning do not replace a file-type restriction.

Time to Complete: ~15 minutes

Code Implementation

Code Pack: Terraform

hth-google-chat-2.02-restrict-chat-filesharing.tf View source on GitHub ↗

# Chat file-sharing limits are configured in:
#   Apps > Google Workspace > Google Chat > Chat file sharing
#     - "External filesharing" dropdown: Allow all files | Images only | No files
#     - "Internal filesharing" dropdown: Allow all files | Images only | No files
#
# The googleworkspace provider does NOT expose these dropdowns, so enforcement is
# ClickOps (SCuBA GWS.CHAT.2.1v1 requires External filesharing = "No files").
# This file creates an OU where the strictest file-sharing policy is applied,
# mirroring the Drive external-sharing pattern in control 4.1.

# OU for highly sensitive teams: configure "External filesharing = No files" and
# "Internal filesharing = Images only" here for the tightest Chat data boundary.
resource "googleworkspace_org_unit" "chat_no_file_sharing" {
  name                 = "Chat No External File Sharing"
  description          = "HTH 4.4 -- External Chat file sharing set to 'No files' for this OU (SCuBA GWS.CHAT.2.1v1)"
  parent_org_unit_path = var.target_org_unit_path
}

Validation & Testing

As a standard user, attempt to attach a file in an external conversation—should be blocked
Confirm internal sharing behaves per the configured posture
Review Chat log events for attachment_upload activity

Expected result: External Chat file sharing disabled; internal sharing matches policy.

Compliance Mappings

Framework	Control ID	Control Description
CISA SCuBA	GWS.CHAT.2.1v1	External Chat file sharing disabled
NIST 800-53	AC-3	Access enforcement
SOC 2	CC6.6	Boundary protection

2.3 Enforce Google Chat History & Retention

Profile Level: L2 (Walk)

Framework	Control
CIS Controls	8.2, 8.10
NIST 800-53	AU-2, AU-9, SC-7(10)
CISA SCuBA	GWS.CHAT.1.1v1, GWS.CHAT.1.2v1, GWS.CHAT.3.1v1

Description

Turn Chat history on by default, prevent users from changing their own history setting, force space history on, and use Google Vault to retain and legally hold Chat content for traceability and eDiscovery.

Rationale

Why This Matters:

History off means direct messages are deleted after 24 hours and cannot be retained by Vault—erasing the audit trail
Allowing users to change their history setting lets them obfuscate sensitive sharing (MITRE ATT&CK T1562.001, Impair Defenses)
Retention and legal holds preserve Chat evidence for investigations and dispute resolution

Attack Prevented: Audit-trail tampering, evidence destruction, insider data hiding

Prerequisites

Information-governance/retention requirements defined
Google Vault license (Business Plus or Enterprise editions)

ClickOps Implementation

Step 1: Enforce Chat History

Navigate to: Admin Console → Apps → Google Workspace → Google Chat → History for chats
Select History is ON
Uncheck Allow users to change their history setting
Click Save

Step 2: Enforce Space History

Navigate to: Apps → Google Workspace → Google Chat → History for spaces
Select History is ALWAYS ON
Click Save

Step 3: Configure Vault Retention & Holds

In Google Vault → Retention, create a Chat retention rule by organizational unit or for all spaces; set retention for DMs, group messages, and space messages
In Vault → Matters → Holds, place relevant accounts/OUs on a Chat hold (include spaces the user belongs to)
Note: holds never expire and override retention rules; Chat messages are kept 30 days after deletion

Time to Complete: ~45 minutes

Code Implementation

Code Pack: SDK Script

hth-google-chat-2.03-vault-chat-hold.py View source on GitHub ↗

from googleapiclient.discovery import build

vault = build('vault', 'v1', credentials=credentials)

# 1. Create a matter to own the hold (or reuse an existing matterId).
matter = vault.matters().create(body={
    'name': 'HTH Chat Retention',
    'description': 'HTH 4.5 -- preserves Google Chat content for legal/compliance hold',
}).execute()
matter_id = matter['matterId']

# 2. Place an org unit on hold for the Chat corpus, including space (room) messages.
hold = vault.matters().holds().create(matterId=matter_id, body={
    'name': 'HTH Chat Hold',
    'corpus': 'HANGOUTS_CHAT',
    'orgUnit': {'orgUnitId': 'id:03ph8a2z1example'},  # Admin SDK org unit ID
    'query': {'hangoutsChatQuery': {'includeRooms': True}},
}).execute()

print(f"Created Chat hold {hold['holdId']} on matter {matter_id}")

Validation & Testing

Confirm a standard user cannot toggle history off in a conversation
Verify the Vault retention rule and hold appear and cover the Chat corpus
Search Chat in Vault to confirm content is discoverable

Expected result: History enforced on; users cannot change it; Chat retained per policy.

Compliance Mappings

Framework	Control ID	Control Description
CISA SCuBA	GWS.CHAT.1.1v1	Chat history enabled
CISA SCuBA	GWS.CHAT.1.2v1	Users cannot change history setting
CISA SCuBA	GWS.CHAT.3.1v1	Space history enabled
NIST 800-53	AU-9	Protection of audit information
ISO 27001	A.12.4.2	Protection of log information

3. Monitoring & Detection

3.1 Enable Google Chat Audit Logging & Content Reporting

Profile Level: L1 (Crawl)

Framework	Control
CIS Controls	8.2, 8.5
NIST 800-53	AU-2, AU-6, IR-6
CISA SCuBA	GWS.CHAT.5.1v1, GWS.CHAT.5.2v1

Description

Monitor Google Chat through the Chat log events report (and Reports API / BigQuery export), and enable content reporting so users can flag malicious or inappropriate messages to admins across all conversation types.

Rationale

Why This Matters:

Chat is a phishing and malware-delivery channel; content reporting turns every user into a detection sensor (NIST IR-6)
Chat audit events (message_posted, attachment_upload, room_created, add_room_member) reveal exfiltration and rogue-space activity
Reporting requires Chat history to be enabled (2.3)

Attack Prevented: Undetected Chat phishing/malware, unmonitored data exfiltration, delayed incident response

Prerequisites

Chat history enabled (2.3)
Audit & Investigation admin privilege; BigQuery export for long-term retention (Google Workspace Audit Logging)

ClickOps Implementation

Step 1: Review Chat Log Events

Navigate to: Admin Console → Reporting → Audit and investigation → Chat log events
Filter by Event (e.g., attachment_upload, room_created) and date range
For advanced triage (Enterprise Standard/Plus): Security → Security center → Investigation tool, data source Chat log events

Step 2: Enable Content Reporting

Navigate to: Apps → Google Workspace → Google Chat → Content reporting
Enable Allow users to report content in Chat
Select all conversation type checkboxes (1:1, group, spaces) — SCuBA GWS.CHAT.5.1v1
Select all reporting categories — SCuBA GWS.CHAT.5.2v1
Click Save

Time to Complete: ~30 minutes

Key Chat Events to Monitor

Event	Detection Use Case
`attachment_upload`	Data exfiltration via Chat attachments
`message_posted`	Phishing / malicious link distribution
`room_created`	Rogue or external space creation
`add_room_member`	External users added to spaces

Code Implementation

Code Pack: CLI Script

hth-google-chat-3.01-chat-audit-events.sh View source on GitHub ↗

# Generate a Google Chat audit report for the last 7 days
gam report chat start -7d end today

# Filter to attachment uploads (potential data exfiltration via Chat)
gam report chat start -7d end today event attachment_upload

# Filter to space creation and external membership changes
gam report chat start -7d end today event room_created
gam report chat start -7d end today event add_room_member

# First-party alternative: Admin SDK Reports API via curl + OAuth bearer token
curl -s -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/chat?eventName=attachment_upload"

Code Pack: SDK Script

hth-google-chat-3.01-chat-audit-events.py View source on GitHub ↗

# Pull Google Chat audit events from the Admin SDK Reports API
# (applicationName='chat'). Verified event names include: message_posted,
# attachment_upload, room_created, add_room_member, remove_room_member.
from googleapiclient.discovery import build

reports = build('admin', 'reports_v1', credentials=credentials)

# All Chat attachment uploads in the last 7 days (potential data exfiltration).
resp = reports.activities().list(
    userKey='all',
    applicationName='chat',
    eventName='attachment_upload',
    startTime='2026-05-20T00:00:00Z',
).execute()

for activity in resp.get('items', []):
    actor = activity['actor'].get('email', 'unknown')
    for event in activity.get('events', []):
        print(f"{activity['id']['time']}  {actor}  {event['name']}")

Code Pack: DB Query

hth-google-chat-3.01-bigquery-chat-detection.sql View source on GitHub ↗

-- Surface users uploading an unusually high volume of Chat attachments
-- (potential data exfiltration through Google Chat).
SELECT
  actor.email,
  COUNT(*) AS attachments_uploaded
FROM `project.dataset.chat_logs`
WHERE event_name = 'attachment_upload'
  AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY actor.email
HAVING attachments_uploaded > 50
ORDER BY attachments_uploaded DESC;

-- Track Google Chat space (room) creation to spot rogue or external spaces.
SELECT
  actor.email,
  COUNT(*) AS spaces_created
FROM `project.dataset.chat_logs`
WHERE event_name = 'room_created'
  AND _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY actor.email
ORDER BY spaces_created DESC;

Validation & Testing

As a user, confirm the Report option appears on messages in every conversation type
Submit a test report and confirm it surfaces in the admin tooling
Run the Reports API / GAM query and confirm Chat events return

Expected result: Chat events are auditable; users can report content across all conversation types.

Compliance Mappings

Framework	Control ID	Control Description
CISA SCuBA	GWS.CHAT.5.1v1	Content reporting enabled for all conversation types
CISA SCuBA	GWS.CHAT.5.2v1	All reporting categories selected
NIST 800-53	IR-6	Incident reporting
SOC 2	CC7.2	System monitoring

4. Compliance Quick Reference

CISA SCuBA Google Chat Baseline Mapping

SCuBA Baseline	Control	This Guide
GWS.CHAT.1.1v1	Chat history enabled	2.3
GWS.CHAT.1.2v1	Users cannot change history setting	2.3
GWS.CHAT.2.1v1	External Chat file sharing disabled	2.2
GWS.CHAT.3.1v1	Space history enabled	2.3
GWS.CHAT.4.1v1	External chat restricted to allowlisted domains	2.1
GWS.CHAT.5.1v1	Content reporting enabled for all conversation types	3.1
GWS.CHAT.5.2v1	All reporting categories selected	3.1

SOC 2 / NIST 800-53 Summary

Control	SOC 2	NIST 800-53
1.1 Chat apps	CC6.1	CM-7
2.1 External chat	CC6.6	AC-20
2.2 File sharing	CC6.6	AC-3
2.3 History & retention	CC7.2	AU-9
3.1 Audit & reporting	CC7.2	AU-6, IR-6

Platform-wide compliance mappings (authentication, OAuth, DLP, admin audit logging) are in the Google Workspace guide.

Changelog

Version	Date	Changes
0.1.0	2026-05-29	Initial Google Chat product guide — split from the Google Workspace guide (controls 1.1 app allowlisting, 2.1 external chat, 2.2 file sharing, 2.3 history & retention, 3.1 audit & content reporting). Part of the multi-product platform restructure.

Contributing

Found an issue or have an improvement? See the Google Workspace platform guide for platform-wide controls, or open an issue/PR on GitHub.

Google Chat Hardening Guide

Overview

Intended Audience

How to Use This Guide

Scope

Table of Contents

1. App & Integration Security

1.1 Restrict & Allowlist Google Chat Apps

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing

Compliance Mappings

2. Data Security

2.1 Restrict External Google Chat & Spaces

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing

Compliance Mappings

2.2 Restrict Google Chat File Sharing

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing

Compliance Mappings

2.3 Enforce Google Chat History & Retention

Description

Rationale

Prerequisites

ClickOps Implementation

Code Implementation

Validation & Testing

Compliance Mappings

3. Monitoring & Detection

3.1 Enable Google Chat Audit Logging & Content Reporting

Description

Rationale

Prerequisites

ClickOps Implementation

Key Chat Events to Monitor

Code Implementation

Validation & Testing

Compliance Mappings

4. Compliance Quick Reference

CISA SCuBA Google Chat Baseline Mapping

SOC 2 / NIST 800-53 Summary

Changelog

Contributing