Cordium: AI hits the DB with no password in the process

Cordium in 30 Seconds

Cordium is a free, Apache-2.0, self-hosted sandbox platform from Octelium Labs, LLC where AI workloads reach databases, SSH servers, internal HTTP APIs, and Kubernetes clusters without any credential entering the running process — published at github.com/octelium/cordium . The sandboxes, called Workspaces, get functional access to infrastructure while the raw secret physically stays elsewhere.

Quick Answer: Cordium is an open-source (Apache-2.0), self-hosted sandbox by Octelium Labs that lets AI agents reach databases and SSH hosts without credentials ever entering the sandbox. Secrets stay at the Octelium ZTNA proxy and are injected at the protocol layer only after per-request authorization. Latest release: v0.12.7, June 6, 2026.

The mechanism is what separates it from a plain code-execution sandbox. Instead of injecting API keys, passwords, SSH private keys, or kubeconfigs into the agent's environment, Cordium holds those secrets at Octelium's identity-aware proxy and injects them at the protocol layer only after the Workspace's identity clears per-request, attribute-based authorization . The running code never receives a raw credential.

This is an early-stage project. The latest release at research time is v0.12.7, dated June 6, 2026, on a repository sitting at roughly 42 GitHub stars — recently open-sourced and still building adoption . The codebase is roughly 55% TypeScript and 45% Go .

The security bet underneath all of it is simple to state: a misbehaving or compromised AI cannot exfiltrate credentials it physically never possesses. Whether prompt injection tricks the model or the model simply goes off-script, there is no key sitting in an environment variable, key file, or .env to leak — the credential lives at the proxy, gated and audited per request . The sections below test how that holds up.

How Passwords Never Enter the Running Code

The credential never enters the running code because Cordium splits the secret from the session: the Workspace carries only an identity assertion, while the raw password stays at the Octelium proxy and is injected at the protocol layer after the access gate clears . The agent's process never reads, stores, or logs the secret — it opens a connection and receives a live socket, not a key.

Contrast that with the conventional pattern. To let code talk to Postgres, you mount the password as an environment variable, a .env file, or a volume-mounted key file. The process reads it on startup and holds it in memory for the entire session. That secret now lives in the process environment, the heap, and — through a careless connection string or stack trace — frequently the application logs too. Any code path that can read its own environment can exfiltrate it, which is exactly the failure mode an autonomous or compromised agent exposes.

Cordium's flow inverts the trust boundary:

• The Workspace holds an identity, not a credential. Authentication uses workload identity federation via OIDC assertions, OAuth2 client-credentials, or bearer auth, so the agent or CI/CD job authenticates without any static secret in its environment .
• The proxy holds the secret. Database passwords, SSH private keys, and kubeconfigs sit at the Octelium identity-aware proxy, never in the sandbox .
• Injection happens at the TCP/TLS/protocol layer. Once the per-request ABAC check passes, the proxy attaches the real credential when it brokers the upstream connection — to a database, SSH server, internal HTTP API, Kubernetes cluster, or mTLS-protected service .
• The code sees a working connection. The AI issues a normal connection call and gets a usable socket back. From inside the sandbox, the database "just works," yet there is no password to print, copy, or leak.

This is why protocol-layer injection matters more than it first sounds. The common exfiltration channels for an LLM agent — model output, manipulated prompts that coax it into dumping config, or after-the-fact log scraping — all assume there is an in-process secret to capture. With Cordium there isn't. The model can be fully compromised and still have nothing to hand over, because the thing an attacker wants was never resident in the environment, heap, or logs it controls .

The obvious caveat: this guarantee is only as strong as the boundary itself. If the sandbox can reach upstream services directly — through a network-policy gap that bypasses the proxy — protocol-layer injection no longer protects anything. The mechanism removes the in-process secret; it does not remove the need to verify the network path, which the gating model in the next section is designed to enforce.

Attribute-Based Gating with CEL and OPA

That network path is exactly what Cordium's authorization layer governs. Infrastructure access is decided by per-request, L7-aware attribute-based access control (ABAC), written as policy-as-code in CEL (Common Expression Language) and evaluated through OPA (Open Policy Agent) rather than baked into hard-coded allow-lists or env-var grants . Because the proxy understands the application layer, a policy can gate not just "can this Workspace reach the database" but the specific request being made, at the moment it is made.

The default posture is zero standing privileges: there are no persistent grants sitting around to be abused . Each connection attempt is evaluated against the current policy at the instant it occurs, so revoking access is a policy edit, not a credential-rotation scramble. For an agent that may be running untrusted or model-generated code, this matters: even a Workspace that was authorized a minute ago gets re-checked on the next request, and a policy change takes effect without redeploying the sandbox or touching any secret.

Identity is the input that policy reads, and Cordium accepts a broad set. For humans, it supports any OIDC or SAML 2.0 identity provider, GitHub OAuth2, plus native FIDO2/WebAuthn, TOTP, and TPM 2.0 . For non-human callers — the agents and CI/CD jobs that actually drive most of this traffic — it supports workload identity federation via OIDC assertions, OAuth2 client-credentials, and bearer authentication . The practical point is that a build pipeline or an autonomous agent can authenticate as a first-class identity without a static shared password living in a config file. ABAC only works if the "who" is trustworthy, and static secrets are precisely the part that prompt injection or a leaked .env tends to compromise.

Every authorization decision is also observable. Each request produces an OpenTelemetry-native, identity-labeled, L7-aware structured log record that the Octelium cluster emits and can export to any OTLP receiver, making SIEM and log-management integration available without bolting on a separate audit layer . That gives a reviewer a per-request trail of which identity touched which service under which policy — useful both for incident response and for confirming that the network boundary from the previous section is actually being enforced.

One caveat stays in view: this entire model presumes the Octelium proxy is the only path to upstream services and that its policies are written correctly. The release surveyed here is early — v0.12.7, dated June 6, 2026 — and there is no independent evaluation of how the CEL/OPA enforcement holds up under adversarial agent behavior. ABAC reduces standing risk; it does not remove the operator's job of getting the policies right.

Kubernetes Footprint and Workspace Persistence

Cordium runs entirely on standard Kubernetes — there is no proprietary control plane to adopt. The same declarative model scales from a single-node VM for local development up to multi-node production clusters, and it runs in the cloud or fully on-prem . That choice matters operationally: teams already running Kubernetes inherit Cordium's substrate rather than a separate orchestration layer, and the Octelium proxy that holds the credentials lives alongside the Workspaces it gates.

Isolation comes from rootless nested containers. The host is protected by the outer rootless boundary, while the Workspace itself still grants full root inside the sandbox . The practical consequence for developers is that there is no capability stripping that breaks ordinary build, install, or test tooling — package managers, container builds, and privileged test harnesses behave as they would on a normal box, which is often where lighter sandboxes force workarounds.

Workspaces are defined as declarative YAML and can be built from several sources, so an environment is portable and reproducible across machines:

• OCI images — pull a prebuilt image as the Workspace base.
• Dockerfiles — build the environment from a spec at creation time.
• Git repositories — bootstrap directly from a repo.
• Devcontainer specs — reuse the same definition that drives a local editor container .

Lifecycle is explicit rather than implicit. A Workspace can be persistent — a long-running development or AI environment that survives across sessions — or ephemeral, spun up per task and cleaned up on exit. Persistent state is backed by pluggable CSI Kubernetes-native volumes, so storage uses the cluster's existing drivers instead of a bespoke layer . For autonomous-agent workloads, the ephemeral mode is the one to reach for: each task gets a fresh, disposable environment, which limits the blast radius if an agent corrupts state or installs something it should not.

Access to a running Workspace is offered through four ingress surfaces — a browser terminal, SSH, a CLI, and a gRPC API . The browser terminal suits quick human inspection; SSH and the CLI fit existing developer workflows; and the gRPC API is the programmatic entry point that agents and CI/CD pipelines call. Every one of those paths is still subject to the same identity-aware authorization, so the choice of ingress does not weaken the credential-isolation model described earlier.

Cordium vs. E2B, Daytona, and AISI Inspect

Cordium's closest neighbors solve a different problem than it does: most sandbox tools isolate execution, while Cordium isolates the credential. E2B and Daytona are cloud-managed, fast-startup sandboxes well-suited to ephemeral AI tool calls, but both follow the conventional pattern of mounting secrets — environment variables, key files, kubeconfigs — into the running process, which is the exact exposure Cordium is designed to remove by holding the secret at its identity-aware proxy . Knowing where each tool draws its boundary is what tells you whether they compete with Cordium or stack alongside it.

The UK AI Security Institute's Inspect framework is a clear example of adjacency rather than overlap. Inspect is an evaluation-focused framework that provides sandboxing for agent tool execution across Docker, Kubernetes, Daytona, Modal, EC2, and Proxmox providers, with built-in Docker support requiring Docker Engine 24.0.7+ . Its controls are tuned for safe, reproducible evals: a network_mode: none option for full network cut-off, plus default limits of 100 MB on read-file size and 10 MB on execution-output size . That is sandboxing to contain a graded agent run, not to grant it authorized, audited access to a production database while hiding the password — a different goal entirely.

Protect AI's LLM Guard sits at yet another layer. It is an MIT-licensed toolkit for LLM interaction security offering input/output sanitization, data-leakage prevention, and prompt-injection resistance, and it ships a dedicated "Secrets" scanner . But that scanner operates at the model I/O boundary — inspecting prompts and completions for leaked credentials — whereas Cordium's isolation happens at the network protocol layer, before a secret would ever reach the model at all. The two are complementary: output sanitization catches what slips through; protocol-layer credential isolation prevents the secret from being reachable in the first place.

Read across that table and the positioning is consistent: E2B and Daytona optimize for startup speed and convenience but inherit the mounted-secret pattern; Inspect optimizes for evaluation containment with hard resource caps and optional network isolation; LLM Guard optimizes for text-boundary inspection . Cordium's distinct bet is moving the credential off the agent's machine entirely and gating each request through identity . The trade is maturity for model: at v0.12.7 with roughly 42 stars, it is far younger than the incumbents it contrasts with .

OWASP LLM01 and Adjacent Defenses

Cordium's credential isolation answers one slice of a threat that OWASP formalized in LLM01:2025 Prompt Injection. OWASP defines prompt injection as user or external input that changes an LLM's behavior in unintended ways, and lists its primary harms as sensitive-information disclosure, leakage of AI infrastructure and system prompts, unauthorized function invocation, and arbitrary command execution in connected systems . The OWASP Top 10 for LLM Applications 2025 that carries this entry was published November 17, 2024 . Crucially, OWASP notes that RAG and fine-tuning do not fully mitigate injection, and recommends engineering controls instead: least-privilege access, segregation of external content, input/output filtering, and human approval for high-risk actions.

"Prompt injection vulnerabilities are possible due to the nature of generative AI... mitigation requires constraining model behavior, restricting access by least privilege, and requiring human approval for privileged operations," — OWASP GenAI Security Project (source: LLM01:2025).

Cordium maps onto the least-privilege and credential-isolation parts of that list, but it does nothing for the semantic layer — what an authorized agent decides to do with access it legitimately holds. Two recent research systems target precisely that gap, and both are orthogonal to Cordium's infrastructure approach:

• Cordon ("Semantic Transactions for Tool-Using LLM Agents," submitted June 16, 2026) wraps tool intents in task-level transaction boundaries with lineage tracking, reversible local state, and staged external commits. It reports intercepting policy-violating effects in 45 of 45 risk-bearing workflows, versus 14 of 45 for adapters built on existing defenses, at a 4.17 ms median rollback latency .
• ClawGuard (submitted April 13, 2026) enforces user-confirmed rules at every tool-call boundary, reporting a 100% defense success rate across AgentDojo, InjecAgent, and ChatInject over five models .

These are rule- and transaction-layer controls, not isolation sandboxes — and like all single-vendor benchmark figures, the numbers are author-reported pending independent replication. LLM Guard, an MIT-licensed toolkit from Protect AI, sits at yet another layer, scanning prompt and response text for sanitization, data-leakage prevention, and a dedicated secrets scanner.

The practical takeaway is that no single tool spans the attack surface OWASP describes. Cordium guards the credential layer, ClawGuard and Cordon guard the tool-call and semantic layers, and LLM Guard guards the text I/O boundary. They compose into defense-in-depth rather than compete — a builder pairing Cordium's secretless access with a tool-call gate and output filtering covers far more of LLM01 than any one of them alone.

Cordium at v0.12.x: Maturity and Operational Complexity

Cordium is an early-stage project, and its security claims are vendor-stated rather than independently verified. The latest release is v0.12.7, dated June 6, 2026, and the GitHub repository sits at roughly 42 stars — a recently open-sourced tool still building adoption. No third-party red-team escape tests, neutral isolation-strength benchmarks, or sandbox-escape assessments were published at the time of writing. Treat the secretless guarantee as a design intent that has not yet been measured by anyone outside Octelium Labs.

The gaps matter for anyone weighing production use. There is no neutral measurement of the overhead added by protocol-layer credential injection, no published sandbox-escape evaluation, and no comparison against a deliberately misconfigured baseline to show how the model degrades under operator error. The credential-free property depends entirely on the Octelium proxy being correctly configured and on the Workspace never reaching upstream services directly . A single network-policy gap or proxy misconfiguration could let the sandbox bypass the gateway and defeat isolation — and the sources reviewed include no hardening guide for that failure mode.

Cost is a mixed picture. The core is Apache-2.0 and self-hosted, so there is no licensing fee . The real expense is operational: running and securing a Kubernetes-based Octelium cluster, keeping CEL/OPA policy current, and monitoring the audit pipeline are non-trivial engineering tasks, and that cost is unquantified in any public source.

Citations: AISI Inspect , LLM Guard .

The takeaway: Cordium's identity-based, secretless model is a genuinely useful primitive that fills a real gap in the agent stack, but at v0.12.x it is a bet, not a guarantee. Pilot it on non-critical infrastructure, validate the network policy that enforces the proxy boundary yourself, and pair it with tool-call gating and output filtering. Revisit for production once independent escape testing and overhead numbers exist.

Frequently asked questions

What is Cordium and who built it?

Cordium is a free, open-source (Apache-2.0) self-hosted sandbox platform built by Octelium Labs, LLC and published at github.com/octelium/cordium. Its sandboxes — called Workspaces — run AI agent or developer code against live databases, SSH hosts, and APIs without any credential entering the running process. It layers on Octelium's zero-trust network access (ZTNA) engine, and the latest release is v0.12.7, dated June 6, 2026 .

How does Cordium keep credentials out of the AI process?

Cordium keeps the raw secret at the Octelium identity-aware proxy and injects it at the protocol layer only after a per-request authorization check passes. The Workspace itself holds only an identity assertion — never a password, API key, SSH private key, or kubeconfig. Authorization runs on attribute-based access control (ABAC) written as policy-as-code in CEL (Common Expression Language) and OPA (Open Policy Agent), enforcing zero standing privileges by default . The intended effect: a compromised or prompt-injected agent never sees the credential it uses.

What infrastructure can Cordium Workspaces reach?

Workspaces can reach databases, SSH servers, internal HTTP APIs, Kubernetes clusters, and mTLS-protected services — anything the Octelium data plane can proxy . Each connection is gated per request by L7-aware ABAC policy rather than a static, up-front grant, and every request is audited with OpenTelemetry-native, identity-based structured visibility exportable to OTLP receivers for SIEM and log management. Access reaches the Workspace itself through a browser terminal, SSH, a CLI, and a gRPC API.

How does Cordium differ from E2B or Daytona?

E2B and Daytona follow the conventional pattern: credentials are injected into the sandbox environment as env vars, key files, or `.env` mounts, so the agent process can read them. Cordium replaces that pattern by holding credentials at the proxy and injecting them at the protocol layer, so they never reach the process environment . Functionally the agent still queries the database or opens the SSH session; the difference is that the secret physically stays at the gateway, with per-request authorization and full audit.

Is Cordium production-ready?

Not yet, by a cautious read. As of June 2026 Cordium is at v0.12.7 with roughly 42 GitHub stars and no independent security evaluations in the sources reviewed . The architecture maps cleanly onto OWASP's LLM01:2025 least-privilege guidance — the Top 10 for LLM Applications 2025 was published November 17, 2024 — and the secretless mechanism is principled, but maturity is early-stage. Pilot it on non-critical infrastructure and treat the secretless guarantee as vendor-stated until external audits and escape testing appear.