Security & Architecture Whitepaper

0. Executive summary

Citorum is an enterprise Retrieval-Augmented Generation (RAG) platform built for organizations whose data does not leave the boundary. Customer corpora, queries, responses, and audit logs stay inside the customer’s trust boundary in every supported deployment topology. The Citorum control plane handles licensing, entitlements, and release distribution; it sees no corpus content, no queries, no responses, and no user-identifying information. Egress policy is enforced at the network layer, not asked for politely at the application layer.

This document covers four things, in order. Sections 1–3 establish what the system looks like and what it is defending against. Sections 4–8 are the controls inventory: identity, encryption, key management, model security, and audit. Sections 9–11 cover operations: incident response, coordinated disclosure, and sub-processors. Sections 12–14 cover where we are on compliance, how this document maps to the standard questionnaires, and how to take the conversation further.

One thing worth saying up front: Citorum is pre-audit. We have not completed a Service Organization Control (SOC) 2 Type I or Type II audit, and we do not hold International Organization for Standardization (ISO) 27001 certification. Section 12 names this explicitly and describes what we offer in the interim. Buyers whose procurement process requires an audited report before contract should know that now, not after the demo.

1. Audience & scope

This document is written for Chief Information Security Officers (CISOs), security architects, platform-engineering leads, and the procurement teams running diligence on Citorum. It assumes the reader is familiar with standard enterprise software security review and is not interested in a marketing summary of why RAG matters.

In scope: the security and architecture posture of the Citorum runtime, the control plane, and the data flows between them, across all three supported deployment topologies. The threat model, the trust boundaries, the controls that mitigate the threats, the audit emission, the incident-response process, and our coordinated disclosure commitments.

Out of scope, by design: tuning details for the adjudication ensemble, per-signal weight tables, internal runbooks for production deployment, and the Cloud Security Alliance Consensus Assessments Initiative Questionnaire Lite (CAIQ Lite) and Shared Assessments Standardized Information Gathering Lite (SIG Lite) responses with specific control descriptions. Those are available under non-disclosure agreement (NDA) on request to [email protected].

Three deployment topologies. Citorum ships in three runtime placements, summarized in Figure 1. Topology choice changes who operates the runtime; it does not change how the system works. The data path is the same across all three, the controls inventory is the same, and this whitepaper covers all three unless a section says otherwise.

• Topology I — On-premises.Runtime in the customer’s own datacenter. Air-gap capable. Operated by the customer. Used by air-gapped environments, sovereign-cloud deployments, and customers with regulatory or contractual restrictions on cloud egress.
• Topology II — Customer cloud.Single-tenant Virtual Private Cloud (VPC) in the customer’s account on Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure. Operated by the customer. Sometimes called Bring Your Own Cloud (BYOC).
• Topology III — Citorum-managed. Dedicated single-tenant runtime operated by Citorum. Not multi-tenant. Customers who want the deployment shape of a Software-as-a-Service (SaaS) product but the isolation of a dedicated tenancy.

2. Threat model

The threat model is organized around four assets, four actor classes, and the boundaries the assets must not cross.

2.1 Assets

• Customer corpora. The documents, records, and structured data that the customer has ingested for retrieval. The largest single asset class by volume and the most sensitive in most deployments.
• Queries and responses. The user-submitted question, the retrieved context, the generated answer, and the per-signal adjudication scores. Frequently more sensitive than the corpus they were drawn from, because they reveal what someone was asking about.
• Audit log. The append-only, tamper-evident record of every retrieval, prompt, response, citation, and adjudication score. Both an asset to protect and a control that makes other compromises detectable.
• Keys. The data-encryption keys, the key-encryption keys, the signing keys for audit-log entries, and the service-account credentials used by the runtime. Held in the customer’s Key Management Service (KMS) for all deployment topologies.

2.2 Actors

• External adversary. Internet-facing attacker without credentials. Mitigated by transport encryption, ingress filtering, identity gating, and the absence of an externally-reachable corpus store in any topology.
• Compromised user account. Adversary with valid credentials for a user whose access scope is limited by Role-Based Access Control (RBAC). Mitigated by tenant scoping at the application layer, retrieval scoping at the index layer, and audit emission of every access.
• Malicious or compromised insider. A person with privileged access to part of the system. Mitigated by separation of duties between identity, infrastructure, and data, by audit emission with tamper-evidence, and by the customer holding all encryption keys in their own KMS.
• Compromised supply chain. A malicious dependency, a backdoored container image, or a compromised build pipeline. Mitigated by container image signing, dependency scanning, and the bill-of-materials disclosure described in Section 11.

2.3 Trust boundaries

Three boundaries matter. (a) The customer boundary — the line drawn in Figure 1 between the customer-controlled runtime and the Citorum-operated control plane. Corpus content, query content, response content, and user-identifying information do not cross this boundary in any direction. (b) The tenant boundary — in Topology III only, the line between one customer’s dedicated runtime and any other customer’s. Enforced by single-tenant infrastructure rather than multi-tenant software. (c)The runtime boundary — between the application and inference layers and the underlying compute. Documents reach the inference layer only as part of an in-memory context window; weights do not change in response to corpus content (Section 7).

3. Architecture overview

Figure 2 traces a single query end-to-end. The lifecycle is the same in all three deployment topologies; what changes is who operates each box.

(01) User and (02) application.A user authenticated through the customer’s Identity Provider (IdP) submits a question to the application layer. The application performs tenant scoping — resolving the user’s identity, the tenant or workspace they are operating within, and the document-level Access Control List (ACL) constraints that will be applied to retrieval.

(03) Retrieval. Three retrieval modes run in parallel against the customer’s corpus: vector similarity against an index built with the pgvector extension to PostgreSQL, full-text search against PostgreSQL’s built-in tsvectorindex, and metadata filtering on ACL fields, tag fields, and timestamp ranges. Results are merged. Results that the user is not entitled to see by ACL are never returned by the retrieval layer — not filtered post-hoc, but never indexed into the candidate set in the first place.

(04) Context assembly.The merged result set is reranked, deduplicated, and capped to fit the model’s context window.

(05) Large Language Model (LLM) inference.The assembled context and the user’s question are sent to the LLM inference layer running on customer Graphics Processing Units (GPUs) with customer-pinned model weights. No egress: the inference layer has no network path off the customer runtime. Section 7 covers what model we run and why.

Adjudication pipeline. The LLM’s candidate answer, the retrieved sources, and the original question are passed to a five-signal adjudication ensemble. The signals score the answer against its sources for grounding, contradiction, entity overlap, and faithfulness; a weighted ensemble produces one of three labels — Verified, Review Recommended, or Do Not Rely. Section 7 covers the signals in detail. Critically, the contradiction-max signal acts as a veto: when it crosses 0.60 the label is forced to Do Not Rely regardless of the ensemble score.

(06) Response.The response, the per-source citations, and the adjudication label are returned to the user through the application layer. The label rides on the response — it is not advisory metadata that callers can elide.

(07) Audit. Every retrieval, prompt, response, citation, and per-signal adjudication score is written to the append-only audit log inside the customer runtime. Section 8 covers retention, tamper-evidence, and Security Information and Event Management (SIEM) export.

4. Identity & access

Identity stays in the customer’s Identity Provider. Citorum does not maintain a parallel user directory for production deployments. There is no Citorum-issued password for any production end-user, no Citorum-managed second factor, and no Citorum-side user record that can drift out of sync with the IdP.

4.1 Federation

Three federation protocols are supported, covering the spectrum of enterprise identity providers:

• Security Assertion Markup Language (SAML) 2.0 — for enterprise IdPs including Okta, Microsoft Entra ID (formerly Azure Active Directory), Ping Identity, and OneLogin.
• OpenID Connect (OIDC) — for IdPs that prefer it over SAML, and for customer-built identity layers fronted by an OIDC-compliant proxy.
• System for Cross-domain Identity Management (SCIM) 2.0 — for automated user and group provisioning. Joiners, movers, and leavers are reflected without manual administrative action.

4.2 Authorization

Access is governed by Role-Based Access Control (RBAC). Roles are defined per-deployment and gate three orthogonal capability sets: collection access (which corpora a user can query against), document access (which documents within a collection are visible, derived from per-document ACLs synchronized from the customer’s source-of-truth system), and administrative operations (who can configure collections, manage roles, view audit logs, or invoke break-glass procedures).

Document-level ACLs are enforced at the retrieval layer, not the response layer. A user’s query against a collection containing documents they are not entitled to see will never have those documents enter the candidate result set — the index is filtered by ACL before similarity scoring runs, not after.

4.3 Service accounts and break-glass

Service accounts used by the runtime (database access, KMS access, audit-log signing) are scoped to specific operations. Each service account has its own credential, its own audit trail, and its own rotation policy. Break-glass administrative access is supported through a separately-controlled credential that is held by the customer security team and not present in normal operating state — its use triggers a high-priority audit event that the customer is responsible for reviewing.

See Figure 3 for the runtime-side view of identity-gated retrieval and per-request isolation.

5. Data protection

Encryption is applied in three layers.

In transit. Transport Layer Security (TLS) 1.3 for every network hop, including the east-west traffic between internal runtime services. TLS 1.2 is supported for compatibility with customer IdPs and KMS endpoints that have not yet upgraded; TLS 1.1 and earlier are not negotiated. Cipher suites are restricted to those on the Internet Engineering Task Force (IETF) recommended list; legacy and export-grade suites are disabled in the runtime configuration.

At rest.Advanced Encryption Standard (AES) 256 in Galois/Counter Mode (GCM) for the corpus index, the audit log, and all persistent state. Disk-level encryption is applied independently by the underlying infrastructure (the customer’s storage subsystem in Topologies I and II; the Citorum-managed dedicated infrastructure in Topology III) and does not depend on Citorum-side configuration.

Application layer.For sensitive document fields where defense-in-depth requires it — identifiers under Health Insurance Portability and Accountability Act (HIPAA), payment-card data under Payment Card Industry Data Security Standard (PCI DSS), or specific fields the customer designates — application-layer encryption is available. Field-level keys are derived from a tenant key held in the customer’s KMS using the envelope-encryption pattern described in Section 6. The vector index is built against an encrypted form of these fields, so similarity search continues to work without the inference layer needing access to the plaintext.

Keys for all three layers are described in Section 6. No Citorum-controlled key has access to customer data in any topology, including Topology III.

6. Key management

Keys are held in the customer’s Key Management Service. Citorum integrates with the major options:

• Amazon Web Services Key Management Service (AWS KMS)
• Microsoft Azure Key Vault
• Google Cloud Platform Cloud Key Management Service (GCP Cloud KMS)
• Oracle Cloud Infrastructure Vault (OCI Vault)
• HashiCorp Vault, for on-premises and self-managed deployments

6.1 Envelope encryption

The runtime uses envelope encryption. A Data Encryption Key (DEK) encrypts the actual data; the DEK itself is encrypted under a Key Encryption Key (KEK) held in the customer’s KMS and never leaves it in plaintext. The DEK is decrypted in memory at the moment of use and is not persisted in unencrypted form. Each tenant or workspace can be issued a distinct KEK, allowing customer security teams to revoke access to a single tenant without affecting others.

6.2 Rotation

KEK rotation is performed in the customer’s KMS on whatever schedule the customer’s policy requires. The Citorum runtime fetches the current key version on each KMS interaction and re-encrypts DEKs lazily on next write. The customer’s KMS retains the prior key version for the configured retention window so that historical audit-log entries remain decryptable.

6.3 Revocation

When a customer revokes a KEK — or removes the runtime’s service-account permission to access it — all in-flight requests that depend on that key fail closed. The runtime does not cache plaintext DEKs across requests; the cache is sized to the request lifetime, not to a wall-clock window. Revocation is therefore observable in seconds, not hours.

6.4 Audit-log signing

Audit-log entries are signed under a separate signing key held in the same customer KMS but with a different KMS-side key policy — specifically, the signing key permits signing operations but does not permit decryption. This separates the principal who can read the audit log from the principal who can append to it, and supports the tamper-evidence properties described in Section 8.

7. Model & retrieval security

The model layer is where most enterprise-RAG security stories collapse. The standard pattern — send corpus content to a third-party model Application Programming Interface (API) — cannot survive the regulated regimes Citorum is built for. Our approach is the opposite: open-weights models run on customer GPUs, with weights pinned by the customer, and no network path off the runtime.

7.1 What we run

The current default model is Gemma-4, an open-weights model from Google DeepMind, run on customer-controlled GPUs in all deployment topologies. Customers may pin a specific weight checkpoint and stay on that checkpoint indefinitely — the model lifecycle is under customer control, not under Citorum’s control. Customers who require a different open-weights model can request alternatives during deployment; the runtime is model-agnostic above the inference layer.

7.2 Read-only, shared weights

Model weights are loaded read-only into GPU memory and shared across requests. There is no fine-tuning, no Reinforcement Learning from Human Feedback (RLHF), and no online learning loop that incorporates customer data into weights. Customer corpora reach the inference layer only as part of the in-memory context window for a single request; the weights do not change in response to what they have seen.

7.3 Prompt injection

Prompt injection — a malicious instruction embedded in a retrieved document — is treated as a class of attack we cannot fully eliminate at the model layer, and so is mitigated at the layers above and below. Above: the application layer authenticates and tenant-scopes every request before retrieval runs; the model cannot be tricked into accessing a corpus the user is not entitled to see. Below: the adjudication ensemble runs on the output, and a prompt-injected output that is not grounded in retrieved sources is detected as ungrounded by the NLI entailment signal and flagged as Review Recommended or Do Not Rely.

7.4 The adjudication pipeline in detail

Every answer is scored by a five-signal ensemble before it is returned. Inputs to the ensemble are the user’s question, the retrieved sources, and the LLM’s candidate answer. Outputs are the ensemble score, the per-signal scores, and one of three labels.

• s₁ Retrieval score — cosine similarity of the retrieved chunks against the query. Low scores indicate the question may not be answerable from the corpus at all.
• s₂ Natural Language Inference (NLI) entailment, 20th percentile — sentence-level grounding in the retrieved sources. The 20th percentile, rather than the mean, ensures a single ungrounded sentence is not hidden by a sea of grounded ones.
• s₃ NLI contradiction maximum — veto signal — the maximum contradiction score across the answer’s sentences against any retrieved source. When this exceeds 0.60, the label is forced to Do Not Rely regardless of any other signal. This is the hallucination veto.
• s₄ Recall-Oriented Understudy for Gisting Evaluation (ROUGE) entity overlap — named entities in the answer that match named entities in the sources. Catches the failure mode of confidently-stated entities that do not appear in the corpus.
• s₅ LLM Judge — a separate evaluation pass by a different model focused on faithfulness to the cited sources. The judge cannot be the same model whose output is being evaluated.

Signals are combined by a weighted ensemble with the contradiction-max veto applied at the end. The three output labels are emitted with the response:

• Verified — Cite Source. The answer is well-grounded in the cited sources and may be quoted.
• Review Recommended. The answer is partially grounded; a human reviewer should confirm before relying.
• Do Not Rely. The answer is poorly grounded or contains a contradiction with the retrieved sources. The application is expected to route to a reviewer queue rather than display this as an authoritative answer.

The label rides on the response. Applications that suppress the label by design are out-of-spec; we provide configuration for label rendering but not for label removal.

8. Audit & observability

Every retrieval, every prompt, every response, every citation, every per-signal adjudication score, every administrative action, and every user authentication event is written to the audit log. The audit log is append-only, signed, and lives inside the customer runtime.

8.1 Tamper-evidence

Each audit-log entry contains a hash of the previous entry, chained back to a periodically-published checkpoint. The chain is signed under the audit-signing key described in Section 6.4. A verifier with the checkpoint and the customer’s public signing-key material can detect any deletion, reordering, or modification of historical entries. Verification tooling is provided as part of the runtime distribution.

8.2 Retention

Default retention is seven years — long enough to cover the audit windows of Sarbanes-Oxley (SOX) under the Public Company Accounting Oversight Board (PCAOB), HIPAA, and most regulated-industry requirements. Retention is configurable: customers under a longer regulatory hold can extend it; customers under a shorter privacy-driven schedule can shorten it. Retention applies to the encrypted log entries; the keys that decrypt them remain under customer control regardless.

8.3 SIEM export

Audit entries can be streamed in real time to the customer’s Security Information and Event Management system. Native integration is provided for Splunk, Microsoft Sentinel, Sumo Logic, and Elastic Security; generic Syslog (RFC 5424) is supported for any system that accepts it. Stream content is identical to the local audit log; the customer’s SIEM becomes the primary alerting surface for security-relevant events.

8.4 What an audit entry contains

A retrieval-and-generation entry includes: timestamp, request identifier, authenticated user identifier (per the customer’s IdP), tenant scope, the question, the set of retrieved source identifiers with retrieval scores, the assembled context window in identifier form, the candidate LLM answer, the per-signal adjudication scores, the final ensemble score, the emitted label, and the citation set. An administrative entry includes: timestamp, authenticated administrator identifier, action type, action target, and action parameters. The schemas are documented and stable across minor versions.

9. Incident response

Citorum maintains an on-call rotation for production support and security incidents. Incidents are classified by severity:

• Severity 1. Confirmed unauthorized access to customer data, or active exploitation of a Citorum-side vulnerability. Initial response within 1 hour of confirmation, 24×7. Customer notification within 72 hours of confirmation, in line with European Union General Data Protection Regulation (GDPR) Article 33 obligations — faster where the customer’s contract or applicable law requires.
• Severity 2. Service degradation affecting a customer’s ability to use the platform; a confirmed vulnerability not yet exploited. Initial response within 4 hours during business hours. Customer notification within 5 business days.
• Severity 3. Functional defect without security impact. Tracked, prioritized, and disclosed in release notes.

Post-incident review. For every Severity 1 and Severity 2 incident, we produce a written post-incident review covering the root cause, the impact, the mitigation, and the corrective actions taken. Reviews are shared with affected customers; where appropriate, redacted reviews are published.

Honesty about stage. Citorum is a small and early company. The on-call rotation has the people on it that you would expect a small and early company to have. We do not claim a 24×7 N-tier support organization we do not have. What we do claim is that the people on call are the people who built the runtime; the time from page to root-cause hypothesis is short.

10. Vulnerability management & coordinated disclosure

10.1 Internal vulnerability management

Source code is scanned by Static Application Security Testing (SAST) tooling on every pull request. Dependencies are scanned for known vulnerabilities (Common Vulnerabilities and Exposures, CVEs) on every build and continuously thereafter; advisories are reviewed within one business day and patched within the windows defined by severity. Container images are signed and the signing chain is verifiable at deployment time. Dynamic Application Security Testing (DAST) is run against staging environments on each release candidate.

10.2 Coordinated disclosure policy

We welcome reports from external security researchers. Reports should be sent to [email protected]. The same address is published in our /.well-known/security.txt file per Request for Comments (RFC) 9116.

Our commitments to researchers acting under this policy:

• Acknowledgment. We will acknowledge the receipt of a good-faith report within five business days, with an identifier the researcher can reference.
• Safe harbor. Good-faith security research conducted under the conditions below will not be referred to law enforcement, will not result in legal action by Citorum, and will not result in a complaint to the researcher’s employer.
• Public credit. Researchers who report a confirmed vulnerability and wish to be acknowledged publicly will be credited on the Citorum security page (or in another mutually-agreed venue) after the issue is fixed and disclosed.
• Coordinated timing. We commit to working with the researcher on a coordinated disclosure timeline. The default window is 90 days from confirmed receipt to public disclosure; extensions are negotiated where required by complexity.

Conditions for safe harbor— research is in good faith and falls within the policy if it:

• does not access, modify, or delete data belonging to any party other than the researcher (no testing against production customer environments);
• does not disrupt service availability for other users;
• does not employ social-engineering, physical, or denial-of-service techniques;
• does not retain, share, or publish customer data inadvertently encountered;
• gives Citorum a reasonable opportunity to respond before any public disclosure, and works with us on a coordinated timeline.

No paid bug-bounty. Citorum does not currently operate a monetary bounty program. We may add one at a later stage; until then, this policy provides the legal and procedural safety researchers need without the bounty economics that require a paid program to manage well.

11. Sub-processors & supply chain

11.1 What counts as a sub-processor

A sub-processor is a third party that processes customer personal data on Citorum’s behalf. Required disclosure under GDPR Article 28 and under most enterprise Data Processing Agreements (DPAs). For customer-deployed runtimes (Topologies I and II), Citorum has no sub-processors with access to customer data— the runtime is operated by the customer, in their infrastructure, under their key control. This is a deliberate property of those deployment shapes.

11.2 Sub-processors for Topology III (Citorum-managed)

For Citorum-managed deployments, the current sub-processor list is:

Notification of changes. Customers under a signed DPA are notified in advance of any addition, removal, or change of role for a sub-processor. The notice period is set in the DPA and defaults to thirty days.

11.3 Supply-chain integrity

Container images shipped to customer deployments are signed using Sigstore tooling and the signing chain is verifiable at deployment time. A Software Bill of Materials (SBOM) is generated on each release in CycloneDX format and made available on request under NDA. Build provenance follows the Supply-chain Levels for Software Artifacts (SLSA) framework; the current attainment level is documented in the NDA-gated controls inventory.

12. Compliance posture

Citorum is pre-audit. We have not completed a SOC 2 Type I or Type II audit. We do not hold ISO 27001 certification. We treat this as a fixable gap on a stated trajectory, not a permanent posture — but we have not yet funded the formal audit program, and we will not publish a target date we are not confident we will hit.

What we offer in the interim:

• This whitepaper, in full and unredacted form.
• A filled CAIQ Lite and SIG Lite under NDA, mapped to the sections of this document — useful as a starting point for the customer’s internal vendor-risk questionnaire.
• Direct architect-to-architect engagement: a conversation with the engineering team that built the runtime, not with a sales engineer who has memorized a security one-pager.
• The full controls inventory under NDA, going further on tuning, thresholds, runbooks, and per-signal weight tables than this public document.

Internal controls already in place, notwithstanding the absence of formal certification:

• Multi-factor authentication (MFA) is required for every team member on every internal tool that touches production. There is no exception for engineers, none for executives, and none for break-glass.
• Single Sign-On (SSO) through the company IdP for every internal tool that supports it. Tools that do not are reviewed and either replaced or wrapped behind an SSO-fronting proxy.
• Annual access reviews of every production-touching role, with role removals applied within the review cycle.
• Background checks for any hire with production access, conducted before the hire’s access is provisioned.
• Endpoint management with mandatory disk encryption (FileVault on macOS, BitLocker on Windows, LUKS on Linux); endpoints that fall out of compliance are quarantined.
• Separation of duties for production deployments: the engineer who writes the change is not the engineer who approves and releases it.
• Secrets held in a managed vault, never committed to source repositories. Repository scanning blocks accidental secret commits at the pull-request layer.

Applicability statements for regulated regimes:

• HIPAA. Citorum is suitable for use under a Business Associate Agreement (BAA) when deployed in Topology I or II, where Protected Health Information (PHI) never leaves the customer’s infrastructure. Topology III BAA availability is under construction; ask sales.
• GDPR. The customer is the controller; Citorum, for Topology III only, is the processor. For Topologies I and II, there is no processor relationship to disclose. DPAs are available for Topology III.
• SOX / PCAOB. Audit log retention defaults exceed the seven-year SOX retention requirement; configurations supporting longer holds are available.
• PCI DSS. Field-level encryption (Section 5) is the recommended mechanism for cardholder-data fields where Citorum is deployed in a corpus containing them. We are not, ourselves, a payment processor.
• FedRAMP. Citorum is not currently in the FedRAMP marketplace. Deployments to federal customers are typically via Topology I or II with the customer’s existing FedRAMP-authorized hosting environment.

13. Framework crosswalk

For security teams pre-filling a vendor questionnaire, the following crosswalk maps the standard CAIQ Lite and SIG Lite control families to the sections of this document where they are addressed. The complete questionnaire responses are available under NDA.

Citorum is a doing-business-as (DBA) of Shiva AI Corp, a Colorado corporation. This document is Revision 1, published May 14, 2026. Future revisions will be tagged by date and linked from this URL.