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.
What KDCube is designed to address #
Enterprise AI agents face operationally reasonable risk categories. KDCube's runtime enforcement layer is designed to constrain each before execution.
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.
Indirect Prompt Exfiltration via Artifacts / Journal / URL Content #
Untrusted content embedded in retrieved files, prior turn history, or fetched URLs attempts to smuggle instructions that coerce the agent into leaking sensitive context or bypassing expected behavior.
sources_used. Reviewers can reconstruct exactly which inputs influenced a response, and injected content that does not map to a trusted source is traceable as such.
For internal orchestration agents (non-user-facing), journal content from tool results and URL-fetched content is treated as untrusted data, not as trusted instructions. The agent is designed to process and report on potentially adversarial content without acting on embedded directives.
For direct user-facing agents, the system prompt explicitly instructs refusal to disclose confidential system instructions regardless of injection attempts.
Tool Misuse #
LLM-generated code or an agent tool call attempts to reach external systems or perform side effects outside the intended execution boundary — bypassing the isolation layer that separates untrusted code from networked tool access.
ToolStub, the supervisor resolves the callable from its alias map and executes it with full network access. The executor runs as a dropped-privilege user (UID 1001) with a read-only root filesystem and no secret environment passthrough. Budget caps block excessive spend before enqueue; tenant boundary validation blocks cross-scope queries at the gateway layer.
Cross-Tenant Data Leakage #
In a multi-tenant deployment, an agent serving Tenant A accidentally — or through manipulation — accesses data belonging to Tenant B.
(tenant, project, user) tuple; cross-tenant routing is blocked at admission. Layer 2 (Runtime): execution context propagates tenant ID through the entire stack. Layer 3 (Database): schema-level isolation with tenant-scoped queries on every read/write. Layer 4 (File Storage): path-based segregation under tenants/{tenant_id}/projects/. Layer 5 (Cache & Queue): Redis keys and queue names namespaced per tenant/project.
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.
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.
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.
Enforcement controls #
The complete enforcement surface — what the runtime blocks before execution, and what's being extended next.
Controls mapped to global legislation and standards #
Each documented control corresponds to one or more enforceable legal or regulatory obligations, NIST SP 800-53 security controls, or OWASP ASVS / Top 10 requirements. The table below maps controls to specific framework articles, NIST controls, and OWASP verification requirements that the control satisfies. All evidence is drawn from source documentation; legislation and standard scope is provided for reference and does not constitute legal advice.
| Control | Status | Legislation / framework / standard mapping |
|---|---|---|
| Budget caps per user · project · org |
✅ Available |
GDPR Art. 25 Data protection by design — limits excessive processing EU AI Act Art. 9 Risk management system — budget caps as quantified risk boundary SOC 2 CC6/CC7 Logical access & change management — per-scope spending limits NIST SP 800-53 SA-15 Development process / security requirements — resource constraints on automated systems OWASP ASVS V4.2 Operation-level access control — enforce per-user and per-project resource quotas |
| Rate limiting Redis token bucket · 4 tiers |
✅ Available |
GDPR Art. 32 Security of processing — DoS/abuse prevention is a required technical measure NIS2 Art. 21(2)(d) Supply-chain and access-control measures for essential/important entities (EU) EU AI Act Art. 15 Accuracy, robustness, cybersecurity — rate controls constrain AI system misuse NIST SP 800-53 SC-5 Denial-of-service protection ISO 27001 A.13 Communications security — network service controls OWASP Top 10 API4:2023 Unrestricted Resource Consumption — token-bucket rate limiting directly mitigates this API risk |
| Tenant boundary validation 5-layer defense-in-depth |
✅ Available |
GDPR Art. 5(1)(f) Integrity & confidentiality principle — structural prevention of cross-tenant exposure GDPR Art. 32 Technical measures to ensure confidentiality HIPAA §164.312(a)(1) Access control — uniquely assign user IDs, restrict PHI access to authorized users HIPAA §164.312(b) Audit controls — activity tracked per tenant SOC 2 CC6.1 Logical access security — role and boundary controls CCPA §1798.150 Reasonable security procedures — prevents unauthorized cross-consumer access (California) ISO 27001 A.9 Access control policy PDPA (Thailand / Singapore) Appropriate security measures for personal data NIST SP 800-53 AC-4 Information flow enforcement — 5-layer boundary validation prevents cross-tenant data flow OWASP Top 10 A01:2021 Broken Access Control — tenant boundary validation directly addresses horizontal privilege escalation |
| ISO runtime 5-layer sandbox Docker mode — read-only FS, no executor network, UID 1001, Unix socket mediation |
✅ Available |
GDPR Art. 32 Technical security measures — process isolation as appropriate technical safeguard EU AI Act Art. 15 Cybersecurity requirements for high-risk AI systems HIPAA §164.312(c)(1) Integrity controls — prevent unauthorized alteration or destruction of ePHI NIST SP 800-53 SC-39 Process isolation — separate execution domains NIST SP 800-53 AC-6 Least privilege — executor runs at minimal UID/GID, no secret passthrough SOC 2 CC6.6 Logical access — external threat controls ISO 27001 A.12.6 Technical vulnerability management OWASP Top 10 A03:2021 Injection — read-only filesystem and network isolation prevent code injection from escaping sandbox |
| Supervisor pattern for tool dispatch UID-verified Unix socket · endpoint allowlist |
✅ Available |
GDPR Art. 32 Appropriate technical security measures — mediated outbound access EU AI Act Art. 9 Risk management — controlled tool dispatch as part of AI system risk controls NIST SP 800-53 AC-6 Least privilege — tool access only via trusted supervisor path NIST SP 800-53 CA-3 System interconnections — endpoint allowlist as authorized connection control ISO 27001 A.9.4 System and application access control NIS2 Art. 21(2)(e) Supply chain security — outbound endpoint allowlisting OWASP ASVS V4.2 Operation-level access control — UID-verified Unix socket enforces per-operation least-privilege dispatch |
| Decision logging self-hosted · versioned turn snapshots · timeline replay |
✅ Available |
GDPR Art. 30 Records of processing activities — per-request log with tenant, user, decision reason GDPR Art. 33 Breach notification — logs provide the evidence basis required within 72 hours HIPAA §164.312(b) Audit controls — hardware, software, procedural mechanisms to record ePHI activity EU AI Act Art. 12 Logging requirements for high-risk AI systems — traceability of AI decisions SOC 2 CC7.2 Monitor system components for anomalies NIS2 Art. 23 Incident reporting — logs are the source material for regulatory notifications NIST SP 800-53 AU-2 / AU-3 Audit events / audit record content ISO 27001 A.12.4 Logging and monitoring OWASP ASVS V7.1 Log content requirements — versioned turn snapshots satisfy security-event logging verification requirements |
| Role-based event filtering org · project · tenant visibility |
✅ Available |
GDPR Art. 5(1)(f) Confidentiality — least-privilege visibility enforced on control-plane data HIPAA §164.312(a)(1) Role-based access control — limit PHI-related operational data to authorized roles SOC 2 CC6.3 Role-based access to system resources ISO 27001 A.9.2 User access management — access provisioned on least-privilege basis NIST SP 800-53 AC-2 Account management — role and scope separation OWASP ASVS V4.1 Access control design — org/project/tenant visibility scoping aligns with general access control requirements |
| Attachments security: AV scanning ClamAV at ingress · configurable |
✅ Available |
GDPR Art. 32 Appropriate technical measures to ensure security of processing NIS2 Art. 21(2)(e) Anti-malware and security policies as part of network and information system security SOC 2 CC6.8 Protection from malicious software ISO 27001 A.12.2 Protection from malware HIPAA §164.312(a)(1) Technical access controls — prevent malware ingestion into systems processing ePHI NIST SP 800-53 SI-3 Malicious code protection — ClamAV scanning at ingress satisfies SI-3 implementation OWASP ASVS V12.2 File integrity — antivirus / antimalware scanning of uploaded files before processing |
| File preflight validation + macro blocking MIME · PDF/ZIP/OOXML heuristics · macro block |
✅ Available |
GDPR Art. 32 Technical security measures at ingress ISO 27001 A.12.2 Protection from malware — executable macro blocking ISO 27001 A.12.5 Control of operational software — type enforcement at system boundary SOC 2 CC6.8 Malicious software protection NIS2 Art. 21(2)(e) Security policies for network and information systems NIST SP 800-53 SI-3 Malicious code protection — MIME/heuristic preflight as additional malicious-code detection layer OWASP ASVS V12.1 File upload requirements — MIME type validation and dangerous file extension blocking at ingress |
| Cookie-only infra token exchange delegated auth mode · proxy boundary |
✅ Available |
GDPR Art. 32 Pseudonymisation and encryption — credential not exposed to client JS layer HIPAA §164.312(d) Authentication — verify identity before granting access to ePHI systems SOC 2 CC6.1 Logical access — authentication mechanism controls PCI DSS v4 Req 6.4 Web application security — protect against credential theft (if payment-adjacent deployments) ISO 27001 A.9.4 System and application access control NIST SP 800-53 IA-3 Device identification and authentication — proxy-boundary token exchange authenticates infrastructure layer OWASP ASVS V3.4 Cookie-based session management — HttpOnly cookie token flow prevents credential exposure to client scripts |
| Deployment-level resource limits configurable per deployment |
✅ Available |
GDPR Art. 32(1)(b) Ensuring ongoing availability and resilience of processing systems NIS2 Art. 21(2)(c) Business continuity and crisis management — resource limits protect system stability ISO 27001 A.17 Business continuity management SOC 2 A1 Availability — processing commitments met via resource controls NIST SP 800-53 SC-6 Resource availability — configurable deployment-level limits enforce per-process resource boundaries OWASP Top 10 API4:2023 Unrestricted Resource Consumption — deployment-level limits cap CPU/memory/execution at system boundary |
| Session ownership validation User-Session-ID header · gateway-enforced |
✅ Available |
GDPR Art. 32 Technical measures to ensure integrity of processing — session binding prevents unauthorized request injection HIPAA §164.312(d) Authentication — verify identity of users requesting access to ePHI systems before processing SOC 2 CC6.1 Logical access security — session ownership binding enforces per-user authentication controls NIST SP 800-53 IA-8 Identification and authentication — reject mismatched session identifiers before any processing OWASP ASVS V3.2 Session binding — session tokens must be bound to the authenticated user and rejected on mismatch |
| Named secrets and secret resolution env vars → settings → secrets manager · never in bundle config |
✅ Available |
GDPR Art. 32 Appropriate technical measures — credentials not embedded in config reduces exposure surface HIPAA §164.312(a)(2)(iv) Encryption and decryption — secrets managed outside application layer prevent credential leakage SOC 2 CC6.1 Logical access — credential management controls prevent unauthorized access via exposed secrets NIST SP 800-53 IA-5 Authenticator management — named secret resolution enforces credential lifecycle controls OWASP ASVS V2.10 Service authentication — application secrets must not be stored in source code or config files |
| Policy DSL · Deterministic pre-execution enforcement · Workflow invariants · Cross-agent approval gates Roadmap |
🔮 Roadmap |
EU AI Act Art. 9 Risk management obligations for high-risk AI — declarative policy coverage planned EU AI Act Art. 14 Human oversight — approval gates provide mandatory human-in-the-loop checkpoints GDPR Art. 22 Automated decision-making — human review mechanisms via approval gates SOC 2 CC8 Change management — workflow invariants prevent unauthorized step skipping NIST AI RMF GOVERN Governance function — human oversight and accountability structures |
Scope note: Legislation and standard references are informational mappings between documented technical controls and regulatory/standards frameworks as of March 2026. The EU AI Act requirements for high-risk AI systems (Articles 9, 12, 14, 15) apply depending on the use-case classification of a given deployment. HIPAA applicability depends on whether the deployment processes Protected Health Information. CCPA applicability depends on jurisdiction and data subject scope. NIST SP 800-53 references are drawn from Rev. 5; OWASP ASVS references target ASVS v4.0.3 and OWASP Top 10 2021/API 2023. This mapping does not constitute legal advice — your organization's compliance program and legal counsel determine applicable obligations. KDCube provides the technical controls; certification scope and formal assessment are your organization's responsibility.
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:
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.
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 the LLM call fires. Subprocess isolation blocks direct external network access. All tool dispatch verified via UID-enforced Unix socket. No action in-scope proceeds without clearing these checks.
✅ Before execution (budget, rate, tenant, isolation)
Built for enterprise compliance requirements #
KDCube provides the technical controls that SOC 2, HIPAA, and GDPR programs require (controls available; full certification status depends on deployment configuration): structured audit logging, role-based access control, multi-layer tenant data isolation, and operational monitoring. All data stays on your infrastructure — no third party has access to your agent traffic or audit logs.
Because KDCube is self-hosted, your organization has direct, full control over the security posture. You configure network rules, access controls, data retention policies, and encryption settings to match your deployment requirements exactly.
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
Five-layer defense-in-depth: gateway admission enforces (tenant, project, user) on every request; runtime propagates tenant context through the full execution stack; database queries are tenant-scoped; file storage uses tenant-namespaced path prefixes; Redis keys and queues are namespaced per tenant/project.
Access control
Multi-provider auth: AWS Cognito (production), delegated auth via proxy login service, and SimpleIDP for dev/local deployments. Token validated before processing on every request.
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.
Attachments security
Ingress attachments can be scanned and validated before storage, including AV checks, preflight type validation, and macro-enabled OOXML blocking controls.
Citations / provenance
Source pools maintain stable source IDs (SIDs). Generated text carries citation tokens that resolve to those SIDs, and each artifact records sources_used. Combined with timeline entries, this provides concrete end-to-end provenance for claims and outputs.
Incident investigation
Decision logs include timestamped enforcement outcomes plus versioned turn snapshots. Teams can replay turn history to reconstruct what was requested, what checks ran, which tools executed, and which artifacts/sources influenced the final output.
KDCube delivers the technical controls your compliance program requires.
Audit logs, access controls, tenant isolation, and data residency are built into the platform. Certification scope, formal program definition, and auditor assessment are owned by your organization — KDCube provides the controls, you own the compliance posture.
Build AI that doesn't break trust
Deploy runtime controls in under an hour. Review the code, run it in your environment, and evaluate the enforcement layer directly.