What is a mogenius Agent Sandbox?

A mogenius Agent Sandbox is an ephemeral, isolated environment where AI agents execute and validate generated code, running on your own Kubernetes cluster instead of a developer laptop or a third-party cloud. Each sandbox is a scoped namespace with network policies, RBAC, and a full audit trail, provisioned on demand via MCP, API, CLI, or UI and torn down when the work is done.

Where do Agent Sandboxes run?

Sandboxes run on your own Kubernetes: any cluster, any cloud, on-premise, or air-gapped. Code and data never leave your infrastructure, which makes the approach GDPR-compliant and suitable for regulated environments. There is no external SaaS runtime and no US-hosted sandbox provider in the path.

How is Agent Sandbox governed?

Agent Sandboxes reuse the mogenius platform's governance: workspace isolation, RBAC, developer identity attribution, and a full audit log. Every sandbox action, create, exec, egress, is attributed to the developer or agent that triggered it and recorded for compliance and incident reconstruction. Egress is controlled by network policy so generated code cannot exfiltrate source or secrets.

Does Agent Sandbox work with AI coding agents and MCP?

Yes. The feature is native across MCP, API, CLI, and UI. A local agent can request a sandbox through the mogenius MCP server and run its generated code there, or the entire agent can run inside the sandbox with an external model connected via endpoint. It is built on the Kubernetes SIG agent-sandbox project, so there is no proprietary runtime lock-in.

Give AI agents a sandbox.
On your own Kubernetes.

AI coding agents generate code you didn't write and run it against systems you can't afford to lose. mogenius gives every agent an ephemeral, isolated sandbox to execute and validate that code, provisioned on demand, governed by RBAC and audit, and running on your cluster. Your source and secrets never leave your infrastructure.

Talk to Us See How It Works →

🤖

AI Agent

local, in CI, or in-sandbox

MCP · API · CLI

Sandbox · your cluster

⚙

Ephemeral workload

scoped namespace · runs the generated code

NetworkPolicy RBAC Audited Egress-controlled

Nothing leaves your infrastructure

Every action attributed

The challenge

Agents running code on a laptop
is a blast radius you can't audit.

Agent code on the developer machine

Generated code runs next to SSH keys, env files, cloud credentials, and the corporate VPN: the blast radius is the whole machine

No egress control: the code can read your source and send it anywhere

No attribution and no trail: nobody can reconstruct what an agent touched, or prove it to an auditor

The alternative, a third-party cloud sandbox, ships your code to US infrastructure and caps you with session limits

It's a separate silo, not a layer in the platform your team already runs

With mogenius Agent Sandbox

Code executes in an isolated, ephemeral workload: a scoped namespace with no access to developer machines or company secrets

Egress is governed by network policy; the sandbox only reaches what you allow

Every create, exec, and egress attempt is attributed to a developer or agent and logged

Runs on your own Kubernetes: any cloud, on-prem, air-gapped. No data leaves your infrastructure

A native capability of your mogenius platform: same operator, RBAC, workspaces, and audit

How it works

Provisioned on demand.
Torn down when it's done.

Kubernetes-native sandboxes, consumed at PaaS level.

An agent requests a sandbox through the mogenius interface it already speaks: MCP, API, CLI, or UI. The operator materializes the Kubernetes resources, the mogenius API hands back access, and the UI lets you watch and troubleshoot the running sandbox like any other workload. When the work is finished, the sandbox is suspended or destroyed.

Built on the Kubernetes SIG agent-sandbox project: no proprietary runtime, no lock-in
Isolation by default: dedicated namespace plus network policy
Optional kernel-level isolation (gVisor / Kata) for untrusted code
Suspend & resume, or destroy: ephemeral by design, no session limits
Reuses the governance you already have: RBAC, workspaces, audit

See the Platform →

AGENT Local, in CI, or running in-sandbox

↓ MCP · API · CLI · UI ↓

MOGENIUS RBAC → Workspace → Audit Log

↓ Operator reconciles ↓

SANDBOX Scoped namespace → isolated pod

The agent never touches your real workloads or the host machine. Every request is mediated, governed, and logged.

Two ways to run

Keep the agent outside,
or put it inside.

Mode A

Agent outside, code inside

Your agent runs where it runs today, a developer's IDE, a CI job, and requests a sandbox through the mogenius MCP server. The generated code executes and is validated inside the sandbox on your cluster, never on the machine that launched it.

The laptop stays clean: no generated code touches it
One MCP tool call to create, exec, and tear down
Ideal for IDE agents and PR-validation pipelines

Mode B

The whole agent in the sandbox

Run the entire agent inside the sandbox, for example an OpenCode-style CLI, with your model connected over an endpoint you choose, including a self-hosted one. The agent lives and dies with the sandbox and never has standing access to anything else.

Fully contained autonomous runs, start to finish
Bring your own model endpoint: external or self-hosted
Nothing persists beyond the sandbox's lifetime

Native in every interface

One capability.
MCP, API, CLI, UI.

Sandboxes are first-class, not a bolt-on.

Request a sandbox from an AI agent over MCP, script it through the API, drive it from the CLI, or monitor it in the UI. Every path resolves to the same custom resources, the same RBAC check, and the same audit entry, so an agent can't do anything a developer couldn't, and nothing goes unrecorded.

MCP: agents request sandboxes in the same governed server they already use for K8s operations
API: wire sandboxes into pipelines and internal tools
CLI: create, exec, and tear down from your terminal
UI: watch, inspect, and troubleshoot running sandboxes

AI Agent Governance →

# agent requests a sandbox via MCP, then runs its code

agent → create-sandbox --workspace team-checkout

Identity: dev/sarah.k via claude-code · RBAC ✓

Namespace: sbx-9f3a · NetworkPolicy applied · egress: deny-all

✓ sandbox sbx-9f3a ready

agent → exec-in-sandbox sbx-9f3a -- npm test

Logged: sandbox/exec · attributed: sarah.k

✓ tests passed · 18.2s

agent → suspend-sandbox sbx-9f3a

✓ suspended · destroyed on TTL

Your K8s

Any cloud, on-prem, or air-gapped: nothing leaves your infrastructure

No limit

No session caps: sandboxes live as long as the work needs

100%

Sandbox actions attributed and logged for audit

Open

Built on the Kubernetes SIG agent-sandbox project: no lock-in

Sovereignty & security

Untrusted code runs.
Your data stays home.

A sandbox exists to run code you haven't reviewed. mogenius treats that as a security boundary, not a convenience. Each sandbox is isolated at the namespace level with network policy, egress is denied by default, and sensitive runs can be pinned to a hardened runtime. The whole thing lives on infrastructure you control.

Because sandboxes reuse the mogenius control plane, the same RBAC and audit that govern your clusters govern them too. Every action is attributed to a real identity and reconstructible: the evidence an ISO 27001 or BSI audit asks for is simply the log.

🔒