# Sensitive data movement: enterprise AI policy pack Permit scoped retrieval and analysis while preventing cross-tenant access, uncontrolled exports, public sharing and production-data copies into ungoverned environments. Implementation guidance, not executable Tracelet configuration or legal advice. Tool names identify places where the control may apply; they do not claim shipped connector coverage. Confirm actual tool/action coverage and enforce destination permissions. Replace example thresholds, IDs and approval windows with your approved values. ## Control scope - Protected assets: Secrets, credentials, customer records, employee records, payment data and regulated datasets - Consequential actions: Retrieval, export, copy, upload, paste, sharing, cross-tenant access and non-production replication - Applicable systems: Data warehouses, object stores, CRM, document suites, messaging, browsers and AI assistants - Context to resolve: Resolve classification, record count, fields, tenant, residency, destination tenant/domain, recipient membership and device/workspace trust. - Enforcement boundary: Combine source-system entitlements, field/row security, DLP and destination controls. Browser paste, uploads and screenshots require endpoint/browser coverage in addition to API controls. ## Owners Data protection owner + system data owner ## Configure first - Data classifications, tenant ownership, residency rules and approved processing destinations - Export thresholds, permitted recipient domains, managed devices and expiring share settings - Tokenisation, masking and synthetic-data standards for non-production environments ## Shared decision baseline ### Resolve the real target Decide on immutable IDs and effective context: principal, tenant/account, environment, resource, data classification and destination. Names and local profiles are hints, not authority. ### Fail closed on consequential ambiguity If the target, blast radius, tenant or data classification cannot be resolved, hold the action. Do not treat missing metadata as non-production or low risk. ### Bind approval to the exact action An approval covers the actor, operation, target set, content or artifact digest, value and expiry. Material changes invalidate it; the requester cannot approve their own action. ### Keep an evidence-grade decision record Record resolved context, policy version, matched rule, decision, approver and downstream result. Minimise captured sensitive content and protect the record from the acting identity. ## Policies ### SD-01: Block secrets from leaving approved secret-handling paths - Severity: Critical - Decision: Block - Owner: Secrets platform owner #### Policy statement Deny retrieval or transfer of passwords, private keys, access tokens, recovery codes and live credentials into prompts, tickets, chat, email, logs or unapproved files. #### Covered operations - Read and return secret value - Upload, paste, message or email detected secret material - Write secret to source code, build output, ticket or shared document #### Evaluation rules - Combine source classification with secret-pattern and entropy detection; never log the full matched value. - Resolve destination tenant, workspace, channel, recipients and retention before transfer. - Allow workload-side secret references or handles, not disclosure of secret material to the conversational model. #### Example decisions (illustrative; do not run against live systems) - **AWS Secrets Manager:** `GetSecretValue then paste result into a support ticket`. Block before retrieval or transfer. - **Slack:** `Post a private key to an incident channel`. Block even if the channel is internal. #### Applicable tools and systems - AWS Secrets Manager - Azure Key Vault - Google Secret Manager - HashiCorp Vault - GitHub / GitLab - Slack / Teams - Jira / ServiceNow #### Enforcement Expose reference-based secret operations to agents and keep value retrieval in the workload. Add DLP/secret scanning at browser, messaging, repository and ticket boundaries. #### Exception / approval No chat-based exception. Human recovery uses the secret system’s audited reveal process on a managed device. #### Test fixtures - Should remain permitted: Reference a secret by identifier in deployment configuration without revealing its value. - Should be blocked or held: Retrieve and print a secret, encode it to evade detection or place it in a repository, prompt, ticket or message. #### Implementation references - [Microsoft Purview · Data loss prevention](https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp) ### SD-02: Block cross-tenant customer data access - Severity: Critical - Decision: Block - Owner: Customer data owner #### Policy statement Deny reads and writes when the requested customer, account, case or object does not belong to the tenant and assignment established by the active work context. #### Covered operations - Retrieve record by guessed ID outside assigned tenant - Join, search or aggregate across tenants - Update or attach one tenant’s data to another tenant’s case #### Evaluation rules - Derive tenant and assignment from signed session context and source-system entitlements, never from model-supplied fields. - Enforce row/object-level ownership on every lookup, relationship expansion, export and write. - Fail closed on missing tenant mapping and prevent sequential-ID or broad-search enumeration. #### Example decisions (illustrative; do not run against live systems) - **Salesforce:** `Read account 001… belonging to another region/tenant`. Block. - **Zendesk:** `Attach customer A’s diagnostic file to customer B’s ticket`. Block. #### Applicable tools and systems - Salesforce - HubSpot - Zendesk - Intercom - ServiceNow - Databases / warehouses - Object storage #### Enforcement Enforce tenant isolation in the API and data layer with row/object security and scoped credentials. Agent-side intent checks add context but are not the isolation boundary. #### Exception / approval Cross-tenant investigations require an authorised support/security role, named tenants, a case reference and time-bound access. #### Test fixtures - Should remain permitted: Retrieve the minimum permitted fields for the customer linked to the assigned case. - Should be blocked or held: Change the record ID, use global search or follow a relationship to access another tenant’s data. #### Implementation references - [NIST SP 800-207 · Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) ### SD-03: Review bulk exports of regulated or confidential data - Severity: High - Decision: Require approval - Owner: Data owner + privacy owner #### Policy statement Hold exports of confidential, personal, health, payment or employee data when fields, row count, file size or query scope exceed the data owner’s approved threshold. #### Covered operations - CSV/JSON export or bulk API extraction - Warehouse unload to object storage - CRM, HRIS or support bulk export - Repeated smaller exports that cumulatively cross the threshold #### Evaluation rules - Resolve classifications at field level, exact row estimate, tenant set, destination, recipient and retention. - Aggregate related exports and include query, filters and selected fields in the approved digest. - Require a managed encrypted destination and minimum necessary fields; block unknown or personal destinations. #### Example decisions (illustrative; do not run against live systems) - **Snowflake:** `COPY 2.4M customer rows with email and DOB to an external stage`. Hold for data-owner approval. - **Salesforce:** `Bulk export all contacts to a local CSV`. Hold and verify destination/device. #### Applicable tools and systems - Snowflake - BigQuery - Databricks - Redshift - Salesforce - Workday / HRIS - Zendesk - S3 / GCS / Azure Blob #### Enforcement Use field/row policy, export entitlements, DLP classification and a broker that writes only to approved destinations. Preserve query and destination evidence without duplicating sensitive content. #### Exception / approval Approval covers purpose, exact fields/query, population, destination, recipients, retention and expiry. New purpose or destination needs a new decision. #### Test fixtures - Should remain permitted: Export an approved aggregate without direct identifiers to a governed analytics workspace. - Should be blocked or held: Add sensitive fields after approval, switch to a personal destination or split a large export into small batches. #### Implementation references - [AWS · Discover sensitive data with Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-jobs.html) - [Microsoft Purview · Data loss prevention](https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp) ### SD-04: Review public links and external sharing of sensitive content - Severity: High - Decision: Require approval - Owner: Document or matter owner #### Policy statement Hold external sharing of confidential or restricted files and deny anonymous/public links. Approval must cover the exact content version and verified recipients. #### Covered operations - Create public/anonymous link - Share outside approved domains or guest groups - Change link permissions, download settings or expiry - Post sensitive attachment to an external channel #### Evaluation rules - Resolve file classification, matter/customer ownership, content version, recipient identities, guest membership and link settings at share time. - Deny anonymous access for sensitive content and enforce the shortest practical expiry and least permission. - Invalidate approval when the content, recipients, permission or destination changes. #### Example decisions (illustrative; do not run against live systems) - **Google Drive:** `Set board-plan.pdf to anyone-with-link`. Block. - **Microsoft SharePoint:** `Share restricted contract with counsel@example.com for 7 days`. Hold for matter-owner approval. #### Applicable tools and systems - Google Drive - Microsoft 365 / SharePoint - Box - Dropbox - Slack Connect - Microsoft Teams - DocuSign #### Enforcement Use source-system classification, domain restrictions, guest policy and DLP at the sharing API. Re-check recipients and classification immediately before creating the share. #### Exception / approval One approved content digest, named recipient set, permission and expiry; anonymous links remain prohibited for sensitive classes. #### Test fixtures - Should remain permitted: Share an internal-classified document with a named employee who already has approved workspace access. - Should be blocked or held: Create an anonymous link, change recipient after approval or share a revised sensitive document under an old approval. #### Implementation references - [Microsoft Purview · Data loss prevention](https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp) ### SD-05: Block raw production data in lower-trust environments - Severity: Critical - Decision: Block - Owner: Data protection owner #### Policy statement Deny copying, restoring or replicating raw production datasets into development, test, personal or third-party environments unless an approved transformation removes protected data first. #### Covered operations - Restore production snapshot into dev/test account - Clone warehouse/database across trust boundary - Copy production object-store prefix to lower environment - Disable masking or tokenisation on replicated data #### Evaluation rules - Compare source and destination trust, tenant, region and access population; do not rely on resource names. - Require approved masking/tokenisation job and verify the resulting classification before granting access. - Block copies containing secrets, live payment data or direct identifiers when no approved transformation exists. #### Example decisions (illustrative; do not run against live systems) - **AWS RDS:** `Restore prod snapshot into shared-dev account`. Block until an approved masked derivative is produced. - **Snowflake:** `Clone prod.customer to developer personal database`. Block. #### Applicable tools and systems - AWS RDS / S3 - Google Cloud SQL / BigQuery / GCS - Azure SQL / Blob - Snowflake - Databricks - MongoDB Atlas - Test-data platforms #### Enforcement Use cross-account policy, snapshot permissions and governed data pipelines. Create masked or synthetic datasets through a controlled identity and classify the output before release. #### Exception / approval A time-bound, isolated investigation environment requires privacy/security approval, named users, monitoring and verified destruction. #### Test fixtures - Should remain permitted: Create a synthetic or verified masked dataset in the approved test account. - Should be blocked or held: Share the raw snapshot, restore it to a lower-trust account or disable masking after access is granted. #### Implementation references - [AWS · Discover sensitive data with Macie](https://docs.aws.amazon.com/macie/latest/user/discovery-jobs.html) ### SD-06: Review cross-region and cross-tenant regulated-data transfers - Severity: High - Decision: Require approval - Owner: Privacy and data residency owner #### Policy statement Hold transfers of regulated data to a different region, country, cloud account or SaaS tenant unless the destination is pre-approved for that classification and purpose. #### Covered operations - Cross-region replication or export - Copy to another cloud account/project/subscription - Upload to external SaaS or AI workspace - Change residency, replication or backup location #### Evaluation rules - Resolve source classification and residency plus destination legal entity, tenant, region, processor and retention. - Check an owned allowlist tied to data class and purpose; a vendor name alone is insufficient. - Bind approval to dataset/query, destination, purpose and retention and aggregate related transfers. #### Example decisions (illustrative; do not run against live systems) - **Google Cloud Storage:** `Copy AU customer export to a US multi-region bucket`. Hold for residency review. - **Browser AI:** `Upload a payroll workbook to a personal AI workspace`. Block as an unapproved tenant. #### Applicable tools and systems - AWS / Azure / Google Cloud storage - Snowflake - Databricks - Google Workspace - Microsoft 365 - Browser AI - MCP and SaaS connectors #### Enforcement Use organisation policy, storage controls, tenant restrictions, CASB/DLP and approved connector identities. Monitor the downstream result and record destination identifiers. #### Exception / approval Requires documented purpose, legal/privacy basis where applicable, exact destination, retention and expiry; emergency does not waive destination security. #### Test fixtures - Should remain permitted: Send an approved minimal dataset to a governed in-region processor for the recorded purpose. - Should be blocked or held: Change region or tenant after approval, use a personal workspace or omit destination context. #### Implementation references - [Microsoft Purview · Data loss prevention](https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp) ## Rollout checklist - [ ] Inventory authoritative resource IDs, environments, classifications and owners. - [ ] Map every entry point: IDE, agent, CLI, MCP, API, browser and direct console. - [ ] Put the hard deny or least-privilege boundary in the destination system. - [ ] Test permitted, held and denied fixtures using synthetic data in a sandbox. - [ ] Test aliases, APIs, batch operations, changed approvals, retries and unknown scope. - [ ] Observe matches, tune false positives and then enforce a bounded production scope. Coverage: https://tracelet.ai/platform#coverage