Octelium is a self-hosted Model Context Protocol gateway built around authenticated identity and protocol-aware policy. Control which humans, workloads and AI agents can discover and invoke tools, inspect what crosses the client/server boundary, isolate MCP server credentials, route calls dynamically and audit each MCP exchange.
Unified identity management for humans, workloads and AI agents
Adaptive authentication for humans and non-human identities
Identity-based, application-layer-aware access control
OpenTelemetry-native real-time visibility and auditing
Unified access architecture for private and SaaS resources
Every request from a human, a browser, a CLI, a workload or an AI agent is authenticated against your identity providers, authorized per request at the application layer by the Octelium Service in front of the resource, exported to your SIEM and observability stack whether it is allowed or denied, and only then routed to the upstream HTTP API, database, SSH server, Kubernetes cluster, LLM or MCP server.
Identity-aware access control
Control MCP access down to the method, tool and argument
An MCP connection does not grant blanket access to an MCP server. Octelium authenticates the caller, parses the JSON-RPC request and evaluates identity together with the method, logical target and request body before the call reaches an upstream server.
MCP gateway, Managed containers: Deploy and scale the MCP server itself inside the Cluster. finance-mcp.yaml reads as follows.
kind: Service
metadata:
name: finance-mcp
spec:
mode: MCP
config:
upstream:
container:
image: ghcr.io/acme/finance-mcp:1.4.0
port: 8080
replicas: 3
resourceLimit:
cpu:
millicores: 1000
memory:
megabytes: 2000
mcp:
endpoint: /mcp
replicas: 3: 3/3 ready
MCP security controls
Inspect what agents send and what MCP servers return
MCP introduces a two-sided content boundary: agents send structured arguments to tools, while servers return tool results, resources, prompts and tool definitions that can influence an agent. Octelium provides protocol-aware controls on both directions.
Keep MCP server credentials out of agents and applications
Clients authenticate to Octelium with their own identity. The gateway separately authenticates to the selected MCP server after access is allowed, so server credentials do not have to be distributed across agent runtimes, developer machines or automation systems.
Validate MCP traffic before it reaches an upstream server
Octelium understands MCP's JSON-RPC and streamable HTTP semantics at the gateway boundary. Enforce the protocol surface exposed to clients instead of relying on every MCP server to implement the same transport and compatibility controls.
Every MCP exchange can be tied to the authenticated Octelium identity that initiated it rather than to self-reported client metadata. Structured protocol-aware logs make tool use, server responses and failures visible to security and platform teams.
Run and automate the MCP gateway on infrastructure you control
Octelium runs on Kubernetes and can protect existing MCP servers or deploy the servers itself. Manage the platform declaratively or programmatically without depending on a hosted control plane in the MCP request path.
Cluster resources applied declaratively from YAML with octeliumctl and managed programmatically with the Go, TypeScript, Python and Rust SDKs
GitOps: cluster.yaml in the main branch of the ~/octelium repository describes the desired state of the Cluster. Its diff reads as follows, with + for added, ~ for changed and - for removed lines.
+ kind: Group
+ metadata:
+ name: payments
+ spec: {}
+ ---
+ kind: User
+ metadata:
+ name: alice
+ spec:
+ type: HUMAN
+ email: alice@acme.com
+ groups: ["payments"]
---
kind: User
metadata:
name: bob
spec:
type: HUMAN
~ groups: ["payments"]
---
kind: Service
metadata:
name: billing
spec:
mode: HTTP
config:
upstream:
~ url: http://10.0.3.24:8080
- ---
- kind: Service
- metadata:
- name: billing-legacy
- spec: ⋯
- ---
- kind: User
- metadata:
- name: john
- spec: ⋯
~/octelium ❯ octeliumctl apply --prune .
Group: payments Created
User: alice Created
User: bob Updated
Service: billing.default Updated
Service: billing-legacy.default Deleted
User: john Deleted
Cluster Core resources successfully applied
2 resources created
2 resources updated
2 resources deleted
Go: main.go uses the octelium-go SDK to list the Users of the Cluster and update the email and Policies of linus.
Identity, protocol context, content controls, routing, credentials and audit data are evaluated within the same gateway request path, so each MCP action can be controlled and attributed consistently.
01
Identity-aware access control
Authorize MCP methods, tools, prompts, resources and parsed arguments using authenticated User, Group, Session and Device context with CEL or OPA policy.
Keep bearer tokens, API keys, basic credentials, OAuth2 client secrets and AWS signing credentials inside the Cluster rather than distributing them to agents.
Record methods, targets, arguments and results, stream lifecycle, protocol errors and tool errors with authenticated identity and export them through OpenTelemetry.
Deploy and horizontally scale containerized MCP servers with Secrets, resources, volumes, security contexts and health probes on the same Kubernetes platform.
Octelium parses and validates MCP JSON-RPC instead of treating it as opaque HTTP. Policies and dynamic configuration can use the normalized protocol version, method and logical target together with the complete parsed request body. Finite JSON responses and streamed SSE responses are supported.
How granular is MCP access control?
Access can be controlled at the JSON-RPC method, tool, prompt or resource level and can include values inside parsed arguments. For example, a Policy can allow tools/list for discovery while allowing tools/call only for specific identities, tools and argument constraints.
Does Octelium trust MCP client or session metadata as identity?
No. MCP client name, version, capabilities, request IDs and Mcp-Session-Id values are supplied by the downstream client and are treated as protocol and audit context, not authenticated identity. Security decisions use the authenticated Octelium User, Groups, Session and Device context.
Can different tools be routed to different MCP servers?
Yes. Dynamic configuration can choose the upstream MCP server, its credential and the applicable request-processing configuration from authenticated identity and MCP request context. This allows sensitive tools to be isolated behind dedicated servers and credentials while clients continue to use one controlled gateway.
What MCP guardrails are available?
Request guardrails inspect tool arguments for configured patterns, personal information and secrets and can deny, redact, strip or replace matching request content. Response guardrails inspect tool results, resource contents, prompt messages and tool definitions and can block restricted server-supplied content before it reaches the client.
Can Octelium validate or modify MCP traffic?
Yes. MCP Services can use JSON Schema validation, request rate limits, conditional path handling, Lua and Envoy-compatible ExtProc processing. Lua and ExtProc can intentionally rewrite JSON-RPC requests or responses; rewritten requests are parsed and validated again before later MCP controls run.
How are MCP server credentials handled?
The credential used by an agent to access Octelium is separate from the credential used to access the upstream MCP server. Bearer tokens, custom API keys, basic credentials, OAuth2 client credentials and AWS Signature Version 4 credentials can remain inside the Cluster and be applied after authorization. Downstream authorization credentials are not forwarded by default.
What can teams audit about MCP activity?
Identity-aware MCP logs can include the protocol version, JSON-RPC method, tool, prompt or resource target, request and response bodies, stream lifecycle, result type, protocol errors and tool errors together with the authenticated User, Session, Device, Service and Policy decision. Logs can be exported through OpenTelemetry OTLP.
Can Octelium run the MCP servers as well as protect them?
Yes. An MCP Service can proxy an existing server or deploy a containerized MCP server as a managed upstream. Managed servers can be horizontally scaled and configured with Secrets, resource limits, volumes, security contexts and health probes on the Kubernetes infrastructure running the Cluster.
Is Octelium open source and self-hosted?
Yes. Octelium is designed to run on Kubernetes infrastructure you control with no mandatory hosted control plane in the MCP data path. Cluster configuration can be managed declaratively with YAML and GitOps or programmatically through gRPC APIs and the Go, TypeScript, Rust and Python SDKs.