DTwo Policy Store

Crm bundle

Included policies (10)

About this bundle

A curated bundle of policies for CRM MCP servers. The goal is a sensible default posture for any organization fronting a CRM through the DTwo gateway: keep high-impact CRM writes (like closing deals or reassigning records) under control and keep customer PII from leaking out, while leaving everyday CRM work unaffected. The bundle spans CRM apps — HubSpot and Salesforce today, with room for more under the same theme.

Included policies

Policy App Direction Purpose
block-deal-closure hubspot ingress Deny CRM-object calls that move a deal into a closed stage (closedwon / closedlost); all other deal changes and tools pass through.
protect-associations hubspot ingress Deny CRM-object calls that create or change object associations; all other calls pass through.
protect-deal-owner hubspot ingress Deny deal-update calls that set or change hubspot_owner_id; deal creates and other fields pass through.
protect-lifecycle-stage hubspot ingress Deny contact create/update calls that set or change lifecyclestage; all other calls pass through.
read-only hubspot ingress Block all HubSpot writes (the *-manage-crm-objects tool); read/search/list tools pass through.
redact-pii hubspot egress Redact contact PII (phone, email, fax, SSN) from HubSpot tool responses. Transform-only — never denies.
protect-contact-fields salesforce ingress Deny Salesforce Contact updates that modify protected fields (ownership, account linkage, PII, name, consent flags); other field updates and tools pass through.
query-allowlist salesforce ingress Restrict Salesforce SOQL queries to Account, Contact, and Opportunity objects; other tools pass through.
read-only salesforce ingress Allowlist Salesforce read tools and deny all writes (fail-closed); non-Salesforce tools pass through.
redact-pii salesforce egress Redact contact PII (email, phone, fax, mailing address, birthdate, SSN, card numbers) from Salesforce responses. Transform-only — never denies.

Policy bodies live under apps/. This page only links to them — see the top-level README for the rationale.

How bundle membership works

Bundle membership is declared in each policy's policy.md frontmatter (the policy lists bundles: ["crm"]). This page is a human-readable landing page; the generated manifest.json is the machine-readable source of truth. There is intentionally no separate bundle.json artifact — one source of metadata avoids drift.

The bundle's ingress policies are designed to compose cleanly on the same pipeline. block-deal-closure, protect-associations, protect-deal-owner, and protect-lifecycle-stage are each single-purpose deny policies (default allow := false, re-allowing everything except their own narrow concern — a deal-closing write, an association change, a deal-owner change, and a contact lifecycle-stage change respectively), so they never interfere with each other or with other CRM policies attached to the same direction.

read-only is the broad-strokes alternative: it blocks the entire *-manage-crm-objects write tool, which supersedes all four narrow deny policies above (they each gate a subset of the same tool). Pick read-only when you want a fully read-only connection, or the narrow policies when you want to allow most writes but block specific high-impact ones — combining both is redundant but harmless.

The two redact-pii policies (one for HubSpot, one for Salesforce) are the bundle's egress members — they attach to the egress (response) pipeline rather than ingress, are transform-only (default allow := true), and are orthogonal to the ingress write controls above, so they compose cleanly alongside any of them. Each is scoped to its own app, so they don't interfere with each other.

What's intentionally not in the bundle

Roadmap