Octelium
NEW

Introducing Cordium — Identity-based Sandboxes for Developers & AI Agents

Enterprise

Scale Octelium to meet your organization's needs

Whether you're a startup, a service provider, or a global enterprise, we can help you run Octelium at scale with a centralized web console, real-time visibility, compliance-ready features, and a commercial license.

Join SlackContact usQuick install
  • Centralized control dashboardManage every Cluster resource from one console.
  • Agentic AI assistantRun your Cluster in plain language with your AI provider.Integrates with OpenAI, Claude, Gemini.
  • UI-based policy builderCompose CEL rules from predefined conditions.
  • Policy testerEvaluate Policies for a User and Service before rollout.
  • MCP and LLM playgroundsTry requests and inspect every Policy decision.
  • Authentication & audit logsRecord every sign-in and every resource change.
  • SSH session recordingReplay sessions beside their Access Logs.
  • Real-time visibilityLive Sessions, Devices and Services by Region.
  • OpenTelemetry & SIEMStream logs and metrics to your SIEM.Integrates with Datadog, Splunk, Elastic, Grafana.
  • User & Group provisioningSCIM 2.0 and directory synchronization.Integrates with Microsoft Entra ID, Okta, Google Workspace, Keycloak.
  • Just-in-Time accessRequest, review and grant temporary access.
  • Encrypted Secret managementEncrypt Secrets at rest with KMS or Vault.Integrates with AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault.
  • Automatic DNS & TLSPublish DNS records and rotate TLS certificates.Integrates with Cloudflare, Amazon Route 53, Let's Encrypt.
  • Multi-region ClustersSpan Kubernetes clusters, regions and clouds.
  • Managed upgradesUpgrade Cluster packages from the console.
  • Premium support & licensingA private Slack channel and a commercial license.Integrates with Slack.
The console

Centralized web-based control dashboard

A unified web console for Cluster administrators to manage all the Cluster resources at scale and have a real-time visibility.

Cluster overview

  • Cluster overview for acme.com over the last 24 hours.
  • Requests: 108M, 196 users · 148 services.
  • Denied: 43.6K (0.04%), 108M allowed in the last 24 hours.
  • Logins: 842, 196 users · 41 re-auths.
  • Connected: 316 (1.2K total), 286 new sessions in the last 24 hours.
  • Access requests: 27 (3 pending), 9 active grants · 412 all time.
  • Errors: 12, 38 warnings across 23 components.
  • Access activity: 108M authorization decisions, 99.96% allowed, with a spike of 19,100 denied requests at 11:00.
  • Top users: ci-runner with 31.2M requests, etl-runner with 22.4M requests, support-bot with 14.1M requests, linus@acme.com with 2.1M requests, jane@acme.com with 960K requests.
  • Top services: api.prod with 40.2M requests, analytics.data with 15.2M requests, k8s-prod.infra with 12.1M requests, grafana.monitoring with 4.1M requests, anthropic.ai with 640K requests.

Agent: charting the activity of a database

  • Jane asks the Agent: "Show me the activity of analytics.data in the last hour".
  • The Agent calls visibility.v1.AccessLogService/GetAccessLogDataPoint and visibility.v1.AccessLogService/ListAccessLogTopUser, then charts the requests per minute.
  • analytics.data served 634.6K requests in the last hour and denied 139. Traffic peaked at 14:44 with 18.9K requests per minute, driven by the hourly etl-runner export. Most denials came at 14:20 from support-bot, querying payments.cards, which no Policy allows.
  • Top users: etl-runner with 316,480 requests, linus@acme.com with 139,440, support-bot with 116,160 and 121 denied, dana@acme.com with 62,560.

Access logs

  • Access logs over the last 24 hours: 108M requests, 99.96% allowed and 43,620 denied, with 19,100 at 11:00.
  • support-bot to github-mcp, denied, MCP tools/call delete_repository, no policy match, Namespace ai, 9ms.
  • linus@acme.com to k8s-prod, allowed, KUBERNETES list production/pods, policy match, Namespace infra, 21ms.
  • ci-runner to api, allowed, HTTP POST /v1/deployments, policy match, Namespace prod, 42ms.
  • etl-runner to analytics, allowed, POSTGRES QUERY, policy match, Namespace data, 118ms.
  • support-bot to anthropic, allowed, LLM claude-sonnet-5-5 /v1/messages, policy match, Namespace ai, 3.2s.
  • noah@acme.com to bastion, allowed, SSH SESSION_START, policy match, Namespace infra, 1m 48s.
  • omar@acme.com to grafana, allowed, WEB GET /d/prod-overview, policy match, Namespace monitoring, 18ms.
  • agent-07 to k8s-prod, denied, KUBERNETES delete production/secrets/stripe-keys, no policy match, Namespace infra, 4ms.
  • The denied MCP request of support-bot to github-mcp.ai was tools/call delete_repository with the arguments {"owner":"acme","repo":"billing-legacy"}, with no Policy allowing it.

Agent: creating a PostgreSQL Service with an approved Secret

  • Jane attaches billing-db.env and asks the Agent: "Create a Postgres Service billing-db for billing-db.internal:5432 using the password in this file".
  • The Agent reads uploads/billing-db.env and asks for approval to call core.v1.MainService/CreateSecret for the Secret billing-db-password. Jane approves.
  • The Agent asks for approval to call core.v1.MainService/CreateService for billing-db.finance in POSTGRES mode, with the upstream postgres://billing-db.internal:5432, the user billing_app, the database billing and the password from the Secret billing-db-password. Jane approves.
  • Created billing-db.finance in POSTGRES mode. The password lives in the Secret billing-db-password and the Cluster injects it upstream, so Users and agents connect with psql -h billing-db.finance without ever holding it.

SSH session recordings

  • ssh-4f9a2c1e7b30: noah on bastion.infra from the Session noah-macbook-8f2a, started 6m ago, lasted 1m 48s.
  • ssh-91bd07aa2c64: linus on db-admin.infra from the Session linus-cli-77d2, started 2m ago, still ongoing.
  • ssh-2c7e55f0d913: ci-runner on deploy.prod from the Session ci-runner-gh-71b0, started 11m ago, lasted 14s.
  • ssh-b81a3d92e047: dana on bastion.infra from the Session dana-firefox-a14e, started 38m ago, lasted 6m.
  • Replay of ssh-4f9a2c1e7b30:
  • Welcome to Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-1021-aws x86_64)
  • System load: 0.31 Processes: 142
  • Usage of /: 41.2% of 47.39GB Users logged in: 1
  • Memory usage: 38% IPv4 address: 10.0.4.21
  • Last login: Sat Oct 10 09:12:44 2026 from 10.0.1.4
  • noah@bastion:~$ systemctl status payments --no-pager | head -3
  • ● payments.service - Payments API
  • Loaded: loaded (/etc/systemd/system/payments.service; enabled)
  • Active: active (running) since Sat 2026-10-10 09:12:44 UTC; 1 day ago
  • noah@bastion:~$ journalctl -u payments --since "15 min ago" | grep -c ERROR
  • 37
  • noah@bastion:~$ sudo systemctl restart payments
  • noah@bastion:~$ curl -s localhost:8080/healthz
  • {"status":"ok","version":"4.12.1"}

Agent: querying the new database without its password

  • Jane asks the Agent in the same conversation: "Now connect to it and list the 5 most recent invoices".
  • The Agent runs psql -h billing-db.finance -d billing -c "SELECT id, customer, total, status FROM invoices ORDER BY created_at DESC LIMIT 5" from its Workspace.
  • id | customer | total | status
  • -------+----------------+----------+---------
  • 10482 | Northwind GmbH | 4210.00 | paid
  • 10481 | Globex Corp | 980.50 | open
  • 10480 | Initech | 12400.00 | paid
  • 10479 | Umbrella Ltd | 356.25 | overdue
  • 10478 | Hooli | 2145.90 | paid
  • (5 rows)
  • The query ran as jane@acme.com through billing-db.finance, with the password injected by the Cluster, and it is recorded in the access logs.

Services

  • Services: 148 in total, 41 HTTP, 18 Web, 11 Postgres, 9 SSH, 6 Kubernetes, 7 MCP, 5 LLM and 12 TCP.
  • billing-db.finance, Billing database: Production billing PostgreSQL behind the finance VPC. Mode POSTGRES, Namespace finance, port 5432.
  • analytics.data, Analytics warehouse: Read replicas of the analytics PostgreSQL cluster. Mode POSTGRES, Namespace data, port 5432.
  • api.prod, Public API: The customer-facing REST API. Mode HTTP, Namespace prod, port 8080.
  • k8s-prod.infra, Production EKS: The production Kubernetes API server. Mode KUBERNETES, Namespace infra, port 443.
  • bastion.infra, SSH bastion: Recorded SSH access to the private subnets. Mode SSH, Namespace infra, port 22.
  • github-mcp.ai, GitHub MCP: GitHub MCP server running as a managed container. Mode MCP, Namespace ai, port 8080.
  • billing-db.finance: POSTGRES on port 5432 in the Namespace finance, upstream postgres://billing-db.internal:5432, private FQDN billing-db.finance.local.acme.com, Postgres user billing_app, database billing, password injected from the Secret billing-db-password.
  • Access log of billing-db.finance: jane@acme.com, allowed, POSTGRES QUERY SELECT id, customer, total, status FROM invoices ORDER BY created_at DESC LIMIT 5, Session jane-agent-7f2c, 6ms.
  • Access log of billing-db.finance: jane@acme.com, allowed, POSTGRES SESSION_START billing_app@billing, Session jane-agent-7f2c, 1.4s.
  • Access log of billing-db.finance: linus@acme.com, denied, POSTGRES SESSION_START billing_app@billing, Session linus-cli-77d2, 3ms.

Cluster metrics

  • Cluster metrics over the last 6 hours.
  • Request rate: 1,424 requests/s.
  • Active requests: 212 requests.
  • Authorization p95: 1.82 ms.
  • CPU usage: 3.4 cores.
  • Request rate by component: vigil peaks at 991 requests/s at 10:30, octovigil at 377, apiserver at 119, ingress at 72. Latest 1,424 requests/s, average 1,279, peak 1,483.
  • Denied requests by reason: No policy match spikes to 9,840 at 11:00, while Authenticator required and Session expired stay under 30 per interval.

LLM visibility

  • LLM visibility over the last 24 hours.
  • Requests: 48,213 (31,880 streamed).
  • Denied: 412 (0.85%).
  • Total tokens: 182.4M (141.2M in · 41.2M out).
  • Reasoning tokens: 18.9M (12,402 managed requests).
  • Guardrail denials: 57 (9 modified · 0 errors).
  • Cache hit rate: 18.4% (8,871 served from cache).
  • P95 latency: 6.2s (avg 2.4s).
  • P95 TTFT: 820ms (avg 410ms).
  • claude-opus-5-5 by Anthropic: 18.2K requests, 96.4M tokens.
  • gpt-6.1 by OpenAI: 12.9K requests, 44.8M tokens.
  • claude-sonnet-5-5 by Anthropic: 9.6K requests, 27.1M tokens.
  • gpt-6.1-mini by OpenAI: 5.3K requests, 9.7M tokens.
  • claude-haiku-5-5 by Anthropic: 2.2K requests, 4.4M tokens.
  • claude-opus-5-5 Messages request from jane@acme.com through anthropic /v1/messages: 18.2K / 1.4K input and output tokens, 7.9s · 610ms.
  • gpt-6.1 Responses request from support-bot through openai /v1/responses: 2.1K / 0 input and output tokens, 180ms, denied by a guardrail.
  • claude-sonnet-5-5 Messages request from support-bot through anthropic /v1/messages: 6.8K / 512 input and output tokens, 1.2s · 240ms.
  • gpt-6.1-mini Chat request from ci-runner through openai /v1/chat/completions: 1.1K / 260 input and output tokens, 900ms · 180ms.

Agent: approving an access request

  • The conversation "Approve noah's access request" waits for approval: "Approve the pending access request from noah@acme.com".
  • noah@acme.com has one pending Request, noah-analytics-4f1c, for analytics.data for 2 hours, with the reason Q3 revenue report.
  • Jane approves the call to access.v1.ReviewerService/SetReviewDecision with the decision DECISION_APPROVE.
  • Approved. noah@acme.com now has access to analytics.data for 2 hours, until 16:20, and the Cluster revokes it automatically after that.

Authentication logs

  • Authentication logs over the last 24 hours: 842 authentications of 196 Users, 41 re-authentications, 69% at AAL2 or above.
  • noah@acme.com authenticated with authenticator noah-yubikey at AAL3, Session noah-macbook-8f2a, from 203.0.113.48 in Lisbon, PT.
  • jane@acme.com authenticated with identity provider okta at AAL2, Session jane-console-3c9d, from 198.51.100.12 in Berlin, DE.
  • ci-runner authenticated with credential github-actions-oidc at AAL1, Session ci-runner-gh-71b0, from 140.82.112.4 in Ashburn, US.
  • support-bot authenticated with credential support-bot-token at AAL1, Session support-bot-k2f9, from 10.20.4.17.
  • dana@acme.com authenticated with refresh token dana-firefox-a14e, Session dana-firefox-a14e, from 192.0.2.77 in Toronto, CA.
  • linus@acme.com authenticated with identity provider github at AAL2, Session linus-cli-77d2, from 198.51.100.31 in Helsinki, FI.
  • omar@acme.com authenticated with authenticator omar-totp at AAL2, Session omar-chrome-2be5, from 192.0.2.140 in Dubai, AE.
  • noah@acme.com re-authenticated with the FIDO2 passkey noah-yubikey at AAL3 from a MacBook Pro running macOS 16, as required by Policy.
Visibility

Authentication and Audit Logs

Monitor authentication in real time. Audit every resource change in the Cluster. Replay SSH sessions

  • Dedicated structured Authentication logs for every authentication event, carrying the identity provider, the credential, the authenticator and the assurance level behind it.
  • Audit logs recording every resource modification in the Cluster, with the API method that made it and the User, Session and Device behind it.
  • Replay SSH sessions in the web console.
How visibility and logs work

Authentication logs record every authentication with the authenticator, assurance level, Session and Device behind it; audit logs record every resource change with the API method, the User and the Session that made it; SSH sessions are recorded and replayed in the console.

  • noah@acme.com authenticated with the FIDO2 passkey noah-yubikey at AAL3, Session noah-macbook-8f2a, from a MacBook Pro in Lisbon.
  • jane@acme.com called PolicyService/UpdatePolicy on the Policy deny-destructive from Session jane-console-3c9d, changing its rule from ALLOW to DENY on DELETE requests.
  • marco@acme.com's SSH session to bastion was recorded and replayed: $ systemctl status payments; ● payments.service - Payments API; Active: active (running) since 14:02; $ journalctl -u payments -n 2; 14:31:02 upstream timeout (retrying); 14:31:04 recovered after 2 tries; $ exit.
Telemetry

OpenTelemetry integration with SIEM providers

Scalable OpenTelemetry collectors that concurrently export Access, Authentication, and Audit Logs plus metrics to Datadog, Splunk, Grafana, Elastic, and others in real time.

  • Integrate your SIEM providers such as Datadog, Splunk, Logz.io, Elastic, Grafana, and many others, and export logs and metrics in real time.
  • Horizontally scalable collectors with multiple pipelines to different providers.

The Cluster runs horizontally scalable OpenTelemetry collectors that export access logs, authentication logs, audit logs, component logs, metrics in real time, each signal to every exporter whose pipeline carries it.

  • Datadog: Logs · Metrics
  • Splunk: Logs
  • Elastic: Logs
  • Grafana: Metrics
  • ClickHouse: Logs
  • Apache Kafka: Logs · Metrics
  • Prometheus
  • InfluxDB
  • Azure Monitor
  • Azure Data Explorer
  • Logz.io
  • Any OTLP endpoint
Access

Just-in-Time access

Seamless JIT access to Octelium Cluster Services with self-service access requests, reviews, and time-bound approvals, all from a dedicated access web portal.

  • Catalogs of Services or Namespaces that can be requested directly by Users.
  • Policies whose rule decide whether a request is denied, approved automatically or sent for review.
  • Multi-step reviews with time-bound approvals.

Requesting, reviewing and granting Just-in-Time access

  • jane@acme.com requests the Catalog prod-databases (4 Services) for 2 hours from the access portal: Investigating elevated 5xx on payments-api, INC-2841.
  • Step 1, sre-leads, requires 2 approvals: amara@acme.com and marco@acme.com approve. Step 2, security, requires any approval: ling@acme.com approves.
  • Access is granted to pg-main.prod-databases, pg-replica.prod-databases, mysql-orders.prod-databases, redis-cache.prod-databases until 16:20 UTC, then removed automatically.
Identity

User and Group provisioning via SCIM 2.0

Synchronize Users and Groups from one or more directory providers, such as Microsoft Entra ID and Okta, simultaneously.

  • Users and Groups pushed to the Cluster over SCIM 2.0 by Microsoft Entra ID, Okta or any other SCIM 2.0 provider.
  • Google Workspace and Keycloak directories polled on an interval you set, alongside the OIDC and SAML 2.0 single sign-on every Cluster already has.
How Policies read identity

Users and Groups are pushed to the Cluster over SCIM 2.0 by Microsoft Entra ID, Okta, authentik or any other SCIM 2.0 provider, and Google Workspace and Keycloak directories are polled on an interval.

  • Created User amara.osei (sre · oncall) from Microsoft Entra ID.
  • Created Group sre-leads (12 members) from Okta.
  • Updated User marco.silva (+ platform) from Google Workspace.
  • Created User ling.wei (security) from authentik.
  • Updated Group platform (+3 members) from Keycloak.
  • Removed User contractor-42 (deprovisioned) from Okta.
  • Created User dan.kovac (data · analytics) from Any SCIM 2.0 IdP.
  • Created Group security (7 members) from Microsoft Entra ID.
Secrets

Encrypted Secret management

Automatic, scalable Secret encryption at rest with integrations for major cloud vault and KMS providers.

  • A dedicated Secret manager for Secret encryption at rest with integrations for AWS KMS, Google Cloud KMS, Azure Key Vault, and HashiCorp Vault.
How Secrets work

Every Secret is encrypted at rest with its own data-encryption key, and that key is wrapped by a key-encryption key held in a SecretStore: AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault, Kubernetes, or additional providers on demand.

  • Secret db-prod-password is sealed with dek_7c1e9a, wrapped by the KEK in AWS KMS.
  • Secret github-app-key is sealed with dek_2f8b41, wrapped by the KEK in Google Cloud KMS.
  • Secret datadog-api-key is sealed with dek_a93d07, wrapped by the KEK in Azure Key Vault.
  • Secret stripe-secret-key is sealed with dek_5be2c8, wrapped by the KEK in HashiCorp Vault.
  • Secret smtp-password is sealed with dek_e10f6b, wrapped by the KEK in Kubernetes.
Networking

Automatic public DNS and TLS certificates

Automatic public DNS management and automatic issuance and rotation of TLS certificates via Let's Encrypt.

  • Automatic public DNS management for Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS, DigitalOcean, Linode and OVH.
  • Automatic TLS Certificate issuance and rotation via Let's Encrypt DNS-01 ACME challenge.

When a Service is exposed publicly, the Cluster writes its DNS records on Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS, DigitalOcean, Linode, OVHcloud, and obtains and rotates its TLS certificate from Let's Encrypt through the ACME DNS-01 challenge.

  • api.acme.com: A record 203.0.113.10 on Cloudflare, certificate issued by Let's Encrypt.
  • grafana.acme.com: A record 203.0.113.24 on AWS Route 53, certificate issued by Let's Encrypt.
  • portal.acme.com: A record 203.0.113.31 on Google Cloud DNS, certificate issued by Let's Encrypt.
  • docs.acme.com: A record 203.0.113.47 on Azure DNS, certificate issued by Let's Encrypt.
  • status.acme.com: A record 203.0.113.52 on DigitalOcean, certificate issued by Let's Encrypt.
  • billing.acme.com: A record 203.0.113.68 on Linode, certificate issued by Let's Encrypt.
  • shop.acme.com: A record 203.0.113.75 on OVHcloud, certificate issued by Let's Encrypt.
What you get

Enterprise features and premium support

The sections above cover what most organizations evaluate on. This is the rest of it, for the reader who is checking a specific box.

Management

07

  • Centralized web-based control dashboard

    A unified web console for Cluster administrators to manage and monitor the Cluster's resources in real-time at scale.

  • Agentic AI assistant

    Control and manage your Cluster through natural-language requests in the console. Inspect activity, query logs, create resources and review access requests with AI.

  • Policy builder

    UI-based policy builder to easily create complex CEL rules from a catalogue of pre-defined conditions.

  • Policy tester

    Test your policies in a safe environment on a specific User, Session, Service and Namespace before deploying them.

  • MCP and LLM playgrounds

    Send a request to an MCP or LLM Service from inside the console and watch how the Policies that govern it treat that exact call.

  • Managed upgrades

    Seamlessly upgrade the Cluster packages from within the web console.

  • Multi-Region Clusters

    Scalable Octelium Clusters spanning multiple Kubernetes clusters across regions and clouds.

Visibility

04

  • Authentication and Audit Logs

    Dedicated structured Authentication logs for every authentication event and Audit logs recording every resource modification in the Cluster.

  • OpenTelemetry integration with SIEM providers

    Scalable OpenTelemetry collectors that export logs and metrics to major SIEM providers like Datadog, Splunk, Grafana, Elastic, and others in real time.

  • SSH session recording

    Recorded SSH sessions, replayable in the console beside the Access Log entry that authorized them.

  • Real-time visibility

    Centralized real-time logs and metrics for the entire Cluster.

Identity and devices

03

  • User and Group provisioning via SCIM 2.0

    Synchronize Users and Groups from one or more directory providers (Microsoft Entra ID, Okta, and others) simultaneously.

  • Directory synchronization

    Google Workspace and Keycloak directories polled on an interval you set, alongside the OIDC and SAML 2.0 single sign-on every Cluster already has.

  • Device posture integration with EDR providers

    Soon

    Device posture management integrated with CrowdStrike and additional EDR vendors on demand.

Just-in-Time access

04

  • Access Catalogs

    The set of Services and Namespaces that can be requested, so a request is a selection from a list rather than a description of what somebody wants.

  • Self-service access requests

    Requests made from the access portal with a reason, an urgency and a duration, evaluated by rules that deny, auto-approve or send them for review.

  • Multi-step reviews

    Reviewers named individually or by Group, per step, with any-of, all-of or a required count, a timeout, and a defined outcome when the timeout is reached.

  • Time-bound approvals

    An approved request carries both the Policies it grants and a maximum duration, so elevation is scoped as well as temporary and it ends without anyone remembering to revoke it.

Infrastructure

04

  • Encrypted Secret management

    Automatic, scalable Secret encryption at rest with integrations for AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault, and additional providers on demand.

  • Automatic public DNS for Services

    Automatic public DNS management for BeyondCorp-exposed Services via Cloudflare, AWS Route 53, and custom providers on demand.

  • Automatic TLS certificate management

    Automatic issuance and rotation of TLS certificates for all Services via Let's Encrypt and other public CAs on demand.

  • Component scaling

    Replica counts for the horizontally scalable components set as configuration, so capacity is part of the Cluster definition rather than a manual operation.

Support and licensing

02

  • Premium support

    Direct premium support with a dedicated private Slack channel. Help installing and running Octelium Clusters at scale on cloud-based or on-prem Kubernetes, meeting compliance regulations and standards. Influence the roadmap for upcoming features.

  • Commercial alternative license

    Octelium Cluster components are dual licensed under a copyleft license and a commercial license. We offer an alternative commercial license for businesses that need to use Octelium without the copyleft obligations.

All of it runs inside the same self-hosted Cluster, on your own Kubernetes, in your cloud or on-prem.

Let's talk

Ready to bring zero trust to your organization?

Tell us about your infrastructure and compliance requirements. We'll help you scope a deployment that fits.

Join SlackContact us
  • Free to use, forever, for personal and evaluation use.
  • Nothing about your existing Cluster, Policies or identity setup changes.