Credit card numbers, API keys, passwords, personal information. You know this stuff shouldn't reach the LLM. The question everyone skips is: how do you actually prevent it?

The UI used to be the protection layer

For years, we protected sensitive data by controlling what showed up on screen. Hide it in the UI, obscure it, put it behind a permissions wall that the user never needed to pass. That worked fine when humans were the only ones looking at the screen.

Now you're giving an AI agent access to that screen. Or pumping data into it for context. Or letting it go and fetch information from your systems. The UI isn't the protection layer anymore. You need to think about data access differently.

What to strip, mask, or block

Not all sensitive data needs the same treatment. Some things should never reach Claude at all. Others can be masked with placeholders so Claude knows there's a value there without seeing the actual data.

  • Strip entirely: credit card numbers, CVVs, API keys, passwords, private keys, tokens
  • Mask with placeholders: names, email addresses, phone numbers, physical addresses
  • Block or review: proprietary source code, trade secrets, internal financial data
  • Allow with logging: general business context, process descriptions, public information

The important thing to remember: Claude often doesn't need exact data. It needs the shape of data. You can strip out specific details and still get the full value of what the LLM gives you back. A customer reference number instead of a full name. A price range instead of exact contract terms. You lose very little richness while keeping sensitive information out of the loop entirely.

Build a middle layer with MCP

One practical approach: build an MCP server that sits between Claude and your data. MCP (Model Context Protocol) lets you define exactly what information gets passed through and what gets withheld. Think of it as a controlled access point. Claude asks for data, the MCP server applies your rules, and only the approved information comes back. Credit card numbers get stripped. Customer names get replaced with identifiers. Confidential fields get blocked entirely.

This takes some setup. You need someone who understands your data model and can write the filtering rules. But once it's in place, it handles the problem consistently across every interaction. No relying on individual employees to remember what's safe to share with the AI.

Give Claude fewer permissions than you have

Another approach, and often simpler: treat Claude as an employee with restricted access. You, the professional, have full access to everything. Claude gets a limited view. Set up its access the way you'd set up a junior hire who doesn't need to see payroll data or client banking details.

When something comes up that requires higher-level access, you handle it yourself. Go to the UI, click the buttons, approve the transaction. Keep those actions in your hands and out of Claude's. This is especially practical for smaller teams where building a custom MCP server feels like overkill. Sometimes the simplest protection is just not giving the AI the keys to the rooms it doesn't need to enter.

There's no single right way to handle this. Some businesses need the MCP approach for scale. Others get by with permission-based access control. Most end up using both, depending on the system and the sensitivity of the data involved. The point is to think about it before deployment, not after something leaks.