How to Secure High-Risk AI Models and Systems

This section offers practical, actionable security controls for high-risk AI systems. It is divided into two parts:

Baseline Controls

These are the foundational protections that apply to all AI systems, regardless of architecture, deployment model, or use case. They reflect the minimum safeguards necessary to reduce risk across any high-risk AI environment.

• Baseline controls are architecture-agnostic, meaning they are consistent no matter how the model is built or deployed.
• These serve as the default security expectations for any high-risk AI system.

Architecture-Specific Controls

After the baseline, this guide highlights only the additional controls needed for specific AI architectures (e.g., RAG, multimodal, scientific models, RL agents).

• These are modifiers, not replacements.
• They address risks unique to certain system designs without repeating the universal baseline controls.

Together, these two sections help teams apply a clear, consistent security foundation while tailoring protections to the unique risks posed by different AI system architectures.

Baseline Controls for High-Risk AI Systems

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Controlled model artifact access	Enforce strong identity management; restrict access to model artifacts with sensitive intellectual property, such as model weights, checkpoints, tokenizers, and hyper‑parameter configuration. Use role separation for training, deployment, and operations.	Prevents insider misuse, model tampering, and unauthorized extraction.	IAM policies, RBAC, privileged access management.
Multiparty governance for sensitive actions	Require quorum‑based or multiparty authorization for model release, reconfiguration, fine‑tuning, or deployment of high‑capability modes.	Reduces unilateral insider actions; adds accountability for sensitive model changes.	Two‑person integrity (TPI), approval workflows.
Protected weight storage and serving	Store and serve weights in hardened or confidential‑computing environments; attest the environment before model load.	Prevents offline theft, tampering, or parameter extraction.	Hardware‑backed enclaves, attestation protocols, encrypted storage.

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Training and fine-tuning data integrity	Verify provenance of training and fine-tuning datasets; detect poisoning, tampering, or contamination.	Prevents embedding harmful knowledge, bias, or backdoors.	Dataset signing, hashing, secure ingestion pipelines.
Dataset hazard screening	Apply baseline hazard classification for regulated, dual-use, or dangerous content before ingesting into training or fine-tuning pipelines.	Prevents embedding technical knowledge that could be weaponized.	Data curation policies, hazard scanners.
Input validation and sanitization	Validate or sanitize user inputs and external data sources to reduce injection and malformed content.	Reduces manipulation and improves system robustness.	Content filters, schema validation, untrusted input pipelines.

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Sandboxed model execution	Run models in isolated, sandboxed environments with strong boundaries between components.	Reduces damage if an exploit succeeds or unsafe output triggers harmful actions.	Namespaces, container isolation, virtual machines (VMs), secure enclaves.
Default-deny tool and egress policies	Restrict external calls, tools, and network egress by default; allow only necessary actions.	Limits misuse and reduces the impact of prompt bypass or compromise.	Firewall policies, tool permission lists, geofencing.
Secure deployment surface	Harden runtime environments, model-serving endpoints, and orchestration layers.	Reduces exploitation risk and constrains lateral movement.	Container hardening, dependency scanning, CI/CD security.

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Comprehensive logging	Log access, prompts, outputs, tool calls, and system actions at appropriate fidelity.	Enables investigation, incident response, and misuse detection.	Centralized logging, security information and event management (SIEM) integration.
Behavioral and safety monitoring	Detect anomalous behavior, misuse indicators, or capability drift.	Identifies early signs of unsafe behavior or attacks.	Safety signal monitoring, behavioral baselines.
Auditability and traceability	Maintain audit trails for model versions, deployments, and significant configuration changes.	Ensures accountability and governance.	Version control, change management systems.

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Output validation and filtering	Apply output filters, validation layers, or safety checks to detect harmful, incorrect, or high-risk outputs.	Prevents harmful content from reaching users or downstream systems.	Safety models, rule-based filters, plausibility checks.
Domain-specific post-processing	Add domain-specific validation for safety-critical or regulated environments.	Reduces risk of hallucinations or unsafe instructions.	Human review, external validators, cross-checks.

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Model and dependency integrity	Validate model weights, code, datasets, and dependencies via signatures or checksums.	Protects against tampering or compromised components.	Artifact signing, software bill of materials (SBOM), dependency scanning.
Secure CI/CD and build pipelines	Enforce secure build-and-release processes with integrity checks and attestation.	Prevents supply chain compromise from affecting deployed models.	Build isolation, reproducible builds.

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Knowledge-hazard evaluation	Assess models for sensitive, dual-use, or operationally dangerous latent knowledge.	Identifies potential weaponizable outputs before deployment.	Hazard benchmarks, sensitive capability evaluations.
Misuse-resilience testing	Conduct red-team testing using adversarial prompts, multistep attacks, and bypass attempts.	Detects vulnerabilities missed by standard testing.	AI red-teaming, automated stress-testing.
Capability and drift monitoring	Reevaluate periodically for regression or new capabilities.	Prevents “quiet drift” toward unsafe behavior.	Scheduled evaluations, capability baselines.

Subcategory	Enhanced Baseline Requirement	Why This Matters	Implementation Anchors
Model classification and escalation	Classify models by risk and define governance thresholds where additional controls apply.	Ensures that governance follows capability, not format.	Risk scoring, model registry.
AI-specific incident response	Maintain incident response plans tailored to model misuse, harmful outputs, or compromise.	Enables rapid containment and recovery.	Incident response runbooks, kill switches, rollback mechanisms.
Lifecycle review	Conduct structured reviews at training, deployment, and significant model changes.	Ensures oversight throughout the lifecycle.	Change control boards, formal approval gates.

Although these baseline controls apply to all high-risk AI systems, certain architectures introduce additional risks or implementation challenges. The next section highlights only those architecture-specific controls—focused on the deltas that extend or strengthen the baseline.

Architecture-Driven Control Modifiers

The architecture-driven control modifier tables below—Model Layer Modifiers and System Layer Modifiers—identify where specific AI architectures require additions or adjustments to the baseline controls. These modifiers apply when an architecture introduces risks, behaviors, or dependencies that the baseline does not fully capture. Each table maps six types of AI architectures across relevant control categories, showing how each architecture affects security requirements at the model layer and the system layer.

The following matrix outlines architecture-driven modifications to the baseline controls. These adjustments apply when an AI system’s architecture changes how inputs, outputs, or model artifacts should be protected.

Control Category	RAG	Open-Weight/Self-Hosted	API-Based Models	Scientific/Domain-Specific	RL/Agentic Systems	Multimodal
Access control and weight protection	None beyond baseline.	Protect weight artifacts; enforce signing and provenance verification.	Tight API key governance; rate-limiting; credential isolation.	Gate access based on capability risk.	Restrict tool permissions; enforce step-level approvals.	Restrict access to sensitive sensor inputs.
Data integrity and input validation	Validate retrieved documents; secure vector database; detect indirect injection.	Validate fine-tuning datasets; verify community data provenance.	Enforce strict schemas and filtering pre-API.	Validate scientific inputs; screen for hazardous parameters.	Validate environment state; verify tool outputs.	Defend against adversarial images or audio; validate sensors.
Output handling and safety validation	Validate citations and retrieval consistency.	Run post-finetuning regression checks.	Validate API outputs for schema correctness.	Perform scientific plausibility checks.	Action-level validation; gate external actions.	Validate outputs from sensor-derived decisions.
Evaluation and red-teaming	Test retrieval manipulation and indirect injection.	Red-team for weight manipulation or backdooring.	Test provider behavior across versions.	Domain-expert hazard evaluations.	Reward hacking, multistep jailbreak, autonomy tests.	Test adversarial images or audio.

Even when two AI systems use a similar underlying model, their system-level risk profiles can differ significantly based on how they retrieve data, interface with tools, integrate external components, or interact with real-world environments.

The following controls outline system-layer security controls that become necessary because of the architecture used—that is, the security implications for the infrastructure, execution environment, and operational pipeline surrounding the AI system.

Control Category	RAG	Open-Weight/Self-Hosted	API-Based Models	Scientific/Domain-Specific	RL/Agentic Systems	Multimodal
Environment isolation and execution controls	Harden vector stores; isolate retrieval pipeline.	Serve weights in enclaves; segment environments.	Ensure strong tenant isolation.	Sandbox external scientific tools.	Strict sandboxing for tool-use; constrain loops.	Harden preprocessing pipelines; isolate ingestion paths.
Monitoring, logging and anomaly detection	Log retrieval queries and document hashes.	Monitor weight access and export attempts.	Monitor API traffic and key misuse.	Monitor anomalous scientific outputs.	Log actions, rewards, tool calls; detect reward hacking.	Monitor sensor anomalies or adversarial noise.
Supply chain security and provenance	Validate embedding or index integrity.	Verify weight provenance; signature checks.	Assess provider security attestations.	Validate scientific datasets and tool provenance.	Validate external toolchains and evaluators.	Validate sensor firmware or hardware integrity.
Governance and incident response	Manage allowlists for retrieval sources.	Weight-handling governance and distribution controls.	Define escalation paths for provider failures.	Domain-expert escalation for hazardous outputs.	Maintain kill switches and oversight protocols.	Governance for sensitive sensor data handling.