KDCube — Semantic Sandbox for Enterprise AI Agents

KDCube is a self-hosted semantic sandbox that enforces budget caps, tenant boundaries, and tool-call isolation for AI agents — outside the agent's own reasoning, at the infrastructure layer.

  • Executor runs isolated with no network; all tool calls are proxied through a privileged supervisor — the agent code cannot reach external systems directly
  • Hard spending caps and rate limits enforced per user, project, and org — outside agent reasoning, not overridable by prompts
  • Tenant namespacing enforced across gateway keys, storage, database, and accounting — cross-tenant access blocked at the infrastructure layer
Star on GitHub MIT License Self-Hosted Open Source

Executor Can't Call Tools

The executor process runs fully isolated — no network access, sensitive env vars stripped to a minimal filtered set. All tool calls route through the privileged supervisor proxy, never directly from agent-generated code.

Hard Budget Caps Enforced

Per-user, per-project, and per-org spending caps and request rate limits are enforced at the infrastructure layer — outside agent reasoning and not overridable by prompt manipulation.

Tenant Boundaries Enforced

Tenant and project namespacing is applied across gateway API keys, object storage, database access, and accounting aggregation — cross-tenant data access is blocked before it reaches any backend.

Self-Hosted and Auditable

A monitoring API and control-plane dashboard give full visibility into usage and decisions. MIT licensed, self-hosted on your infrastructure — no vendor access to your agent traffic or policy configuration.

KDCube — When code execution sandboxing is not enough

Infrastructure sandboxes isolate where code runs. That is a necessary starting point — but for enterprise AI agents, it is not sufficient.

What infra sandboxing does

An infra sandbox (Docker, gVisor, subprocess isolation) controls the compute environment: filesystem access, network egress, process privileges. It prevents the executor from reaching production systems directly.

What it does not do: it has no knowledge of what the agent intended to do, how much it has spent, which tenant it belongs to, or whether its tool calls are within policy.

What KDCube's semantic sandbox adds

  • Tool-call isolation: Executor has no direct tool access. Tool calls route through a supervisor proxy that applies policy before dispatch.
  • Budget and rate governance: Per-user, per-project, per-org spending caps and rate limits enforced outside agent reasoning — hard limits that no prompt can override.
  • Tenant boundary enforcement: Every gateway request, database query, and storage operation is scoped and validated against the tenant namespace. Cross-tenant access is blocked at the infrastructure layer.
  • Auditability: A monitoring API and control-plane dashboard expose usage aggregation and decision history. Self-hosted — you own the audit trail.

The risk is not just a rogue process. It is an agent that overspends a budget, leaks data across tenant boundaries, or calls tools it was never supposed to reach — and nothing at the infra layer stopped it. KDCube is the semantic layer that does.

Sandboxing code is not enough.

AI agents don't just run code. They write emails. They process refunds. They query customer records. They call third-party APIs with real consequences.

Infrastructure sandboxes isolate the compute. Guardrails wrappers filter the output. Observability tools log what happened. None of them stop a wrong action before it executes.

The enterprise risk is not malicious code. It is an agent that does something it was never supposed to do — and nobody blocked it in time.

Infra Sandbox

What it does: Isolates execution environment

What it misses: Does not know what the agent intended to do

Guardrails Wrapper

What it does: Filters output after generation

What it misses: Does not intercept tool calls or API actions

Observability Tool

What it does: Logs what happened

What it misses: Logs are read after the fact — damage already done

The gap is semantic. KDCube closes it.

What is a semantic sandbox?

From infrastructure sandbox → semantic sandbox.

Traditional Sandbox

Isolates where code runs. Controls the compute environment. Does not understand what the agent is trying to do.

Semantic Sandbox

Controls what an agent is permitted to do — based on intent, context, and policy — before any action is taken.

KDCube intercepts agent tool calls, API requests, and execution paths at the runtime level. It checks them against configured constraints: budget limits, rate caps, allowed action sets, and tenant boundaries. If an action is out of bounds, KDCube blocks it. Not after the fact. Before it fires.

How KDCube works

Intercept. Evaluate. Enforce. Then execute — or block.

Subprocess-isolated code execution

  • Isolated subprocess within Docker Compose deployment
  • No external network access by default
  • Sensitive env vars stripped; minimal filtered environment; workdir filesystem only

✅ Available

Budget controls and rate limiting

  • Per-user, per-project, per-org spending caps
  • Hard limits that cannot be overridden
  • Request frequency and token throughput constraints

✅ Available

Multi-tenant isolation patterns

  • Tenant boundary validated on every request
  • Cross-tenant DB access blocked at the gateway layer
  • Knowledge base scoping per tenant (validate KB isolation boundaries during setup)

✅ Available

Streaming runtime with tool orchestration

  • REST, SSE (Server-Sent Events), Socket.IO
  • Token-by-token streaming responses
  • Knowledge base / memory context patterns

✅ Available

Decision logging (request/response)

  • Every allow/block decision timestamped
  • Self-hosted on your infrastructure
  • Control plane monitoring dashboard included

✅ Available

Policy DSL & deterministic enforcement Roadmap

  • Declarative constraint definitions per agent role
  • Verifiable allow/deny before any tool call fires
  • Workflow invariants and cross-agent approval gates

🔮 Roadmap

Where semantic sandboxing matters

Enterprise scenarios where "block before execution" is not optional.

Refund Authorization

An agent processes customer refund requests. KDCube enforces a maximum refund per transaction. Anything above requires a human approval step. The agent cannot bypass the limit — not through prompt manipulation.

$500 hard cap enforced

CRM Access Boundaries

An agent assists sales reps. A prompt injection attempt asks the agent to retrieve data from a different tenant. KDCube enforces tenant boundaries at the gateway layer — cross-tenant data access is blocked before it reaches the database. Validate KB isolation boundaries during setup.

Zero cross-tenant leaks

Approval Workflows

An agent manages vendor onboarding. It can draft contracts but must not send them without a human sign-off. KDCube gates the send-email tool call. The workflow cannot skip the approval step — even if the agent concludes the document is ready.

Enforced approval gates Roadmap

Data Boundary Enforcement

An agent processes medical records. KDCube restricts outbound API calls to an approved allowlist. Calls to unapproved endpoints are blocked. The execution environment has no external network access by default.

Allowlist-only outbound calls

Cost Containment

An agent runs complex analytical tasks. Left unconstrained, a single poorly-scoped prompt can trigger thousands of dollars in LLM token consumption. KDCube enforces per-user, per-project, and per-org spending caps. Hard limits cannot be exceeded.

60–80% estimated infra savings*

Secure Code Execution

An agent generates and runs Python scripts. KDCube runs the code in an isolated subprocess with no external network access and no environment variable access. No code run in the sandbox can reach production systems directly — all outbound tool calls route through the trusted supervisor.

Zero network egress by default

Why KDCube

Not a framework. Not a guardrails wrapper. Not observability.

Block before execution — not after

Most tools observe or filter. KDCube intercepts. The enforcement decision happens before any external system is called. Wrong actions do not execute.

Semantic constraints, not just compute limits

Rate limits and memory caps are infrastructure. KDCube enforces what the agent is allowed to do — action scope, data access, spend authority — not just how much CPU it uses.

Self-hosted. Your infrastructure, your policy.

KDCube runs on your infrastructure. No vendor has access to your agent interactions, your policies, or your data. MIT licensed. No lock-in.

Open-source and auditable

The enforcement layer is not a black box. Every constraint, every decision, every blocked action is logged and inspectable. You own the audit trail.

Open-source. Self-hosted. Zero vendor lock-in.

Deploy in under 30 minutes

git clone https://github.com/elenaviter/kdcube-ai-app
cd kdcube-ai-app/app/ai-app/deployment/docker/all_in_one

# Setup directories
mkdir -p data/{kdcube-storage,exec-workspace,postgres,redis,clamav,neo4j/{data,logs,plugins,import}}
chmod -R 0777 data
mkdir -p logs/{chat,kb,dramatiq} nginx/webroot

# Build code execution image
docker build -t py-code-exec:latest -f Dockerfile_Exec ../../..

# Initialize database
docker compose build postgres-setup
docker compose run --rm postgres-setup

# Add API key to .env.backend:
# ANTHROPIC_API_KEY=sk-ant-api03-your-key

# Start services
docker compose build && docker compose up -d

# Runtime ready at localhost:8000

Quick setup: pipx install kdcube-apps-cli && kdcube-apps-cli

What you get

  • Deploy in under 30 minutes — Docker Compose, single command
  • 60–80% lower infrastructure cost vs. managed SaaS agent platforms (estimated, based on typical SaaS pricing vs. self-hosted infrastructure costs)
  • Your data stays on your infrastructure — no calls home, no telemetry you did not configure

KDCube is MIT licensed. The full source is on GitHub. Deploy on your own infrastructure — a single VPS, Docker Compose, or a Kubernetes cluster — and you control everything.

No usage-based fees. No per-seat pricing. No vendor access to your agent traffic. Infrastructure costs vary by cloud provider and configuration; example ranges of $50–$2,000/month are based on typical VPS/cloud pricing. The runtime itself is free.

Where we are headed

The current runtime enforces economic and isolation constraints today. The following capabilities are on the roadmap and are not yet shipped.

Policy DSL Roadmap

Declare agent permissions in a human-readable policy language. Define what actions, data scopes, and spend limits are permitted per agent role.

Deterministic Enforcement Engine Roadmap

Pre-execution evaluation that produces a verifiable allow/deny decision before any tool call fires, with no probabilistic components.

Workflow Invariants Roadmap

Declare required steps in a workflow. Prevent agents from skipping approval gates, notification steps, or compliance checkpoints.

Cross-Agent Approval Gates Roadmap

Require a second agent, human-in-the-loop confirmation, or external approval before high-impact actions execute.

Follow progress: github.com/elenaviter/kdcube-ai-app

KDCube vs. the alternatives

KDCube integrates with common agent frameworks and tool APIs. It is complementary to, not a replacement for, your orchestration layer.

Comparison of AI agent tooling categories: what each tool does and what it does not do
Category What it does What it does NOT do
Infrastructure sandbox
(Docker, gVisor)
Isolates compute environment Does not know what the agent intends to do; no semantic constraints
Guardrails wrapper
(NeMo Guardrails, etc.)
Filters LLM output text Does not intercept tool calls or API actions; fires after generation
Observability tool
(LangSmith, Helicone)
Logs and traces agent behavior Read-only; logs damage after it occurs; does not block
Agent framework
(LangGraph, LangChain, CrewAI)
Orchestrates agent logic and tool calling Provides no enforcement layer; delegates execution control to the agent
KDCube — Semantic Sandbox Intercepts tool calls and API actions; enforces budget caps, rate limits, and tenant boundaries before execution (full semantic workflow constraints are on the roadmap) Not an LLM proxy, not a framework, not a log aggregator

Start enforcing what your agents are allowed to do.

Open-source. Self-hosted. Under 30 minutes to first controlled agent.

MIT Licensed · Self-Hosted · Open Source