AI Agents

Unlike generic container runtimes or traditional "AI sandbox" products that primarily focus on filesystem and process isolation, Cordium treats AI agents as first-class infrastructure principals with identities, policies, sessions, scoped infrastructure access, and observable runtime behavior. A Cordium Workspace is not merely an isolated execution environment, but it also has a dedicated Octelium Session identity, policy-controlled access to infrastructure resources, and full observability through OpenTelemetry-native auditing. This architecture allows AI agents to access infrastructure such as remote private resources behind NAT, AI models, publicly protected SaaS resources such as SaaS APIs and databases without requiring direct distribution of long-lived and/or over-privileged credentials into the runtime environment.

note

You can read various example guides for AI agents such as Codex and Claude Code.

The Problem with Existing Approaches

Most current AI-agent execution approaches rely on running the agent directly on developer laptops or CI runners, inside generic containers or ephemeral VMs, with infrastructure credentials injected directly into the environment, with broad API tokens or cloud credentials granted to the runtime, or with infrastructure-level isolation but no application-layer identity and authorization.

These approaches share a common failure mode: the runtime environment accumulates credentials in environment variables, shell history, mounted files, git credential stores, cloud SDK configurations, kubeconfigs, SSH keys, CI secrets, or application configuration files. AI agents can unintentionally leak such credentials through logs, generated code, prompts, telemetry, external API calls, or unintended tool invocations.

Traditional container isolation does not solve the core access-control problem. A container with a mounted production credential effectively becomes a highly privileged execution environment regardless of how isolated the filesystem or kernel namespace may be. Most existing "AI sandbox" systems also lack a unified identity and policy model for infrastructure access, placing the authorization boundary at the credential itself rather than at the workload identity.

Here is an example for an Octelium Service (read more about Octelium Services here) of a SaaS HTTP API that uses bearer authentication:

kind: Service
metadata:
  name: my-gemini
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: https://generativelanguage.googleapis.com
      auth:
        bearer:
          fromSecret: gemini-api-key

You can read more detailed secretless access example guides for Octelium as an API gateway, AI gateway, MCP gateway, SaaS API gateway, S3 gateway and AWS Lambda gateway.

note

Read in detail about secretless access here.

Identity-Based Agent Execution

Every Cordium Workspace receives its own Octelium Session identity. That identity becomes the security principal used for infrastructure access. Instead of distributing credentials into the Workspace, infrastructure access is mediated through Octelium's identity-aware proxies and secretless access architecture totally out of reach of the Workspace. Inside the Workspace, agents use standard tools and protocols (e.g. curl, psql, ssh, etc.) without having to possess the upstream credentials used to authenticate against those resources. The Octelium identity-aware proxy, Vigil, injects the appropriate application-layer credentials dynamically at the identity-aware proxy based on the agent identity and context. The AI agent is allowed to perform an action because the Workspace identity is authorized to perform it, not because the runtime environment contains static credentials with broad privileges.

This means infrastructure access becomes policy-driven rather than credential-driven. Access scopes can be changed without rotating secrets or rebuilding environments. Different Workspaces running the same Template can receive different access levels based on identity and context. Compromised or misbehaving agents cannot extract credentials that were never present inside the runtime. This model extends naturally to HTTP APIs, SSH, Kubernetes APIs, PostgreSQL, MySQL, mTLS-protected services, internal AI gateways, and any other application-layer protocol supported by Octelium's secretless access.

Every Workspace is owned by an Octelium User (read more here) and Session (read more here). Here is an example for an Octelium User that can be used by an AI agent:

kind: User
metadata:
  name: agent-1
spec:
  type: WORKLOAD
  groups: ["agents", "dev", "ops"]
  authorization:
    inlinePolicies:
      - spec:
          rules:
          - effect: ALLOW
            condition:
              all:
                of:
                - match: ctx.namespace.metadata.name in ["staging", "production"]
                - match: ctx.service.spec.mode == "HTTP"
                - match: ctx.request.http.method in ["GET", "POST", "PUT", "DELETE"]
                - match: ctx.request.http.path.startsWith("/apis")
                - match: ctx.request.http.uri == "/apis/users?name=john"
                - match: ctx.request.http.queryParams.name == "john"
                - match: ctx.request.http.headers["x-custom-header"] == "this-value"
                - match: ctx.request.http.scheme == "http"
                - match: string(ctx.request.http.body).toLower().contains("value1")
                - match: ctx.request.http.bodyMap.key1 == "value1"

note

Policy rules can be defined per User, Group, Session, Device, Service and Namespace. Read in detail about Octelium's access control and Policies here.

AI agents identities should be managed WORKLOAD Octelium Users that can authenticate to the underlying Octelium Cluster via the following methods:

Authentication tokens.
OAuth2 client credentials.
Access tokens.
OIDC-based assertions which can be used for secretless authentication from within GitHub actions, cloud providers, Kubernetes clusters, etc.

AI agents can authenticate and interact with the Cordium Cluster via CLIs (read more here) or via the gRPC-based API SDK (read more here).

Isolation Model

Agents frequently need to install packages, compile code, run language runtimes, execute test suites, build containers, spawn subprocesses, interact with databases, use package managers, run browsers, or execute arbitrary developer tooling. For this reason, Workspaces intentionally provide what appears to be full root capability from inside the sandbox environment. Internally, however, the Workspace runs as a rootless container inside an outer, restricted supervisor container.

Ephemeral and Reproducible Execution

Cordium is designed around reproducible Workspace creation. Templates define the image, repositories, startup tasks, limits, runtime configuration, variables, and initialization logic declaratively. Pre-built Templates can be snapshotted and restored within seconds using Kubernetes CSI snapshots. This allows AI-agent workloads to start from deterministic environments with pre-installed dependencies, cached package trees, cloned repositories, language toolchains, and runtime frameworks already prepared ahead of time.

An ephemeral Workspace run starts from a clean state and is fully destroyed afterward. This prevents state bleed between runs, limits persistence opportunities for compromised agents, and makes execution behavior easier to reason about operationally. Persistent Workspaces remain available for human-assisted development sessions, long-running automation, collaborative debugging, or agents that intentionally maintain local state over time.

Observability and Auditability

All infrastructure access performed by Workspaces is audited through Octelium's OpenTelemetry-native application-layer L7-aware visibility. This includes HTTP and gRPC API requests (e.g. request path, method, query argume), database queries, full SSH sessions, Kubernetes API operations, etc.

note

Read in detail about Octelium visibility here.

Because every Workspace has a dedicated Session identity, infrastructure activity can be correlated directly back to the Workspace, the Template, the originating User, the Space, and the specific Session performing the operation. This becomes particularly important for AI-agent workloads where reproducibility, traceability, and post-incident analysis are operationally critical.