[ security ]
Data Sovereignty & AI Security Whitepaper
Last updated:
Version 1.0, June 2026 Audience: Security, compliance, and data-protection stakeholders Classification: Customer-facing
1. Executive Summary
The Kikimora AI Platform provides an AI assistant for security operations: it connects large-language-model reasoning to an organization’s security tooling (cloud platforms, ITSM, scanners, firewalls) through a controlled, auditable integration layer.
This document describes the platform’s current, implemented data sovereignty and security controls. It is written to answer four questions a security organization must ask of any AI system before adoption:
- Where is data processed and stored, and under which jurisdiction?
- What can the AI actually do - and what can it categorically not do?
- How are abuse, malicious exploitation, and unintended behavior prevented and detected?
- How is every action of the system observed, logged, and attributable?
The short answers: all model inference, application data, and observability data are processed and stored exclusively in the European Union; the AI’s capabilities are restricted to an explicitly allow-listed, deterministic, predominantly read-only tool set with server-side schema validation; no customer data is used for model training and inference data is subject to zero-retention processing; and every agent action is traced end-to-end in an EU-hosted observability platform.
Everything described in this document is implemented and operational today.
2. System Overview
┌──────────────────────────────────────────────────────────────────┐
│ USER LAYER │
│ Web client · per-user authentication · role-based access · │
│ tenant-scoped sessions │
├──────────────────────────────────────────────────────────────────┤
│ APPLICATION LAYER (self-hosted, containerized) │
│ Chat application · agent runtime · credential vault │
│ MongoDB cluster - EU region only │
├──────────────────────────────────────────────────────────────────┤
│ TOOL / INTEGRATION LAYER (self-hosted MCP services) │
│ Deterministic API connectors: Azure, ServiceNow, scanners, │
│ firewalls, cloud providers - allow-listed tools, strict │
│ input validation, read-only by default │
├──────────────────────────────────────────────────────────────────┤
│ MODEL LAYER │
│ Google Vertex AI - EU data-residency endpoints only · │
│ no training on customer data · zero retention │
├──────────────────────────────────────────────────────────────────┤
│ OBSERVABILITY LAYER │
│ LangSmith (EU region) - full trace of every agent run: │
│ prompts, tool calls, parameters, results, model responses │
└──────────────────────────────────────────────────────────────────┘Key architectural property: the model never touches external systems directly. Every interaction between the AI and a customer system passes through a self-hosted integration service (an MCP server) that exposes only a fixed, reviewed set of operations. The model proposes; deterministic, validated code executes.
3. Data Sovereignty
3.1 Model inference - EU-only, by configuration and by endpoint class
All LLM inference runs on Google Cloud Vertex AI, pinned to the EU multi-region. This is enforced at the platform configuration level, and - importantly - the platform routes through Google’s regional data-residency endpoints (aiplatform.eu.rep.googleapis.com), the endpoint class Google provides specifically for data-residency guarantees, rather than the global API surface. Requests cannot silently fail over to non-EU regions: a misconfiguration produces an error, not a cross-border request.
3.2 No training on customer data; zero retention
Under Google Cloud’s Vertex AI data-governance commitments:
- Customer prompts, retrieved context, tool results, and model responses are not used to train Google’s foundation models. This is a contractual property of Vertex AI as an enterprise service (Google Cloud Service Terms), distinct from consumer AI offerings.
- Zero data retention: inference data is processed in memory to generate the response and is not stored by the model service after processing. Vertex AI’s data-caching behavior can be and is disabled for zero-retention operation.
The combination means the model layer is a stateless processor under EU jurisdiction: data goes in, an answer comes out, nothing remains and nothing is learned from it.
3.3 Application data - EU-resident MongoDB
All application state - user accounts, conversations, agent configurations, integration credentials - resides in a MongoDB cluster deployed exclusively in an EU region. There is no replication to, or backup in, any non-EU region.
3.4 Observability data - EU-resident LangSmith
Agent execution traces (Section 7) are stored in LangSmith’s EU region. Monitoring the AI does not create a side channel that exports data out of the EU.
3.5 Encryption in transit and at rest
- In transit: TLS on all paths - user ↔ platform, platform ↔ integration services, integration services ↔ customer systems, platform ↔ Vertex AI, platform ↔ LangSmith.
- At rest: database-level encryption at rest on the MongoDB cluster. Integration credentials receive an additional application-layer encryption (AES-256) before storage, so credentials are never persisted in plaintext even inside the encrypted database (Section 5.2).
3.6 Deployment sovereignty
The entire platform - application, integration services, supporting services - is containerized and self-hosted. No component depends on a third-party SaaS other than the two EU-pinned services named above (Vertex AI, LangSmith). For customers with elevated sovereignty requirements, the same artifacts deploy as a single-tenant instance in a customer-controlled VPC or on-premises environment.
4. The Tool Layer: What the AI Can and Cannot Do
The most important AI-security property of the platform is that the model’s agency is bounded by construction, not by instruction. Prompt-level rules can be attacked; the following properties are structural.
4.1 Deterministic connectors - no generated code is ever executed
Every tool available to the AI is a hand-written, code-reviewed API operation against a specific external system. Tools are deterministic wrappers: fixed endpoint, fixed operation, parameterized inputs.
The platform contains no code-execution tool, no shell access, no arbitrary HTTP request capability. The model cannot write code and have it run, cannot reach arbitrary URLs, and cannot compose operations that were not explicitly implemented. If an operation does not exist as a reviewed tool, the AI cannot perform it - regardless of what any prompt, user, or injected instruction says.
4.2 Allow-listing at two levels
- Service level: each integration service exposes only its implemented, reviewed tool set - nothing is dynamically generated.
- Agent level: each AI agent is configured with an explicit list of permitted tools. Tools not on the list are invisible to the model - they are not merely blocked; the model does not know they exist.
4.3 Read-only by default
The tool fleet is overwhelmingly read-only: inventory queries, security findings, policy and configuration reads, log retrieval. Write-capable operations are rare, individually justified, narrowly scoped (e.g., creating an ITSM ticket), and stand out by design in both the allow-list and the audit trail. There are no destructive operations (no delete-resource, no modify-firewall-rule, no terminate-instance) anywhere in the current tool fleet.
4.4 Strict server-side input validation
Every tool input is validated server-side against a strict schema (zod) before any API call is composed: types, required fields, enumerations, and bounds. Malformed or out-of-contract parameters - whether produced by model error or by an injection attempt - are rejected by the integration service before reaching any customer system. Validation happens in the integration layer, outside the model’s influence.
4.5 Defense-in-depth effect
These four properties compose into the platform’s core containment argument:
Even a fully compromised model - through prompt injection, jailbreak, or model error - can only invoke pre-approved, validated, predominantly read-only operations, authenticated with the requesting user’s own credentials (Section 5), with every invocation logged (Section 7).
The blast radius of the worst-case model failure is bounded to: reading data the requesting user was already authorized to read.
5. Identity, Credentials, and Tenant Isolation
5.1 The AI acts as the user - never as a superuser
There is no privileged “AI service account” with standing access to customer systems. Integration credentials are per-user and per-tenant: each user connects their own credentials for each integration, and when the AI executes a tool on that user’s behalf, it authenticates with that user’s credentials. The AI’s effective permissions in any external system are exactly the requesting user’s permissions - the platform adds zero privilege.
5.2 Credential handling
- Credentials are stored AES-256-encrypted at the application layer in the EU MongoDB cluster, on top of database encryption at rest.
- They are decrypted per request and injected into the specific integration call, scoped to that request’s execution context.
- Integration services hold credentials in memory for the duration of a request only - no integration service stores credentials at rest, and a compromise of an integration container yields no credential material.
- Credentials are never visible to the model. They travel application → integration service directly; the model sees tool names and parameters, never secrets.
5.3 Tenant isolation
The platform is multi-tenant with tenant scoping enforced server-side on every request: users are bound to their tenant, integration configurations are keyed per user and tenant, and tenant context propagates through the agent runtime into every tool invocation. Cross-tenant access is rejected at the application layer, not left to model behavior.
5.4 Role-based access control
Administrative capabilities (tenant management, user provisioning, integration governance) are restricted to defined administrative roles. Standard users operate strictly within their own tenant and their own connected integrations.
6. Addressing the Four AI-Risk Categories
The platform’s controls map directly to the four risk categories a security organization typically requires evidence for - each with both a control (prevention) and a detection mechanism:
| Risk | Control (prevention) | Detection |
|---|---|---|
| Abuse (misuse of the AI’s capabilities) | Per-user authentication; the AI holds only the requesting user’s privileges; read-only-by-default tools; RBAC on administrative functions | Per-user attribution of every agent run and tool call in the audit trail |
| Malicious exploitation (prompt injection, jailbreaks) | No code execution, no arbitrary HTTP; allow-listed tool surface invisible beyond configuration; server-side schema validation rejects out-of-contract inputs; credentials never in model context | Full prompt + tool-call traces enable review of anomalous instruction patterns and tool-use sequences |
| Hallucination (fabricated answers) | Retrieval-grounded answering for knowledge questions: responses to compliance/standards queries are grounded in retrieved source documents with citations; operational answers are grounded in live tool results, not model memory | Traces preserve the retrieved context and tool results alongside the model’s answer, making grounding verifiable after the fact |
| Unintended behavior (actions nobody asked for) | The AI cannot act outside its tool list; write operations are rare, scoped, and explicit; humans direct the interaction - there is no autonomous write path in the current platform | Every action (including every attempted action) appears in the execution trace with its triggering context |
7. Monitoring, Logging, and Auditability
Every agent execution is traced end-to-end in LangSmith, hosted in the EU region:
- the user’s input and the full prompt context assembled for the model,
- every model invocation and response,
- every tool call: tool name, parameters, target integration, and returned result,
- retrieval operations and the documents/context retrieved,
- timing, token usage, and error states.
Properties of the audit trail:
- Attribution: each trace is tied to the authenticated user and tenant that initiated the run.
- Completeness: there is no untraced execution path - tool calls are emitted by the agent runtime itself, not self-reported by the model.
- Reviewability: traces allow security teams to answer, for any answer the AI ever gave: what was it asked, what did it look at, what did it do, and what did it base its answer on.
- Sovereignty-consistent: the observability pipeline meets the same EU-residency bar as the data it observes (Section 3.4).
This trace layer is the platform’s answer to the detection half of AI governance: the system is not just constrained, it is observable in full.
8. Regulatory Alignment
The controls above are designed to support customer obligations under the European regulatory landscape:
- GDPR / DSGVO: EU-only processing and storage (Sections 3.1–3.4); no use of personal data for model training (3.2); zero retention at the model layer (3.2); encryption in transit and at rest (3.5); per-user attribution and full processing transparency via traces (7); single-tenant/on-premises deployment options for data-protection-impact-driven requirements (3.6).
- NIS2 / national critical-infrastructure regimes (e.g., BSI oversight, IT-SiG 2.0): least-privilege integration model (5.1), bounded and reviewed tool surface (4), comprehensive logging and attribution (7), self-hosted deployment under operator control (3.6).
- EU AI Act: the platform operates as a human-directed assistant - humans initiate every interaction, the system has no autonomous action path, all capabilities are bounded and logged; transparency and traceability obligations are supported natively by the trace layer (7).
- OWASP LLM Top 10: the architecture directly addresses the highest-ranked risks - prompt injection (LLM01) via structural capability bounding rather than prompt-level defense (4.5); insecure output handling (LLM02) via server-side validation (4.4); sensitive information disclosure (LLM06) via credential isolation from model context (5.2) and per-user privilege scoping (5.1); excessive agency (LLM08) via allow-listing, read-only defaults, and absence of destructive operations (4.2–4.3).
(This section describes architectural alignment; it does not constitute a certification claim.)
9. Summary of Controls
| Domain | Control | Status |
|---|---|---|
| Model inference location | Vertex AI, EU multi-region, data-residency endpoint class | Implemented |
| Model training on customer data | None - contractual (Vertex AI enterprise terms) | Implemented |
| Inference data retention | Zero retention at model layer | Implemented |
| Application data location | MongoDB cluster, EU region only | Implemented |
| Observability data location | LangSmith, EU region | Implemented |
| Encryption in transit | TLS on all paths | Implemented |
| Encryption at rest | Database-level + AES-256 application-layer for credentials | Implemented |
| Tool surface | Deterministic, allow-listed, no code execution, no arbitrary HTTP | Implemented |
| Tool input safety | Server-side zod schema validation | Implemented |
| Write capability | Read-only by default; rare, scoped, explicit write tools; no destructive operations | Implemented |
| Privilege model | Per-user, per-tenant credentials; AI holds requesting user’s privileges only | Implemented |
| Credential exposure | Never in model context; per-request injection; no at-rest storage in integration services | Implemented |
| Tenant isolation | Server-side enforcement on every request | Implemented |
| Hallucination control | Retrieval-grounded answers with citations; tool-grounded operational answers | Implemented |
| Audit trail | Full agent-run tracing (prompts, tool calls, results), per-user attribution, EU-hosted | Implemented |
| Sovereign deployment | Single-tenant VPC / on-premises option | Available |