Stop sensitive data leaking into workplace AI

To stop sensitive data leaking into ChatGPT and Copilot at work, give employees sanctioned work accounts, define which data classes each exact product may receive, discover unsanctioned use and enforce policy before content is sent. Start with detect-only monitoring on verified paths. Tune the rules before you block prohibited data, redact recoverable values and send narrow exceptions for approval. Test prompts, paste, uploads, connected apps, IDE context and agents. An observed AI destination is not proof that the interaction was inspected or stopped.

Start with the exact product and account

"Copilot" can mean Microsoft Copilot, Microsoft Copilot Chat, an embedded Microsoft 365 feature or GitHub Copilot. ChatGPT also has personal and managed workspaces. Record the product, plan, tenant or workspace, account type, enabled models, web search, apps, connectors, agents, retention, administrator access and applicable contract. Approve that exact combination for a named purpose.

OpenAI's enterprise privacy page says business data is excluded from model training by default and describes workspace, access and retention controls. Microsoft's enterprise data protection guidance says Microsoft Copilot and Copilot Chat apply enterprise terms, identity, permissions, sensitivity labels, retention and audit controls, with capabilities varying by subscription. It also says web queries use separate data-handling practices and advises checking agent terms.

Provider commitments inform the assessment. Your organisation still needs to decide whether the disclosure, purpose, account, feature, retention and access are acceptable for each data class. The OAIC recommends, as a matter of best practice, that organisations keep personal information and particularly sensitive information out of publicly available generative AI tools.

This guide covers workforce data crossing into third-party AI services. For attacks carried in untrusted instructions, use the prompt injection guide. The LLM security guide covers retrieval, model output and tool authority across production applications.

Write one operational rule for each data class

Connect the AI rule to the organisation's existing information classification. Define examples employees recognise and name the owner who can approve an exception.

• Public: Allowed in sanctioned work accounts for approved tasks.
• Internal: Allowed only when the exact product, account and feature are approved; minimise the input.
• Confidential: Use a reviewed workflow with the required provider, identity, retention and DLP controls; approval may be required.
• Restricted: Block by default. Use only through a case-specific workflow approved by Security, Privacy, Legal and the data owner as applicable.

Restricted examples commonly include live credentials, private keys, authentication tokens, sensitive personal or health information, legally privileged material, payment data, active incident evidence, merger information and export-controlled material. Adapt the list to the organisation's legal duties, contracts and risk.

The policy should also state:

• approved products, plans, workspaces, accounts, models and features;
• approved purposes and prohibited decisions or actions;
• allowed prompt, paste, file, image, voice, IDE, API, connector and agent paths;
• the control for each data class: allow, audit, redact, require approval or block;
• who approves an exception, what evidence they see and when approval expires;
• incident reporting, credential rotation, deletion and notification routes; and
• the policy owner, review date and change triggers.

Use the Australian workplace AI policy guide for the broader governance document. This guide covers the data-leakage rollout and test plan.

Give employees a sanctioned path they can recognise

Employees need one usable route for common work. Publish a short approved-tool card in the service catalogue and inside onboarding:

1. Sign in with the organisation-managed account and confirm the expected workspace or tenant.
2. Use only the approved product and feature for the task.
3. Remove names, identifiers, secrets and unnecessary document sections before submission.
4. Use placeholders or approved test data when the task does not need real values.
5. Stop when the tool, account badge, connector, model or data handling differs from the approved card.
6. Report accidental disclosure immediately. Rotate any exposed credential without waiting for the full investigation.

Personal accounts, copied API keys and browser sessions can look similar to sanctioned workspaces. Make the managed identity visible, remove obsolete shortcuts and give employees one place to ask whether a use is approved. Training should use realistic job tasks and show why a block occurred, how to correct the input and how to request a narrow exception.

Discover Shadow AI without claiming protection

Build the inventory from procurement and SSO records, approved browser and endpoint signals, network metadata, expense records, staff reporting and application-owner review. Include public chatbots, embedded AI features, coding assistants, plugins, connectors, local models and direct APIs.

Record the source and confidence of each observation. A domain or process signal can show likely use while revealing nothing about whether a prompt was inspected. Keep discovery evidence content-minimised and proportionate to the governance purpose. Use the Shadow AI guide for the inventory fields and the distinction between discovered, reviewed and protected activity.

Roll out in detect-only mode first

Use controlled fixtures before watching workforce activity. Confirm that the sensor is present, policy is current and every claimed entry path reaches the decision point. Then pilot with representative teams and approved work accounts.

During detect-only operation:

• record the application, account class, entry path, finding type, policy version and delivery state without retaining routine prompt plaintext;
• review false positives, plausible misses, unsupported files, bypass routes, latency and employee confusion;
• separate observed, inspectable and enforceable paths in reporting;
• fix classification labels and employee guidance before broadening detectors; and
• define the evidence required to move each rule into enforcement.

Detect-only mode records findings and cannot stop delivery. Tell employees and decision-makers that limitation plainly. Urgent, high-confidence cases can be blocked from the outset when the path has already passed delivery tests and the business has a safe alternative.

Choose block, redact or approval by outcome

Block when disclosure is prohibited, the value cannot be made safe, the destination or account is unsanctioned, or required inspection cannot complete. Credentials and private keys normally require a block plus rotation if exposure may have occurred.

Redact when removing the matched value preserves the task. Show the employee what category was removed and keep the unsent draft available for correction. Recheck the transformed content before delivery because partial redaction can leave identifying context.

Require approval for a legitimate, unusual use where an accountable owner can assess the exact product, account, purpose, data class, recipients, connected features and retention. Bind approval to that request and an expiry. Broad or permanent overrides create a new unmonitored path.

A warning that employees can bypass is guidance. Report it separately from an enforced block. Provider-native controls can help: Microsoft Purview documents DLP options for sensitive prompt text, web search and labelled files or email in Microsoft Copilot, with plan, preview and content-coverage limits. The same page says direct file uploads in prompts are not scanned by that DLP location. Verify current tenant availability before relying on the control.

For GitHub Copilot Business and Enterprise, GitHub documents content exclusion for supported files and surfaces. GitHub also documents gaps for Edit and Agent modes in editors, IDE-supplied semantic information, symbolic links and remote filesystems. Treat exclusions as scoped controls and test the enabled IDE, mode and repository combination.

Test delivery, failure and rollback

Use test strings written for the exercise and non-functional credential-shaped canaries. Keep real employee, customer and production secret data out of tests, tickets, screenshots and retained logs.

Test every supported route:

• typed prompts, paste, drag and drop, file and image upload;
• browser, desktop, IDE, command-line, mobile and direct API paths;
• work and personal accounts, tenant switching and private browsing;
• web search, plugins, apps, connectors, retrieval and agent tools;
• local files, remote repositories, symbolic links and IDE-generated context;
• allow, detect, redact, approval, block and user-cancel outcomes; and
• stale policy, offline service, timeout, extension disablement, provider change and unsupported content.

Assert the decision and the delivery outcome. A visible warning or screenshot cannot prove that content stayed off the provider connection. Use a controlled network or provider-side oracle where possible, plus a content-minimised decision record that identifies policy, finding, action and delivery state.

Rollback needs an owner, a versioned previous policy and a rehearsed route. If a rule disrupts approved work, revert that rule or return the affected group to a declared detect-only state while the team investigates. Keep critical protections active where they remain valid, communicate the temporary boundary and retest before restoring enforcement.

Review controls on a set cadence and after changes

A practical starting point is a weekly review of incidents and active exceptions, a monthly review of control health and unsupported paths, and a quarterly review of products, provider terms, data classes and the sanctioned-tool register. Increase frequency for higher-risk use.

Review immediately after an incident, or after any change to a provider, plan, model, feature, connector, browser, IDE, policy, legal obligation or material use case. The OAIC calls for regular performance review, staff training and monitoring across the AI product lifecycle. ASD's ACSC AI data security guidance recommends classification, access control, minimisation, validation, monitoring, risk assessment and secure deletion across the lifecycle.

Track measures that lead to a decision: confirmed protected paths, unsupported paths, false-positive and missed-case investigations, override age, stale policy, control health, rollback use and time to rotate exposed credentials. Avoid presenting visits to an AI domain as prevented leakage.

Known limitations to publish

• No detector identifies every secret, personal record, confidential passage or transformed value.
• Browser controls cannot cover every desktop, mobile, API, local-model or embedded-AI path.
• File encryption, archives, images, remote filesystems, plugins and agents can create separate inspection gaps.
• Provider plans, tenant settings and connected features have different data-handling terms.
• Existing file permissions can be too broad, so an AI assistant may surface information the user can access but rarely encounters.
• A provider's no-training commitment does not decide purpose, disclosure, retention, administrator access or third-party connector risk.
• Detection and investigation can create employee privacy risks when evidence collection is excessive.
• Observed activity remains discovery evidence until the exact interaction path is verified as protected.

Publish these limits beside the approved-tool card and control status. Give employees a safe alternative when a path is unsupported.

How Promptective fits

Promptective discovers recognised and suspected AI activity and applies organisation policy before delivery on supported browser, desktop and code-assistant paths. Supported decisions can audit, block, redact or require approval, with routine evidence that excludes prompt and response plaintext.

Coverage depends on the exact application, provider, connection, device and deployed integration. Discovery alone remains observed activity. Verify each claimed path with the rollout and delivery tests above, and do not assume one Copilot product's coverage applies to another. Compare browser AI protection, desktop AI protection and Shadow AI governance to map current support to your workforce.

Primary sources

• OAIC: Guidance on privacy and the use of commercially available AI products, published 21 October 2024 and updated 17 January 2025.
• ASD's ACSC: AI data security, published 23 May 2025.
• OpenAI: Enterprise privacy, updated 8 January 2026 when reviewed.
• Microsoft: Enterprise data protection in Microsoft Copilot and Microsoft Copilot Chat, updated 18 August 2026 when reviewed.
• Microsoft Purview DLP for Microsoft Copilot and Copilot Chat, updated 11 June 2026 when reviewed.
• GitHub: Content exclusion for GitHub Copilot, reviewed 26 August 2026.

Reviewed by the Promptective security team on 26 August 2026. Provider features and terms change. Recheck the linked primary sources and test the exact deployed path before relying on a control. This guide provides operational security guidance and is not legal advice.