Policy stories

Problem-first guides to governing AI agents. Each one takes a specific risk — a leaked secret, exposed CRM data, an unwanted write — and names the DTwo policies that address it.

• SLACK · DLP

  Stop AI agents from leaking secrets into Slack

  Once an agent posts to Slack, an API key is in channel history and search. Catch it before the send, not after.

  For: Platform and InfoSec teams running an AI assistant with Slack write access

• CRM · PII

  Keep customer PII from walking out of your CRM

  An agent reading Salesforce or HubSpot pulls emails, phone numbers, and addresses into its context and your chat logs. Mask them on the way out.

  For: RevOps and data-governance owners exposing a CRM to AI tooling

• CRM · ACCESS CONTROL

  Give AI agents read-only access to your CRM

  For a low-risk CRM pilot, give the agent a one-way mirror: it reads every record and changes none. The read-only policies enforce that, and a query allowlist tightens it further.

  For: Teams piloting AI on a CRM who want zero write risk

• HUBSPOT · ACCESS CONTROL

  Guard the CRM writes your revenue depends on

  You want agents logging activities and creating records, just not closing deals or reassigning owners on their own. Gate the few writes that matter.

  For: RevOps teams who want productive agents without high-impact mistakes

• JIRA · ACCESS CONTROL

  Wall off sensitive Jira projects from AI agents

  Security, legal, and HR projects share the same Jira as your sprint board. Keep agents from reading or writing them, and redact whatever still comes back.

  For: Teams running AI on Jira with confidential projects in the same instance

• SLACK · ACCESS CONTROL

  Slack hygiene for autonomous AI agents

  Slack's OAuth scopes pick capabilities, not the channels they apply to: you can grant an agent 'post messages,' but not 'post only in #status' — one scope covers every channel at once.

  For: Platform teams granting agents Slack access beyond a single channel