Welcome to this week's blog spotlight: How to Give AI Access to Sensitive Data Without Letting It Leave Your Network. If you've been wondering how to connect AI to your most sensitive systems without handing over the keys, this one is for you!
Why This Matters
The blog frames MCP around a simple principle: expose tools, not systems. Rather than giving a model direct access to a database or file share, you give it a defined tool that takes specific parameters and returns structured results — the model never sees what's underneath. For organizations sitting on sensitive data in on-premises databases, CAD/BIM repositories, or geospatial systems, that distinction is what makes AI adoption possible without a compliance nightmare.
Inside the Blog
The post covers the full spectrum of keeping data protected while still letting AI act on it. A few highlights:
- Any FME workspace can become an MCP tool the same way as before. Swap in an MCP writer, publish to FME Flow, register with clear parameters — but the emphasis here is what that unlocks: any MCP-capable client gets FME's full readers, writers, transformers, and spatial capabilities, not raw database access.
- The strongest protection is running the entire stack — model, client, and server — on-premises. Pairing a local client (LM Studio, Goose, Ollama) with an open-weight model (Gemma, Qwen) means nothing crosses onto the internet, which is what makes this viable for regulated or air-gapped environments.
- When data does need to reach the outside world, FME acts as a "data guardian" with three layers of filtering, from strongest to weakest: never load sensitive fields in the first place, strip them mid-workflow if they must be loaded, or restrict what the output/writer sends back.
- You don't need a frontier model for everything, matching a smaller local model to a well-scoped task keeps both cost and data under control.
Key Takeaways
The practical advice stands out just as much as the architecture. Tool, server, and parameter descriptions are what let a model pick the right tool and call it correctly — vague documentation, not a weaker model, is almost always the real cause of wrong tool calls, especially for local models that can't lean on broad cloud-scale reasoning to guess your intent.
Join the Conversation
Do you have a workflow that touches sensitive data right now, one you'd want AI to help with but haven't exposed yet? Where would you draw your own filtering line, at the source, mid-workflow, or at the output? Let us know below!
See you next time for another blog spotlight