Every time you send something to an AI tool, data leaves your control. Most teams underestimate both how much goes out and what the provider does with it once it arrives. This play is a practical guide to sharing data with AI tools safely: knowing what is transmitted, classifying it by risk, sanitizing before you share, and centralizing control through a gateway.

When to use this play#

Use it whenever your team uses LLMs or AI development tools that send data to an external provider, which is to say almost always. It is most valuable before something goes wrong, as the standing policy people work from, but it also includes the steps to follow if sensitive data has already been shared.

Know what gets transmitted#

When you use an AI tool, more goes to the provider than the words you typed: prompts, code snippets, file contents, the surrounding conversation context, and metadata all leave with the request. And what the provider does with it varies. Expect temporary retention for safety monitoring, often on the order of 30 to 90 days; possible use for service improvement; and sometimes training, which varies by provider and is sometimes opt-out. Enterprise terms usually offer stronger protections than consumer terms, and all of these policies change often. The safe assumption is that anything you send could be retained.

Tier your data by risk#

Sort what you might share into three tiers and act accordingly:

• Never share — personal data, secrets, keys, and tokens, financial and billing data, and proprietary strategy or pricing.
• Use with caution — sanitized configuration files and general debugging questions that have been stripped of specifics.
• Generally safe — questions about public libraries, standard concepts, public error messages, and best-practice discussions.

The guiding rule: when in doubt, do not share it. Ask a more generic version of the question or sanitize first.

Sanitize before you share#

Before sending anything from the cautious tier, run it through a checklist:

• Strip secrets and connection strings.
• Tokenize hard-coded values.
• Remove personal data.
• Remove proprietary markers that identify the work or the client.

Route through a gateway#

A gateway, such as an MCP gateway, is how you turn individual judgment into enforced policy. It gives you centralized control, a full access log and audit trail, server-side filtering and sanitization, and granular role-based permissions. Crucially, it means no internal system connects directly to an external LLM; the gateway sits in between. Individual discipline is good, but a gateway is what makes the policy hold up at scale.

Govern access#

• Grant access by role, not by default.
• Require manager approval for elevated access.
• Review access quarterly and remove what is no longer needed.

If sensitive data is shared anyway#

Mistakes happen. When sensitive data goes out, respond on a known path rather than improvising:

1. Document what was shared and when.
2. Request data deletion from the provider.
3. Notify operations.
4. Decide whether client notification is warranted.
5. Update your sanitization procedures and training so the same gap does not reopen.

Keep reviewing on a cadence#

• Monthly — review usage logs and access audits.
• Quarterly — run a full content audit, update the policy, and assess any new tools.
• Annually — conduct a security audit and a penetration test of the gateway.

Common traps#

• Assuming only the prompt is sent. File contents, conversation context, and metadata go too. People leak data they never consciously typed.
• Trusting consumer terms with sensitive data. Consumer terms typically retain and sometimes train on your data. Match the terms to the sensitivity.
• Relying on individual judgment alone. Discipline varies and people are busy. The gateway is what enforces policy when attention lapses.
• Skipping sanitization on "just a config file." Configuration files are full of connection strings and hard-coded values. They belong in the cautious tier for a reason.
• No plan for a leak. Improvising after sensitive data goes out wastes the narrow window where deletion requests and client notification matter most.

Signals it's working#

• People reach for the generic version of a question by default.
• The gateway's audit trail can answer "what did we send, and when" without guesswork.
• Access reviews actually remove stale permissions each quarter.
• The rare leak gets documented and routed through the response steps instead of quietly hoped away.