KDCube - safer way to build AI for companies
Deploy AI agents with enforceable runtime controls: block unsafe actions, contain spend, and keep company data inside your infrastructure.
Business-first summary lives here. Deep technical behavior is documented in Docs and control details in Security.
- Unsafe tool actions are blocked before execution, not after incident review
- Hard spend and rate limits are enforced outside prompt logic
- Tenant boundaries are enforced across gateway, storage, and data access paths
For architecture and controls by layer, use docs.html and security.html.
Execution Safety
Agent-generated code executes in isolation. Privileged actions are mediated by runtime controls.
Cost Governance
Set hard limits for users, projects, and organizations to prevent runaway usage.
Data Boundaries
Tenant separation is enforced across request routing, storage, and accounting.
Self-Hosted Control
Run on your infrastructure with audit visibility and no mandatory vendor data path.
Why sandboxing alone is not enough
Compute isolation is necessary, but companies also need policy, spend, and tenant controls before actions are executed.
Infrastructure sandboxing
Good at isolating compute and limiting process-level access.
Not enough for business controls like approval policy, tenant scope, and cost containment.
What KDCube adds
- Action mediation: privileged operations pass through controlled runtime boundaries.
- Cost governance: spend and rate controls are enforced independently of prompt output.
- Tenant enforcement: request and data access paths are scoped by tenant and project.
- Auditability: decisions are traceable on infrastructure you control.
The enterprise risk is policy failure, not only process escape. KDCube focuses on preventing unsafe or out-of-scope actions before they execute.
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.
KDCube Semantic Layer
Enforces budget, rate, tenant, and execution-safety boundaries before execution. Declarative action-level policy DSL is roadmap.
KDCube intercepts agent execution at runtime and applies configured constraints (budget, rate, tenant, and isolation) before calls are admitted. Deterministic per-action allow/deny across arbitrary workflows is on the roadmap.
How KDCube works
Admit, enforce, execute, and audit. Implementation detail is in Docs.
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, and per-org spending caps with multi-tier accounting rollups
- Reservation/commit economics checks at admission with hard-limit enforcement
- 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
- Composable Skills and tool namespaces (local + MCP) via dynamic bundles
✅ 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 enforces current admission/economics/runtime boundaries today; explicit workflow-step invariant gating is a roadmap capability.
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.
*Estimate range depends on workload profile, model mix, traffic shape, and infrastructure/operations choices.
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.
Fast evaluation path
Use the all-in-one deployment to validate fit quickly, then move to managed infra patterns for production.
- Typical first environment in under an hour
- Clear migration path to production topology
- Full setup steps in Deployment Model
What you get
- Business-safe default posture for spend, tenant separation, and controlled execution
- Lower platform lock-in risk with self-hosted deployment choices
- Your data stays on your infrastructure by default
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 already provides economic controls, isolation, and Observability signals (monitoring endpoints, queue pressure, circuit-breaker state) used for scaling decisions. The following items are additional roadmap capabilities 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 |
| Citations / provenance layer | Maintains source pools and citations so outputs can reference supporting sources | Does not enforce admission controls, budgets, or tenant isolation by itself |
| Skills extension layer | Adds namespaced Skills and MCP-backed tools to bundle workflows | Does not replace Gateway / Admission checks or economics enforcement |
| 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 |
Build company AI with safer defaults.
Use KDCube to deploy AI with enforceable controls, then scale with docs-backed architecture patterns.
MIT Licensed · Self-Hosted · Open Source