The problem nobody talks about
Companies adopted AI at full speed. And there's a problem that doesn't get enough attention: almost every tool is SaaS-first. Along the way, the company loses control over its own information — which data feeds the AI, where its tools live, and what ends up traveling to a cloud model.
For many organizations, that's a minor detail. For anyone in a regulated environment — banking, healthcare, government, fintech — it's a serious problem.
And here's the frustrating part: self-hosted alternatives usually fail exactly where the enterprise needs them most — integration with corporate identity (SSO, SAML, SCIM, team-based access).
A quick primer on MCP
If you haven't run into it yet: MCP (Model Context Protocol) is basically the "USB-C" for connecting AI to your tools. Instead of building a custom integration for every model and every system, MCP standardizes how an AI accesses your data sources and tools.
It's powerful. But in an enterprise, that same power is the risk: if an AI can reach your tools through MCP, what exactly is it reaching, on whose behalf, and what leaves the perimeter?
The two halves of the problem
When you try to put governance around enterprise AI, you actually face two separate problems:
- Control — what the AI can touch, and what data is allowed to leave.
- Adoption — whether people actually use the governed path, or route around it.
That second one is underrated. If the governed tool is annoying to use, people bypass it. They just open ChatGPT in another tab, paste the document there, and all the control you built becomes decorative. Shadow AI is rarely born from bad intent — it's born from friction.
How I approached it
I've been building something to close this gap (a few weekends' worth 😅). It's called Kravn — a self-hostable MCP gateway aimed at enterprises. I'll use it here as a concrete example of the design decisions, not as a pitch — the ideas apply whether you use it or build your own.
Two core principles:
What has to stay inside, stays inside. It runs 100% on your own servers, connected to your own systems, with no dependency on anyone's cloud.
What does leave, leaves governed. Nothing travels to a model blindly: you can redact secrets and PII, block or sanitize content, stop prompt-injection, and audit every single call.
All wired into your identity stack (SAML / OIDC / SCIM / RBAC / teams), starting with a single command (docker compose up / helm install).
The design decision I care about most
For the end-user side, there's one rule that I think matters more than any feature: the client never grants permissions.
A project or an agent can only ever filter down what that person was already allowed to access — it can never hand them an extra tool. And it's re-validated on every message. It can never become a back door around the governance you configured.
This sounds obvious but it's easy to get wrong: the moment a "convenience" feature can widen access, your whole governance model has a hole in it.
Why source-available matters here
A security team can't trust a black box sitting in the middle of every AI call. So it's source-available — you can read it, run it, and audit it. For infrastructure that governs sensitive data flows, "trust me" isn't good enough; "here's the code" is.
If you're evaluating MCP for your org
MCP is still new, and a lot of teams are just discovering it. If you're weighing it up, the questions worth asking — of any solution, mine or otherwise — are:
Does it run fully within my perimeter?
Does it integrate with my existing identity (SSO/SCIM/RBAC)?
Can it govern what leaves — redaction, sanitization, audit?
Can any user-facing convenience feature ever widen access? (It shouldn't.)
Can my security team actually read what it does?
If you work in platform, security, or AI adoption at a company that can't (or won't) let its information reach the cloud blindly, I'd love for you to take a look and tell me what you think 🙌
👉 https://kravn.ai
📚 Deeper guides on MCP gateways, auth, governance and on-prem/K8s: https://kravn.ai/learn
Built as source-available — read it, run it, audit it.
Top comments (0)