> For the complete documentation index, see [llms.txt](https://calvin-lai.gitbook.io/calvin-lai-security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://calvin-lai.gitbook.io/calvin-lai-security/application-security/llm-model-section-criteria.md). # LLM Model Section Criteria **1 June 2026** **Document Purpose**: This guideline serves as a reference for AI developers, Data Scientists, and MLOps engineers. It outlines mandatory model selection, development practices, security controls, and deployment requirements to ensure compliance with corporate standards and **ISO/IEC DIS 27090:2025** (Cybersecurity — Artificial Intelligence — Guidance for addressing security threats and failures in AI systems). *** #### 1. Approved Model Scope (Target Models) * **Only lightweight open-source LLMs in the 1B to 8B parameter range** are permitted (e.g., quantized versions of Llama, Mistral, Gemma, Phi-3, etc.). * Larger models (>8B) or closed-source models require explicit approval from the Security and AI Governance teams. * Prefer models with strong community vetting, available model cards, and support for quantization (e.g., GGUF, 4-bit) to run efficiently on-prem. * **Reasons for Limiting Models to 1B–8B Parameters** * **Smaller attack surface**: Larger models (>8B) are significantly more complex, making them harder to fully audit, verify, and secure against threats such as model exfiltration, membership inference, model inversion, and data poisoning (ISO 27090 Clause 6). * **Reduced memorization risk**: Larger models tend to memorize training data more aggressively, increasing privacy risks (PII leakage via membership inference or inversion attacks). * **Easier air-gapped deployment**: Models in the 1B–8B range are more practical to run efficiently on limited on-premise hardware without compromising isolation or performance. * **Better guardrail effectiveness**: Smaller models are easier to control with external guardrails, schema enforcement, and HITL mechanisms. Larger models often require more resources and are more prone to instruction drift and prompt injection success. * **Supply chain & verification feasibility**: Smaller models are simpler to statically verify (hashes, signatures) and maintain full provenance through AIBOM. **SafeTensors and GGUF Format Requirement**: * Models **must be available in SafeTensors format** (for secure weight loading without pickle vulnerabilities) **and/or GGUF format** (for efficient quantization and CPU/GPU compatibility in air-gapped environments). * Prefer quantized versions (e.g., 4-bit, 5-bit, or 8-bit GGUF) to optimize performance while maintaining security. *** #### 2. Core Security & Deployment Requirements (Mandatory) * Must support **full air-gapped containerization** (e.g., Docker/Podman) in a dedicated internal subnet/VPC with **complete egress blocking** (zero outbound internet access). * **No runtime downloading** of model weights, dependencies, containers, or updates. * Models must be **statically verified** using cryptographic hashes (SHA-256 or stronger) and digital signatures before deployment. * Disable all telemetry, analytics, phone-home, and auto-update features at build time. **Air-Gapped Network Implementation Guidelines** True air-gapping is critical for high-security environments (aligned with ISO 27090 Zero Trust principles, Clause 5.2): * **Avoid sole reliance on Layer 2 VLANs** without ACLs — they can be bypassed via misconfiguration or lateral movement. * **Recommended Architecture**: * Deploy a **physical or next-generation firewall** between the core switch and the AI subnet with a **default-deny policy**. * Explicitly allow only necessary internal traffic (e.g., from approved management/jump hosts). * Implement strict ACLs, security groups, micro-segmentation, and host-based firewalls. * **True Air-Gap (for highest sensitivity)**: Physically disconnected systems with data transfer only via encrypted offline media (e.g., scanned USB/optical media with chain-of-custody). * Additional controls: Short-lived certificates, local package/container mirrors, FIPS-compliant configurations where required, and regular audits. * **Important**: Always collaborate with your organization’s Network Security/Infrastructure team. Implementation must be tailored to your specific IT environment, risk assessment, and compliance needs (e.g., defense, healthcare, or regulated industries). *** #### 3. Data Privacy & Protection Requirements (Mandatory)
CriterionPriorityWhat to Check
Training data contaminationCriticalDoes the model provider disclose training data sources? secrets removed?
Data retention policyCriticalWill your API inputs be stored or used for retraining? Can you delete session data?
On-premises / VPC deploymentHighCan the model be deployed in your own infrastructure (self-hosted or private cloud)?
GDPR / CCPA / HIPAA complianceHighDoes the model provider offer compliance certifications for your region/industry?
Air-gap deployment capabilityCriticalCan the model run completely offline (no internet) after download? Does the inference engine attempt any external call (telemetry, license check, update check)?
Model weight integrity & provenanceHighAre model weights checksum-verified? Can you verify they haven't been tampered with (e.g., SHA-256 hash from official source)? Is there a signed release?
*** #### 4. Output Quality & Reliability Requirements * Must support **strict schema enforcement** (e.g., Outlines, Guidance, JSON mode with grammar constraints). * Demonstrate strong resistance to hallucinations, instruction drift, and instability under high-volume workloads. * All outputs must route through external guardrails for validation and sanitization. *** #### 5. Security Threat Protection Requirements (Mandatory) * Strong resistance to **indirect prompt injection, jailbreaks, and evasion attacks** — perform regular adversarial testing. * **No plaintext PII** in logs, prompts, outputs, or storage — enforce full scrubbing/suppression. * Implement layered external guardrails: * Input pre-processing & sanitization * Output filtering, schema validation, and confidence thresholding * Rate limiting and anomaly detection **Supply Chain Security (AIBOM)**: Generate and maintain an AI Bill of Materials to track components, provenance, and risks throughout the lifecycle. *** #### 6. Human-in-the-Loop (HITL) Requirements (Mandatory) * Models must expose **log-probability / confidence scores** for tokens or outputs. * Validation UIs **must flag low-confidence outputs** (e.g., <95% threshold requires human review). * High-risk or safety-critical decisions require documented human oversight to mitigate overreliance. *** #### 7 . Final Approval Rule (Gate Criteria) A model or solution can only proceed to deployment if it satisfies **all** of the following: 1. Robust air-gapped deployment with verified network isolation (physical firewall or equivalent recommended). 2. Strong external guardrails + effective HITL mechanisms. 3. Documented mitigation of key ISO 27090 threats. 4. Full AIBOM and provenance records. 5. Formal approval by Information Security and AI Governance teams. *** **Daily Reminder**:\ Security, isolation, and deterministic behavior are non-negotiable. When in doubt — especially regarding network architecture, data handling, or supply chain — escalate to the Security team immediately. These criteria help reduce risks of data leakage, model compromise, and compliance gaps. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://calvin-lai.gitbook.io/calvin-lai-security/application-security/llm-model-section-criteria.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.