Detailed Security Controls Reference

This section provides detailed, implementation-level security controls for high-risk AI systems.

While earlier sections introduced baseline controls and architecture-specific modifiers, this reference organizes controls by security domain and maps each one to the threats it mitigates. The goal is to help practitioners quickly identify which controls matter most for their system—and why.

High-risk AI systems face a set of recurring failure modes that can be exploited or triggered across different architectures. To make these risks easier to understand and prioritize, this guide aligns threats with the OWASP Top 10 for LLM Applications and assigns them a priority level based on potential consequence:

• HIGH: Could cause rapid, irreversible, or severe harm
• MOD-HIGH: Significant impact or escalation risk if unmitigated
• MED: Important weaknesses that may enable higher-impact failures

Note: Although many of the OWASP Top 10 security controls are phased in LLM language (including the title), these controls also apply to non-text-based systems. Even though the examples that OWASP provides are LLM-focused, the security controls are architecture-agnostic and therefore generalizable to any AI system.

The table below introduces these threat categories, their mapped OWASP identifiers, the recommended control categories, and the consequences of failing to address them. These mappings help you navigate the detailed control tables that follow—each of which expands on the specific mitigations, implementation anchors, and threat mappings for every domain.

Threat (Ordered by Consequence)	Recommended Security Controls	Mapped Control Category	Priority (Consequence if Ignored)
Transitive prompt injection (OWASP LLM01, LLM07)	Sanitize or canonicalize retrieved content; block tool calls from untrusted retrievals.	Content safety and prompt injection defense; toolchain isolation and sandboxing.	HIGH: Model executes unintended logic or harmful actions from manipulated retrieval content.
Toolchain hijacking (OWASP LLM08, LLM09)	Run tools in micro virtual machines or secure runtimes; least-privilege tool identities; strict egress allowlists.	Toolchain isolation and sandboxing; access and auditing.	HIGH: Unauthorized real-world actions (file deletion, system modification, data exfiltration).
Plugin or agent escalation (OWASP LLM08, LLM06)	Step limits; execution budgets; human approval gates for high-impact actions.	Agent governance and autonomy constraints.	HIGH: Irreversible or out-of-policy multistep agent actions.
Implicit trust between components (OWASP LLM10, LLM09)	Schema, signature, or provenance checks; end-to-end deny-by-default authorization.	Intercomponent trust validation; access control.	MOD-HIGH: Poisoned or injected data propagates silently across layers.
State leakage or memory replay (OWASP LLM06, LLM07)	Limit or time-bound memory; encrypt/redact logs; restrict tool access to state.	Memory and state management; access and auditing.	MOD-HIGH: Sensitive data or dangerous queries leak or replay across sessions.
Access escalation via integration (OWASP LLM04, LLM09)	End-to-end least-privilege authorization; deny-by-default connectors; restrict shell or operating system (OS) tools.	Access control; toolchain isolation.	MOD-HIGH: Privilege escalation through integrated components.
Cross-system entanglement (OWASP LLM03, LLM10)	Output validation before triggers; circuit breakers; idempotent APIs.	Deployment safeguards.	MOD: Cascading failures and difficult-to-diagnose incidents.
Boundary erosion (OWASP LLM02, LLM05)	Network segmentation; per-tool identities; read-only file systems.	Intercomponent trust validation; deployment safeguards.	MOD: Data leakage or unintended execution from blurred boundaries.
Version drift or tool mismatch (OWASP LLM10)	Pinned versions; SBOMs; signed artifacts; automated alerts.	Supply chain security; deployment safeguards.	MOD: Silent breakage, bypassed checks, or unexpected new attack paths.

The tables that follow break these control categories into detailed, implementation-level guidance. Each table contains the relevant control subcategories, their practical descriptions, mapped threats and priority levels, and key implementation anchors. Use these tables to identify the specific safeguards required for your system’s architecture and threat profile.

Subcategory	Description	Mapped Threat(s)	Why High Priority	Implementation Anchors
End-to-end authorization (deny by default)	Enforce authorization at every hop (model → orchestrator → tools → data stores); identity and context propagate end to end; connectors fail closed.	Access escalation; boundary erosion; implicit trust.	Reduces privilege escalation across components and limits lateral movement if upstream controls fail.	Service mesh with mutual Transport Layer Security (mTLS), signed requests, zero-trust segmentation.
Quorum-based release or conditional instantiation	Require multiparty approval for modifying, releasing, or activating high-capability models.	Insider misuse; uncontrolled proliferation.	Prevents unauthorized changes or deployments of sensitive models.	Dual control approval, secure enclaves, privileged workflows.
Confidential computing for weights	Store and serve weights inside attested enclaves with encrypted memory.	Weight extraction; model tampering.	Blocks parameter theft and protects integrity even under infrastructure compromise.	Trusted execution environments (TEEs), remote attestation, encrypted memory.
Weight access governance	Restrict access to checkpoints, weight files, fine-tuned variants, and training artifacts.	Unauthorized access; model leakage.	Weights are intellectual property and capability vectors; strict control is required.	RBAC/ABAC (attribute-based access control), audit logs, tiered access.

Subcategory	Description	Mapped Threat(s)	Why High Priority	Implementation Anchors
Toolchain isolation and sandboxing	Isolate downstream tools and enforce strict sandboxing to prevent misuse via integrated toolchains.	Toolchain hijacking; agent escalation.	Prevents harmful real-world actions triggered by manipulated output.	Namespaces, VM isolation, secure computing (seccomp), egress restrictions.
Geofenced, sandboxed inference	Restrict where models run and what they can call; require default-deny egress.	Unauthorized access; remote misuse.	Contains harm even if prompt safety is bypassed.	Runtime policies, egress control, tenant isolation.
Agent governance and autonomy constraints	Limit agent loop depth, restrict autonomy, require human approval for high-impact actions.	Agent escalation; multistep compounding harms.	Multistep agents can combine capabilities and cause emergent risk.	Human-in-the-loop (HITL) gates, loop limits, execution caps.
Plugin capability gating	Fine-grained permissions for tools; prohibit unsafe tool combinations.	Toolchain hijacking; integration escalation.	Minimizes blast radius by limiting what a single tool or plugin can perform.	Per-tool allowlists, policy routing, scoped sandboxes.

Subcategory	Description	Mapped Threat(s)	Why High Priority	Implementation Anchors
Dataset hazard classification	Screen training data for dual-use or regulated content; track provenance.	Knowledge hazards.	Prevents dangerous capability acquisition during training.	Dataset versioning, hazard taxonomies, checksums.
Data provenance and retrieval controls (for RAG)	Track origin and trustworthiness of retrieved documents; apply scoring or allowlists.	Transitive prompt injection.	Ensures that manipulated external content cannot control model behavior.	Hashing, trust filters, source verification.
Supply chain security for tools and plugins	Integrity-check tools, plugins, retrievers, and downstream dependencies.	Backdoors; version drift; toolchain hijacking.	Tools expand the attack surface; provenance prevents injected vulnerabilities.	Supply-chain levels for software artifacts (SLSA) provenance, signed packages, dependency scanning.

Subcategory	Description	Mapped Threat(s)	Why High Priority	Implementation Anchors
Prompt injection and content filtering	Filter and sanitize inputs and outputs; block dual-use prompts and unsafe completions.	Indirect prompt injection; policy bypass.	Provides final-line defense when prompt-level or tool-level bypasses occur.	Semantic filters, moderated models, allow/deny rules.
Memory and state management controls	Limit, encrypt, or disable persistent memory; periodically audit stored content.	State leakage; replay; persistence of unsafe data.	Long-term memory multiplies risk by reusing sensitive or harmful data.	Memory time to live (TTL), encrypted logs, purge processes.

Subcategory	Description	Mapped Threat(s)	Why High Priority	Implementation Anchors
Knowledge hazard evaluation	Identify dangerous latent capabilities (e.g., chemical/biological synthesis paths).	Biological or chemical misuse; emergent harm.	Prevents accidental release of harmful, irreversible outputs.	Domain expert evaluations, hazard scenario testing.
AI‑assisted red‑teaming	Probe for misuse pathways and dual‑use capabilities using combined human and AI techniques.	Emergent capabilities; jailbreaks.	High‑capability models may hide risky behavior until adversarially probed.	Automated prompting, scenario generation.

Subcategory	Description	Mapped Threat(s)	Why High Priority	Implementation Anchors
Misuse‑resilience testing	Adversarial evaluation at multiple lifecycle stages; review for harmful capabilities.	All composite threats.	Ensures that governance reacts to capability, not only model type or size.	Lifecycle checkpoints, periodic audits.
Model classification and escalation protocols	Label high‑risk systems and define clear slow/stop deployment conditions.	Unknown unknowns; hazard escalation.	Provides a safety brake when new capabilities emerge unexpectedly.	Capability thresholds, escalation playbooks.

The controls outlined in this section provide a robust set of safeguards tailored to the unique risks associated with high-risk AI systems. Although not every control applies equally across all architectures or deployment contexts, together they represent a coherent, defense-in-depth strategy that reduces the likelihood and impact of misuse, emergent model behavior, or system-level exploitation. By implementing baseline protections, applying architecture-specific modifiers, and using the detailed controls library as a reference, organizations can build resilient, well-governed AI systems capable of operating safely in sensitive or high-impact environments.

In conclusion, it can be helpful to clarify how security expectations shift once a system is considered high risk.

• Many of the control categories—such as access control, sandboxing, monitoring, and supply chain security—exist in ordinary AI deployments, but high-risk systems require stronger, more granular and more verifiable versions of those same protections.
• This means adding such measures as multiparty approval for weight changes, knowledge-hazard filtering instead of only toxicity filtering, sandboxing with default-deny egress, provenance checks that include hazard screening, and capability-aware evaluations rather than purely accuracy-based testing.

Put another way, high-risk systems do not introduce entirely new families of controls—they elevate the rigor and depth of existing ones to match the consequences of failure.

Key Takeaways

Layered safeguards ensure that security scales with risk, providing baseline defenses for every system, integrated protections for composite deployments, and enhanced security measures for high-capability, high-risk, or dual-use environments.