Glean Security Guide: Permissions, connectors, tokens and agents done safely

Enterprise AI search makes every overshared document findable by anyone it was accidentally shared with, in seconds, through a single question. Glean indexes content and permissions from dozens of SaaS applications and answers questions, runs agents and calls tools on top of that index. Its core promise is that it never shows a user more than the source system already allows, which means the platform is only as safe as the permissions it inherits, the connector credentials it holds and the agents and tokens built on it. This guide covers how identity and access work in Glean, its admin and agent roles, connector service accounts and API tokens, the logs available for detection, and a hardening baseline. It is for security engineers, identity teams and SaaS administrators deploying or reviewing Glean; the general retrieval design questions are covered in the Permission-Aware RAG Guide. Product details are taken from Glean's documentation as checked on 27 October 2026 and may change.

Key takeaways

• Glean inherits permissions, it does not fix them. Connectors mirror each source's ACLs, groups and roles, and queries are checked against that mirror, so "anyone with the link" files and stale group memberships become instantly searchable.
• The permission mirror is a snapshot. Glean documents that mirrored permissions can lag the source until the next crawl or incremental update, so removal of access is not instant in search.
• Connector credentials are some of the most powerful NHIs in the tenant. They read content and permissions across whole SaaS estates; use dedicated service accounts, minimum scopes and scheduled rotation.
• Global API tokens can impersonate any user. A Glean-issued global token with the X-Glean-ActAs header acts as whichever user it names; prefer OAuth for per-user integrations and treat global tokens as privileged secrets.
• Agents shift risk from reading to acting. Write actions, scheduled agents and service-credential agent identity need governance gates: who can publish, which tools run unattended, and which inputs agents may trust.

How identity and access work in Glean

Users sign in through the organisation's identity provider. Glean's connectors crawl each data source, store content in the tenant's index, and also retrieve the source's permission model: ACLs, group memberships and role assignments. At query time Glean evaluates the signed-in user against those mirrored permissions before returning anything. Glean states that the same check applies to search results, AI answers and citations, agents and actions, MCP server results and embedded integrations such as ServiceNow, Zendesk and Salesforce, and that it "never grants broader access than the source system provides".

Where the inheritance model breaks down

• Oversharing at the source: Glean faithfully enforces a file shared with "everyone in the organisation". Search turns a sharing mistake that was obscure into one that is one question away. This is the main risk for any enterprise AI search deployment, the same one described in the Enterprise AI Copilot Security Guide.
• Identity mapping: the source's user and group identifiers must map correctly to the IdP identity. Contractors with different email domains, renamed accounts and guest users are the usual edge cases. Test with real accounts.
• Snapshot lag: a user removed from a sensitive group may still see results until the next update. For leavers, deprovisioning at the IdP and SCIM removes Glean access entirely, which is faster than waiting for every source's permission to refresh.
• Retrieved content is untrusted: permission checks decide what a user may see, not whether a document contains hidden instructions. An attacker who can get a document or email into a user's accessible corpus can attempt indirect prompt injection, as the EchoLeak attack on Microsoft 365 Copilot showed for a comparable assistant.

Admin roles and privileged access

Glean's secure configuration guidance separates platform administration from agent governance. Assign roles deliberately and review them on a schedule.

• Admins can see what users cannot: connector configuration, Verify access tools and sensitive content reports expose document metadata at scale. Treat Glean admin roles as privileged access and manage them through your PAM or IGA processes. See the Privileged Access Management Guide.
• Enforce SSO and MFA on admins: and consider Glean's IP allowlisting for admin access where your network model supports it.
• Review quarterly: the shared responsibility model calls for periodic admin role reviews. Include Agent Moderators and anyone who can register service credentials.

Integrations, API tokens and service accounts

Connector credentials

Each connector authenticates to a source with credentials that can read content and its permission model across the whole scope you give it, often an entire Google Workspace, Microsoft 365 tenant, Slack workspace or Confluence instance. Glean's shared responsibility page tells customers to use dedicated service accounts for integrations rather than individual credentials, document and audit their permissions, and rotate API keys, access tokens and integration secrets on a set schedule.

• Dedicated identity per connector: never connect a source with a named administrator's account. When that person leaves, either the connector breaks or a leaver's credential keeps running.
• Minimum scope: use greenlists and redlists to include or exclude repositories, folders and items, and start with a pilot scope. Exclude HR, legal, M&A and security folders until they have been reviewed.
• Know the delegated power: some sources grant crawlers tenant-wide read through mechanisms such as Google Workspace domain-wide delegation. See the Google Workspace Domain-Wide Delegation Security Guide.
• Independent monitoring: Glean's guidance suggests using Microsoft Purview to monitor connector API activity independently in Microsoft 365, so a compromised connector shows up in the source's own logs.

API tokens

A global token that names the CEO in X-Glean-ActAs gets the CEO's search results. Inventory these tokens, record what each integration needs, and ask whether a per-user OAuth flow would work instead. Indexing tokens deserve similar care in the other direction: a stolen token can plant documents, including ones with injected instructions, into what users and agents retrieve. The patterns for vaulting and rotating such tokens are in the API Key Management Guide.

Agents and agent identity

• Default identity: an agent runs with the permissions of the user who triggered it, not its creator or publisher, including scheduled agents, which run as the executor without per-run approval.
• Agent identity with service credentials (beta): an admin creates a scoped service credential in the target platform and registers it in Glean; builders attach it to an agent, which then runs with that fixed permission set for every invoker. Glean says secrets are stored encrypted, injected server-side and never placed in the agent runtime, LLM context or sandbox, and that the triggering principal is logged alongside the agent's actions.
• The audience is the access control: with a service credential every invoker gets the same access, so the credential's audience setting decides who effectively holds it. A broad audience on a high-privilege credential is a privilege escalation path for every user in it.
• Write actions: in interactive web sessions, write actions pause for user confirmation by default (Glean notes this does not apply to read-only actions or to Slack and Microsoft Teams). The admin setting "Run without user confirmation" removes the pause for a given action; reserve it for safe, repeatable, low-risk actions.
• Scheduled agents: Glean's guidance is to favour vetted internal inputs and avoid high-risk feeds such as the email inbox, limit web search to approved domains, hard-code destinations (project keys, folder IDs, channel IDs), cap item counts, concurrency and timeouts, and keep destructive actions interactive.

For the identity design behind delegated versus agent-owned credentials, see the Delegation Chains and Attenuated Authority for AI Agents guide.

Logging and detection

Thirty days is short for investigations: arrange ongoing delivery to your SIEM or data lake and set retention there. Useful detections:

• Configuration risk: new connectors, scope changes, redlist removals, role grants and changes to "Run without user confirmation".
• Search abuse: one user running many searches for terms such as "salary", "password", "acquisition" or "layoff", or opening unusually many citations outside their normal sources.
• Token misuse: API calls with X-Glean-ActAs naming executives or security staff, from unexpected IP ranges or outside the integration's normal pattern.
• Agent anomalies: Glean's background agent guidance suggests alerting on new or changed subscriptions, bursts of background writes, unusual tool call volume and abnormal trace patterns. Unsharing an agent or removing its subscriptions pauses it.

Metrics

• Oversharing backlog: number of documents flagged by sensitive content reports and still visible, trending down.
• Connectors on dedicated service accounts: target 100 per cent, each with a named owner and rotation date.
• Global tokens in use: count, age and owner; trend down as integrations move to OAuth.
• Agents with write tools set to run without confirmation: count, each with a documented approval.
• Log coverage: admin and event logs delivered to the SIEM with retention that meets policy.

Hardening baseline

1. Clean the sources first. Before connecting a source, run its native oversharing reports (public links, organisation-wide shares, large groups) and fix or exclude the worst areas. Glean recommends running sensitive findings reports per connector before making content visible to everyone.
2. Identity at the edge. Enforce SSO with MFA, SCIM deprovisioning and, where appropriate, IP allowlisting. Remove leavers at the IdP.
3. Pilot ring. Use Glean's phased rollout: enable each connector for a small test group defined in the Admin console, test permission enforcement with accounts in different departments, then expand. Rollback is to disable the connector or narrow its visibility while you remediate.
4. Scope connectors. Dedicated service accounts, greenlists for what should be indexed, redlists for sensitive locations, and Purview sensitivity-label rules to exclude labelled Microsoft 365 content where needed. See the Microsoft Purview Information Protection Guide.
5. Turn on Glean Protect policies. Scan for PII, payment data and credentials using infotypes, terms and regex, run continuously or weekly, and use autohide while owners remediate. Use visibility controls (all users, all but the owner, all but explicit sharers) and Verify access to confirm the outcome.
6. Govern tokens. Prefer OAuth; scope Glean-issued tokens; restrict and expire global and indexing tokens; store them in a secrets manager.
7. Govern agents. Keep "Can publish agents" off for Default Members, route publishing through Agent Moderators, keep destructive actions interactive, and register service credentials only with a narrow scope and audience.
8. Choose the model path deliberately. Glean's guidance points to its Universal Model Key, described as zero-day data retention with no training on enterprise data; confirm the contractual terms for whichever model provider you select.
9. Wire up logging. Admin audit logs and customer event logs into the SIEM, with retention beyond the 30-day default.

Deployment model and organisation size

Common misconfigurations

• Indexing everything on day one: connecting whole tenants before any oversharing review turns years of loose sharing into searchable exposure.
• Connectors on a person's admin account: creates a hidden dependency on one human and a high-value credential nobody rotates.
• Global tokens in scripts and wikis: a token that can impersonate any user, stored like a low-value API key.
• Relying on assistant instructions as access control: exclusion rules in assistant policies help, but only source permissions and redlists actually stop retrieval.
• Broad audiences on service-credential agents: every invoker inherits the credential's access, bypassing their own permissions.
• Unattended writes from untrusted inputs: scheduled agents reading inboxes or open web results and then writing to tickets, chat or code without confirmation are an indirect prompt injection path.
• Logs left at 30 days: by the time an oversharing or token misuse incident is noticed, the evidence has aged out.

Framework mapping

Practitioner checklist

• Run oversharing reports on each source and fix or redlist sensitive locations before connecting it.
• Enforce SSO with MFA and SCIM deprovisioning; review Setup Admin, Admin, Super Admin and Agent Moderator holders quarterly.
• Connect every source with a dedicated, documented service account and rotate its credentials on a schedule.
• Pilot each connector with a test group and verify permission enforcement with accounts from different departments.
• Enable Glean Protect policies for PII, payment data and credentials, with autohide during remediation.
• Replace global Glean-issued tokens with OAuth where possible; scope, expire and vault the rest, and alert on unusual X-Glean-ActAs targets.
• Scope Indexing API tokens to specific datasources and treat push connector code as a permission source of truth needing review.
• Keep "Can publish agents" off for Default Members and keep destructive actions interactive.
• Register agent service credentials with narrow scope and a deliberate audience; rotate and revoke them like any NHI.
• Deliver admin audit logs and customer event logs to the SIEM with retention beyond 30 days.

Standards and references

• Glean: Core security principles
• Glean: Secure configuration
• Glean: Shared responsibility model
• Glean: Agent identity
• Glean: Scheduled trigger security
• Glean Developers: Client API authentication
• OWASP: Top 10 for LLM Applications 2025
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Permission-Aware RAG Guide · Enterprise AI Copilot Security Guide · Microsoft 365 Copilot Security Deep Dive · Generative AI Data Loss Prevention Guide