Launched this week
Kravn
The self-hosted enterprise MCP gateway
13 followers
The self-hosted enterprise MCP gateway
13 followers
Kravn is a self-hostable enterprise MCP gateway: bring the Model Context Protocol on-prem, with SSO/SCIM/RBAC and no data leaving your network.
Took it for a spin on a test cluster and the SSO setup was painless, plus it's nice seeing the MCP traffic stay inside the network instead of bouncing to some external proxy. Curious how it handles auth for a large batch of internal tools though.
@keremerifooyuk Appreciate you digging in — and yeah, keeping the MCP traffic on-network is one of the core design goals, so glad that came through. Here's the whole picture:
Fronting many MCP servers at once. Kravn sits in front of all your MCP servers together — it connects to each upstream (streamable-HTTP, SSE or stdio), pulls their tools, resources and prompts into a single registry, and re-exposes them behind curated MCP endpoints. So a client points at Kravn, not at a dozen scattered servers, and you get one governed surface over the lot.
Auth for a large batch of tools. The model is curation + team entitlement, not per-tool ACLs — that's what keeps it sane at scale. An admin composes an endpoint (a named bundle that explicitly lists which tools it carries) and grants it to teams (public / authenticated / restricted-to-teams). You add a person to a team, not to N tools. You can narrow which tools of an endpoint a given team gets, but the default is the whole bundle, so config effort grows with exceptions, not with tool count. The reachable set is recomputed as a filter over live entitlement on every request — teams are re-read from the DB (never baked into the token), and the same filter governs both tools/list and tools/call, so an un-entitled tool is invisible and uncallable. Revoke a team's access and the next call can't reach it.
Credential security. Each upstream's credentials (API keys, OAuth tokens, mTLS keys) are encrypted at rest with AES-256-GCM at the field level; for key custody you can put an external KMS/HSM in front (HashiCorp Vault Transit or Azure Key Vault envelope encryption — the key-encryption key never leaves the KMS). Just as important: Kravn doesn't forward end-user identity to third-party upstreams — each upstream sees Kravn's own per-server credential, not the user, so a compromised upstream can't impersonate your people. And all egress runs through an SSRF-pinning dispatcher (DNS resolved in-process and pinned to the socket to kill rebinding, cloud metadata IPs always blocked, TLS verification always on), so nothing bounces off-network or gets redirected to an internal target.
On top of that, every tool call is recorded in a tamper-evident audit trail (who called which tool, on which endpoint, with which args + outcome), exportable to your SIEM. It's all source-available, so none of this is a black box
Congrats on shipping Kravn. For teams rolling this out, having a built-in audit log viewer with filters by user, tool, and time would save a ton of compliance headaches. Maybe pair it with CSV export so security teams can pipe it into their existing SIEM without extra glue code.
@meralelkatk5hf Hi Meral! Thanks a lot — and good callout on the compliance side.
On the SIEM piece specifically, the good news is Kravn already covers this without a CSV export or any glue code. Two paths:
1. Structured stdout (always on)
Every audit event is emitted as a single JSON line through a dedicated logger, tagged so your collector can pick it out cleanly:
json
Fields are in snake_case with a versioned schema, so Fluent Bit / Filebeat / Vector (or whatever log pipeline your k8s cluster already runs) can filter on audit:true and forward it straight to your SIEM. It's vendor-agnostic — the same setup works for Splunk, Sentinel, QRadar or Elastic.
Two details worth flagging: the prev_hash/hash fields form a hash chain, so the log is tamper-evident out of the box. And the event is exported even if the DB write fails — if the database goes down, your SIEM still receives the record and you don't lose the audit trail.
2. Webhook
If you'd rather push events instead of tailing logs, there's a webhook you can configure under Configuration → Observability (screenshot below).
Spent an afternoon poking at it on a staging box and was surprised how clean the SSO + RBAC setup was, took maybe ten minutes to get going. Nice to see an MCP gateway that actually feels built for on-prem rather than bolted on.
self hosted MCP gateway with proper RBAC is honestly so needed, finally someone is taking this seriously. one thing though, can you add granular audit logging per tool call so admins can actually see which models are touching which data. that would make the security pitch way stronger for enterprise buyers
finally someone tackling MCP for actual enterprise use cases with self-hosting and proper auth controls, the SCIM and RBAC baked in right out of the gate shows they get what IT teams actually need