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
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.
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.
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.
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.
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.
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.
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.
| 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