Glean

5 reviewed Dtwo policies for Glean MCP servers — egress + ingress controls for governing what AI agents can do with Glean.

On this page
  1. Available policies
  2. Tool naming on the DTwo gateway
  3. Identity claims
  4. Contributing
  5. Ingress policies (4)
  6. Egress policies (1)

Reusable DTwo policies for the Glean MCP server — primarily the official Glean managed remote MCP server that the Claude connector uses (default server: search, chat, read_document, employee_search, user_activity, memory, memory_schema), plus the deprecated gleanwork/local-mcp-server and thin community wrappers. Glean is an aggregation layer: a single tool call fans out across everything the tenant has indexed (Drive, Confluence, Slack, Jira, Gmail/Outlook, GitHub, Salesforce, Gong, HR systems…), and Glean ships its own MCP Gateway that proxies third-party servers and data-source write actions. Its risk profile is therefore closer to all-corp-data egress than to any single app: read tools return whatever the authenticated user can see across every source, read_document fetches arbitrary public URLs (a covert exfiltration channel), the memory tool is a writable cross-session persistence surface, and the tool inventory is admin-mutable — agents-as-tools and gateway-proxied writes can appear without warning.

Available policies

Policy Direction Purpose Framework bundles
cap-search-export ingress Clamp bulk-export params on search — lower over-broad num_results to a ceiling and strip exhaustive:true (transform-only). soc2, hipaa, gdpr-ccpa
default-deny-unknown-tools ingress Pin a per-tenant allowlist of verified built-in Glean read tools; deny every other tool suffix on the Glean server (agents-as-tools, gateway-proxied writes). soc2, gdpr-ccpa
fence-datasource-scope ingress Restrict which indexed datasource a search may target via the app argument; deny restricted sources (Gong, Salesforce, HR) unless the caller is in the cleared IdP group. soc2, hipaa, pci-dss, gdpr-ccpa, sox
gate-memory-writes ingress Deny mutating memory/read_memory calls (add/update/delete) unless the caller is in the pilot group; memory reads and all other tools pass. soc2, hipaa, pci-dss, gdpr-ccpa, sox
redact-pii-egress egress Redact SSNs, payment-card numbers (PANs), and IBAN/bank accounts from Glean read-tool responses before they reach the agent context (transform-only). soc2, hipaa, gdpr-ccpa

Tool naming on the DTwo gateway

DTwo prefixes tool names with the MCP server name configured on the gateway, and Glean's built-in tools use bare, generic snake_case names (search, chat, read_document). A Glean MCP server registered as glean surfaces glean-search; one registered as glean-mcp surfaces glean-mcp-search. The policies here match on the suffix (search, read_document, meeting_lookup, etc.) so they stay portable across naming conventions, and the default-deny-unknown-tools policy anchors on the configured Glean server prefix so Glean's generic names are never confused with a same-named tool on a different server. Confirm the exact tool names your gateway sends using the dump-input debug technique before deploying. The deprecated local server used different names for the same functions (company_search, people_profile_search); add those aliases only if a tenant still runs the archived package. Agents-as-tools and gateway-proxied tools have arbitrary org-specific names — inventory them per tenant before writing match rules.

Identity claims

The identity-gated policies (fence-datasource-scope, gate-memory-writes, and the exemption logic in others) read input.subject.claims.groups with placeholder group names (e.g. glean-memory-pilot, sales, revops, hr). Replace these with your own IdP group names at import time. Missing claims fail closed for grants (no group → not exempt / not cleared). cap-search-export and redact-pii-egress are single-purpose transforms and require no claims.

Contributing

To add a Glean policy:

  1. Create apps/glean/<policy-slug>/ with policy.md and a tests.yaml test file.
  2. Add a row to the table above.
  3. Declare apps: ["glean"] in the policy frontmatter, plus any industry / bundle slugs that apply.
  4. If the policy fits a framework or thematic bundle, link to it from the matching landing page.
  5. Run pnpm manifest from the repo root.

See CONTRIBUTING.md for the full process.

Ingress policies (4)

Egress policies (1)

Updated

to navigate to open