Enforce what agents are allowed to do.
Before they do it.

KDCube enforces constraints at the runtime layer —
budget caps, rate limits, tenant boundaries, and subprocess isolation —
not in post-hoc logs, not in output filters, not in prompt engineering.

See How It Works View on GitHub

What KDCube is designed to address

Enterprise AI agents face five categories of operational risk. KDCube's semantic sandbox is designed to constrain each.

Threat 1

Prompt Injection

A malicious or malformed input causes the agent to take an action the operator did not intend. The agent "believes" it has authorization to perform a privileged action.

KDCube response Constraints are enforced at the runtime level, not derived from the agent's own reasoning. An agent cannot reason its way past a hard budget cap or a tenant boundary. The runtime checks budget, rate, and tenant validity on every request — independent of the agent's intent. Per-action allow/deny policy rules require the deterministic enforcement engine (roadmap).
✅ Runtime enforcement available + Deterministic enforcement engine Roadmap
Threat 2

Tool Misuse

An agent calls a tool with parameters it should not use — issuing a refund above the authorized limit, querying a table outside its scope, or sending a document before approval.

KDCube response Budget caps block excessive spend before the LLM call is charged. Tenant boundary validation blocks cross-scope queries at the gateway layer. Tool dispatch is proxied through the privileged supervisor (UID-verified via Unix socket), so the isolated executor cannot call tools directly. Workflow invariants to block premature action steps are on the roadmap.
✅ Budget + tenant enforcement available + Workflow invariants Roadmap
Threat 3

Cross-Tenant Data Leakage

In a multi-tenant deployment, an agent serving Tenant A accidentally — or through manipulation — accesses data belonging to Tenant B.

KDCube response Every request carries tenant identity. Database access and storage paths are scoped to the validated tenant. Gateway middleware enforces tenant identity on every request. Note: KB API tenant scoping is in progress — validate knowledge base isolation boundaries before production multi-tenant deployment.
Note: Gateway-level tenant isolation is available. Full KB API tenant awareness is in progress — verify isolation boundaries during setup.
✅ Available (validate KB isolation during setup)
Threat 4

Runaway Spend

An agent enters a loop, receives an unusually expensive prompt, or is exploited to consume large volumes of LLM tokens, driving up costs without bound.

KDCube response Hard budget limits at the user and project level cannot be exceeded — implemented via ledger-backed reservation and commit in project_budget.py and user_budget.py. When a limit is hit, execution stops and a rate-limit event is emitted. Request-frequency rate limiting (burst + hourly windows) is enforced per user type in Redis. No agent reasoning or configuration overrides these caps.
✅ Available
Threat 5

Workflow Skipping

An agent completes a multi-step workflow but skips a required approval, notification, or compliance checkpoint — either through flawed reasoning or deliberate manipulation.

KDCube response Roadmap Workflow invariants will declare required steps. The runtime will verify that mandatory steps were completed before permitting subsequent actions. An agent cannot finalize a contract send without the approval gate having been cleared.
🔮 Roadmap
Threat 6

Unauthorized Data Exfiltration

Code running inside a sandbox attempts to call external APIs, send data to unapproved endpoints, or exfiltrate sensitive information through network channels.

KDCube response The isolated executor subprocess has no direct external network access by default. All tool dispatch is proxied through the trusted supervisor process. Outbound endpoint allowlisting is configurable at deployment policy level — configure per your data protection requirements.
✅ Available (endpoint allowlist configurable by deployment policy)

Controls: today and on the roadmap

A complete list of enforcement controls — which are available now and which are on the roadmap.

KDCube security controls: current availability and enforcement scope
Control Status What it enforces
Budget caps (per user, project, org) ✅ Available Hard spending limits that stop execution when reached
Rate limiting ✅ Available Request frequency and token throughput constraints
Tenant boundary validation ✅ Available Blocks cross-tenant data access on every request
Subprocess-isolated code execution ✅ Available No external network access by default; sensitive env vars stripped via blocklist (PATH, HOME, SSH_*, credential vars, IDE vars); workdir filesystem only
Supervisor pattern for tool dispatch ✅ Available All tool dispatch proxied through UID-verified Unix-socket supervisor (UID 1001 enforced via SO_PEERCRED); outbound endpoint allowlist configurable at deployment level
Decision logging (self-hosted) ✅ Available Budget, rate-limit, and throttling decisions logged with context; monitoring API surfaces circuit breaker state, queue stats, and throttling events; all stored on your infrastructure
Deployment-level resource limits ✅ Available Resource limits on sandboxed execution; configurable at deployment level
Policy DSL for declarative rules Roadmap 🔮 Roadmap Human-readable action scope definitions per agent role
Deterministic pre-execution enforcement Roadmap 🔮 Roadmap Verifiable allow/deny before any tool call fires
Workflow invariants Roadmap 🔮 Roadmap Required step enforcement; skip prevention
Cross-agent approval gates Roadmap 🔮 Roadmap Human-in-the-loop or secondary agent confirmation

Block before execution — not after

KDCube's runtime enforcement is pre-execution.

Budget, rate, and tenant checks happen before the LLM call is charged and before any external system receives a request. Subprocess isolation prevents the executor from reaching external networks directly. There is no rollback, no compensation transaction, no post-hoc correction for these controls.

The sequence on every agent request:

  1. Agent generates a tool call or API request.
  2. The gateway middleware checks rate limits, tenant identity, and budget balance.
  3. If any check fails, the request is rejected and a throttling/budget event is recorded.
  4. Only requests that pass all checks proceed to the agent runtime.
  5. Code execution runs in an isolated subprocess (no external network, filtered env vars); tool calls are proxied through the UID-verified supervisor.
  6. Budget charges and rate events are recorded in the ledger and throttling log.

This model differs fundamentally from output filtering (which operates after the LLM responds) and from observability (which records what happened). Budget, rate, and isolation controls prevent wrong actions from executing — not just detect them after the fact.

Scope note: The controls above (budget, rate, tenant, subprocess isolation) are fully implemented. Universal per-action allow/deny based on a declarative policy engine — covering arbitrary tool-call scoping — requires the deterministic enforcement engine, which is on the roadmap.

Key principle: Budget exhaustion, rate limit breach, and tenant boundary violations are blocked before execution. The checks do not rely on the agent's own judgment about authorization.

Output filtering

Operates after the LLM responds. The action may have already started. Filters text — does not intercept tool calls.

✗ After the fact

Observability

Records what happened. Useful for investigation and attribution. Cannot stop wrong actions from executing.

✗ Read-only

KDCube enforcement

Checks budget, rate limits, and tenant identity before execution. Subprocess isolation blocks direct network access. Declarative per-action policy enforcement is on the roadmap.

✅ Before execution (budget, rate, tenant, isolation)

Designed to support enterprise compliance requirements

KDCube is designed to support SOC 2-style controls, including budget/rate decision logging, access control, tenant data isolation, and operational monitoring. It does not claim SOC 2 certification and does not replace your compliance program.

Because KDCube is self-hosted, your organization retains direct control over the security posture of the deployment. You configure network rules, access controls, data retention policies, and encryption settings. No third party has access to your agent traffic or audit logs.

Compliance-relevant capabilities:

Audit logging

Budget charges, rate-limit decisions, and throttling events are logged with request context (tenant, user, timestamp, decision reason). Monitoring API exposes circuit breaker state, queue depths, and throttling statistics. All data stored on your infrastructure.

Data isolation

Gateway-level tenant identity enforced on every request. Cross-tenant DB access blocked. Note: KB API tenant scoping is in progress — validate isolation boundaries before production multi-tenant deployment.

Access control

Integrates with your existing auth system: AWS Cognito (implemented), custom JWT (implemented). Token validated before processing.

Data residency

Self-hosted. Data does not leave your infrastructure. You control where it is stored and retained.

Encryption

TLS in transit when configured with the provided nginx_proxy_ssl.conf; see deployment guide. Encryption at rest is your deployment responsibility — you configure it per your requirements.

Incident investigation

Decision log provides the record needed to reconstruct agent behavior. Every decision is timestamped and accessible via the control plane monitoring dashboard.

Important: KDCube is designed to support these controls. It does not certify compliance on your behalf. Compliance certification requires your organization's formal program, scope definition, and auditor assessment.