An AI writing or translation assistant reads whatever text a person is typing, in email, chat, documents and web forms, so the question "is it safe for business?" is really a question about which account the person uses, which settings govern that account and where the assistant is allowed to run. Grammarly is a common example, and its Enterprise, Business and Education plans give administrators controls over sign-in, provisioning, model training on organisation content, generative AI features, client apps and the websites and desktop applications where it operates. This guide explains those controls and then sets out the same governance pattern for any writing or translation assistant your organisation approves or needs to restrict. It is for IT administrators, security teams and privacy officers who own collaboration tools and shadow AI policy. For the browser extension side of the problem, see the AI Browser Extensions Security Guide.
This is an independent guide from NHI Mgmt Group, based on Grammarly's public documentation as of November 2026. It is not sponsored or reviewed by Grammarly. Product features change, so confirm settings against Grammarly's current documentation.
Key takeaways
- The account type decides the data terms. Grammarly documents Product Improvement and Training as on by default for individual users and off by default for Enterprise, Business, Pro and Education accounts bought through Sales, so moving staff onto the organisation's licence changes how their text is treated.
- Capture work-email sign-ups. Enterprise domain controls (Domain Verification, Domain Capture and Invite Capture) bring personal accounts created with company email addresses under the organisation's licence and SSO.
- Use SAML SSO and SCIM. SSO ties access to your identity provider, and SCIM deactivates Grammarly users when they are deactivated upstream.
- Choose where the assistant runs. Enterprise admins can block Grammarly on specific domains and desktop applications, and set each client app to Available, Managed or Blocked per group.
- Govern generative features separately. Admins can switch off the AI assistant, Strategic suggestions and Paragraph-level rewrites under Feature access while keeping core writing suggestions.
How identity and access work in Grammarly
Grammarly has two worlds: individual accounts that people create themselves, and organisation accounts administered from the Admin Home console. Most of the governance value comes from moving people from the first to the second, because organisation accounts carry the organisation's data settings and controls.
| Account route | Who controls settings | Training default (per Grammarly docs) |
|---|---|---|
| Individual (Free, Premium, single-user Pro) | The user | Product Improvement and Training on by default; the user can turn it off |
| Multi-user Pro bought through the website | Admins only | On by default; an admin can turn it off for the organisation at account.grammarly.com/admin/data_settings |
| Enterprise, Business, Pro and Education bought through Sales | Admins and the sales agreement | Off by default, so organisation content is not used for training |
Grammarly describes training as covering building AI and machine learning models, validating them and deciding which features to build or improve. With the setting off, content is not used for those purposes, although aggregate or non-content data such as writing statistics may still be collected. A user who joins a team takes on the admin's setting.
Sign-in, provisioning and domain capture
- SAML SSO: available on Business, Enterprise and Education plans, with setup guides for identity providers including Okta, Microsoft Entra ID, Google, PingOne, OneLogin, Auth0, ADFS, JumpCloud and others.
- SCIM provisioning: available on Enterprise. In Grammarly the admin opens the Provisioning page, activates SCIM and creates a token for the identity provider. The Okta guide states that users deactivated in Okta are deactivated in Grammarly, can no longer sign in, and their data is kept as an inactive user for 30 days before the account is deleted. Grammarly notes that deprovisioning takes a short time to apply, so allow for a short lag in leaver processes.
- Domain Verification: new sign-ups with a verified work domain are sent to your SSO login, and only people granted Grammarly in your identity provider get accounts.
- Domain Capture: existing users with your domain must join the Enterprise licence or change their account email to a personal address before continuing.
- Invite Capture: applies to people invited to the licence and also works without SSO.
Availability: Grammarly lists the domain sign-up controls as Enterprise only, requiring SAML SSO first (except Invite Capture), and enabled through your Customer Success Manager. Changes take effect at the user's next sign-in. For SSO design generally, see the SCIM Provisioning Guide.
Admin roles and privileged access
The Grammarly admin role controls every setting in this guide: data settings, Feature access, client apps, the domains and apps block list, SSO and the SCIM token. Grammarly also refers to custom roles for these tasks. Treat the admin role as a SaaS administrator.
- Keep admins few and named: two or three people from IT, with a backup, all signing in through SSO.
- Use admin-controlled groups: when a control is scoped to a group, Grammarly offers an option to make the group admin-controlled, so only admins can delete the group or remove its members. Use it for groups that carry restrictions, otherwise a group owner could remove someone from a restricted group.
- Protect the SCIM token: it can create and deactivate users. Store it in your secrets manager, record its owner and regenerate it when the owner changes.
- Change control for data settings: any change to Product Improvement and Training, or to Feature access for generative AI, should go through a recorded change, because it changes how staff text is processed.
Integrations, API tokens and service accounts
A writing assistant integrates through client software rather than service accounts, so the "integration" surface is the set of places the client reads text. Grammarly's Enterprise controls map onto that surface directly.
| Control | Admin path (per Grammarly docs) | Effect | Scope |
|---|---|---|---|
| Client apps | Admin Home, Organization, Enterprise security, Client apps | Set Grammarly for Windows, Mac, browser extensions and Mobile to Available, Managed (central deployment only) or Blocked | Organisation or groups |
| Domain controls | Admin Home, Organization, Enterprise Security, Domains and apps, Add to block list, Domain | Grammarly stops operating on the listed domains; optional Include subdomains | Chrome, Firefox and Edge extensions, Windows and Mac apps; organisation or groups |
| Application controls | Same page, Add to block list | Grammarly stops running in named desktop apps, identified by .exe name on Windows and bundle ID on Mac | Windows and Mac apps; organisation or groups |
| Feature access | Admin Home, Organization, Feature access | Switch off AI assistant, Strategic suggestions and Paragraph-level rewrites | Organisation |
| Product Improvement and Training | Data settings | Controls whether content is used for training | Organisation |
Availability: client apps, domain and application controls are listed as Enterprise only; Feature access for generative AI is listed for Pro, Plus, Business, Enterprise and Education plans.
What to block, where
Use the block list for the places where typed text is most sensitive or regulated: internal HR and case management systems, clinical or customer record applications, privileged access and secrets tools, admin consoles, password managers and legal matter systems. On desktops, add the executable or bundle ID for each, separately for Windows and Mac. Pair this with endpoint controls so that unmanaged installs of any writing assistant are visible. Set client apps to Managed where you deploy through your software distribution tool, which stops people installing their own copy.
Governing other writing and translation assistants
The same pattern applies to any writing, paraphrasing or translation assistant, whether delivered as a browser extension, desktop app, office add-in or website. Work through these questions for each one before approving it:
- Is there an organisation plan with admin controls? Look for SSO, SCIM, a training opt-out that the admin controls, and a way to restrict where the tool runs.
- What happens to submitted text? Read the vendor's data processing terms for storage, retention, training use and sub-processors, and record them in the supplier assessment.
- Which surfaces does it read? An extension with access to all sites reads every form field; a website only sees what people paste. See the Browser Extension Security Guide.
- Can you restrict it technically? Browser management can allow or block extensions by ID, endpoint management can block or manage installs, and web filtering can restrict sites by category.
Where a tool is not approved, block it at the browser and network layers and offer the approved option in the same message, because blocking without an alternative drives people to personal devices. See the Shadow AI Policy Template.
Logging and detection
- Identity provider logs: with SAML SSO, every Grammarly sign-in appears in your identity provider. Alert on sign-ins outside the assigned group and on SCIM provisioning errors.
- Browser management reports: extension inventory reports show which writing assistant extensions are installed, by version and user, including unapproved ones.
- Endpoint inventory: software inventory shows desktop writing assistants installed outside your deployment tool.
- Network and secure web gateway logs: traffic to writing and translation services from users without an organisation licence is the clearest shadow AI signal for this category.
- DLP: where your DLP inspects browser uploads and pastes, policies for regulated data apply to writing assistant websites too. See the Generative AI Data Loss Prevention Guide.
| Metric | Target | Source |
|---|---|---|
| Work-email accounts on the organisation licence (after Domain Capture) | 100% | Grammarly admin console |
| Licensed users signing in through SSO | 100% | Identity provider logs |
| Leavers deactivated by SCIM within your standard | 100% | SCIM logs against HR leaver list |
| Sensitive systems on the domains and apps block list | 100% of the agreed list | Block list review |
| Unapproved writing assistant extensions installed | Falling to 0 | Browser management reports |
Hardening baseline
- Decide policy first. Agree which writing and translation assistants are approved, for which data classes, and where they must not run. Record it in the AI acceptable use policy; see the AI Acceptable Use Policy Template.
- Buy and configure the organisation plan. Confirm Product Improvement and Training is off for the organisation, or turn it off in data settings where your plan exposes the toggle.
- Connect SAML SSO, then SCIM. Configure SSO with your identity provider, assign the app to a group, activate SCIM, and test a leaver end to end.
- Bring personal accounts in. Ask Grammarly to enable Domain Verification and Domain Capture (or Invite Capture) so work-email accounts join the licence. Communicate the change before it takes effect at next sign-in.
- Set client apps. Set the apps you deploy to Managed and block the ones outside your standard build.
- Build the block list. Add sensitive domains (with Include subdomains where appropriate) and desktop apps by executable and bundle ID.
- Decide generative features. Keep or switch off AI assistant, Strategic suggestions and Paragraph-level rewrites under Feature access, by data class and team.
- Restrict unapproved assistants. Use browser and endpoint management to block other writing and translation extensions and apps, and web filtering for their websites, with a pointer to the approved tool.
- Report vulnerabilities and track updates. Keep clients current through your deployment tool; Grammarly's security page lists its HackerOne programme and security contact.
Testing and rollback: pilot each restriction with one admin-controlled group, check that blocked domains and apps behave as expected on Windows and Mac, and confirm SCIM deactivation. Domain and app entries can be removed from the Domains and apps page, and client app settings can be changed back on the Client apps page, so rollback is a console change.
Common misconfigurations
- Licence bought, personal accounts left alone: staff keep using individual accounts with their own settings. Enable Domain Capture or Invite Capture.
- SSO without SCIM: leavers keep accounts until someone removes them manually. Activate SCIM on Enterprise.
- Block list scoped to the main domain only: subdomains of sensitive systems stay covered by the assistant. Tick Include subdomains.
- Desktop block on one platform only: a Windows executable entry does nothing on Mac. Add the bundle ID too.
- Restricted groups that anyone can edit: a group owner removes a member from the restriction. Make restriction groups admin-controlled.
- Blocking every assistant with no approved option: people paste text into web tools on personal devices. Approve one governed tool and say so.
Framework mapping
| Control area | Setting | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Other |
|---|---|---|---|---|
| Account lifecycle | SAML SSO, SCIM, Domain Capture | AC-2, IA-2 | PR.AA-01 | ISO/IEC 27001:2022 A.5.18 |
| Data use by supplier | Product Improvement and Training | SA-9 | GV.SC-07 | GDPR Art. 28 processor terms |
| Where the tool runs | Domain and application controls, client apps | CM-7, CM-10 | PR.PS-01 | CIS Controls v8.1 Control 2 |
| Generative features | Feature access | CM-7 | PR.PS-01 | OWASP LLM02:2025 Sensitive Information Disclosure |
| Shadow use | Browser, endpoint and network controls | CM-8, AU-6 | ID.AM-02, DE.CM-03 | ISO/IEC 27001:2022 A.8.12 |
Practitioner checklist
- Publish which writing and translation assistants are approved, for which data, and where they must not run.
- Move staff onto the organisation plan and confirm Product Improvement and Training is off.
- Configure SAML SSO, activate SCIM and test a leaver.
- Enable Domain Verification and Domain Capture or Invite Capture for work-email accounts.
- Set deployed client apps to Managed and block unsupported ones.
- Block sensitive domains (with subdomains) and desktop apps by executable and bundle ID.
- Decide Feature access for generative AI per data class and team.
- Use admin-controlled groups for every restriction, keep admins to a named few and vault the SCIM token.
- Block unapproved writing assistant extensions, apps and sites, and monitor extension inventory monthly.
Standards and references
- Grammarly: Security
- Grammarly: Product Improvement and Training control
- Grammarly: Enterprise domain controls for new signups and existing users
- Grammarly: Manage client apps controls
- Grammarly: Manage domain controls
- Grammarly: Manage application controls
- Grammarly: Turn off generative AI for my team
- Grammarly: Configure SCIM provisioning with Okta
Related NHI Mgmt Group resources: AI Browser Extensions Security Guide · Shadow AI Discovery Guide · Generative AI Data Loss Prevention Guide · AI Acceptable Use Policy Template · Top 10 Shadow AI Risks