← Domains & pillars

SecurityView domain

APRF-01

Adversarial Security

Prevent prompt injection, jailbreaks, exfiltration, and model/tool abuse from becoming a production incident.

Purpose

Establish controls that prevent adversarial misuse of models, prompts, tools, and outputs from compromising confidentiality, integrity, or availability—distinct from content-safety and responsible-AI harms covered in the Safety domain.

Mandatory checks

Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.

  • SEC-M1L3 · DefinedTier 2 · ProductionhybridE3

    Untrusted input (including model-generated text) shall never authorize privileged tool or side-effect actions without server-side policy—so prompt injection and privilege escalation cannot bypass the control plane.

    Artifact
    Server-side policy mediating privileged tool/actions (not prompt-only) + Versioned injection/privilege-escalation corpus + CI gate report + Policy-engine deny sample logs or harness results (denyRatePct + modelTextPrivilegeGrants)
    Pass condition
    ≥95% of corpus cases that attempt privilege escalation via untrusted input are denied; 0 cases where model text alone granted a privileged tool call in the suite (measuredAt ≤90 days). If production AI cannot invoke tools or privileged side effects, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Prevent untrusted model input from being treated as an authorization decision for privileged actions.

    Threats mitigated

    Prompt InjectionPrivilege EscalationExcessive AgencyUnauthorized Tool Use

    Protects

    RuntimeToolsExternal SystemsIdentity

    MITRE: ATLAS AML.T0051 · ATLAS AML.T0051.000 · ATLAS AML.T0051.001 · ATLAS AML.T0054 · ATLAS AML.T0053

    Direct and indirect prompt injection only produces impact when model output is trusted to authorize a privileged operation. Enforcing authorization server-side, independently of the model, removes the injected instruction's path to a privileged effect, and contains jailbreaks for the same reason.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

  • SEC-M2L3 · DefinedTier 2 · ProductionhybridE3

    High-risk model outputs shall be schema-validated or policy-filtered before any write, irreversible, or financial side effect—so non-conforming output cannot drive privileged downstream actions.

    Artifact
    Coverage inventory of high-risk side-effect paths (write/irreversible/financial) + Schema or policy filter definitions applied before those side effects + Contract test results showing non-conforming output rejected on 100% of inventoried paths
    Pass condition
    100% of high-risk side-effect paths (impact tier write/irreversible/financial) reject non-conforming model output in contract tests; coverage inventory lists every such path (measuredAt ≤90 days). If production AI cannot drive write, irreversible, or financial side effects, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Ensure model output cannot cause side effects until it has been validated against an explicit schema or policy.

    Threats mitigated

    Prompt InjectionUnsafe Code ExecutionHallucinated ActionsTool AbuseHarmful Content Generation

    Protects

    RuntimeExternal SystemsDataUsersSafety

    MITRE: ATLAS AML.T0051.001 · ATLAS AML.T0067 · ATLAS AML.T0077 · ATLAS AML.T0102 · ATLAS AML.T0050 · ATT&CK T1059

    Schema validation and policy filtering break the link between manipulated model output and the downstream executor that acts on it. This blunts rendering and trusted-output-component manipulation, and prevents generated malicious commands from reaching an interpreter unchecked.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

  • SEC-M3L3 · DefinedTier 2 · ProductionhybridE3

    Customer-facing releases shall run an abuse/jailbreak/injection security suite—with those case classes present—as a blocking gate, or record a time-boxed waiver (owner + expiry ≤30 days) when the gate does not pass.

    Artifact
    Abuse/jailbreak/injection suite definition covering those case classes + CI/release gate configuration that blocks promote on suite fail + Last 30 days of release reports showing gate=pass, or owned waivers (expiry ≤30 days)
    Pass condition
    100% of production releases in the last 30 days show an abuse/jailbreak/injection suite gate = pass (suite must include those case classes), or a time-boxed waiver with owner and expiry ≤30 days (measuredAt ≤90 days). If no customer-facing / production AI releases exist, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Prevent releases that regress the system's resistance to jailbreak, abuse, and injection.

    Threats mitigated

    Prompt InjectionJailbreakHarmful Content GenerationData Exfiltration

    Protects

    ModelsPromptsUsersSafety

    MITRE: ATLAS AML.T0051 · ATLAS AML.T0054 · ATLAS AML.T0043 · ATLAS AML.T0068

    Pre-release adversarial testing detects injection and jailbreak regressions before customers are exposed to them. Covering obfuscated and crafted adversarial inputs is what makes the gate meaningful rather than nominal. It is a release gate, not a runtime defence.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

  • SEC-M4L3 · DefinedTier 2 · ProductionhybridE3

    Network and identity boundaries shall prevent the model/tool runtime path from becoming a universal proxy to internal systems—so the model identity reaches only allowlisted destinations and has 0 unrestricted routes to internal admin APIs or data stores.

    Artifact
    Architecture diagram of model/tool trust boundaries + Network policy or egress allowlist export for the model/tool runtime identity + Automated or reviewed probe results (allowlisted-only reachability; unrestricted internal admin/data-store routes = 0)
    Pass condition
    Automated or reviewed probe shows the model/tool runtime can reach only allowlisted destinations; 0 unrestricted routes to internal admin APIs or data stores from the model identity (measuredAt ≤90 days). If no model or tool runtime can initiate network calls, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Prevent the model and agent path from becoming an unrestricted proxy into internal systems and networks.

    Threats mitigated

    Data ExfiltrationPrivilege EscalationPrompt InjectionTool Abuse

    Protects

    NetworkInfrastructureExternal SystemsAPIsData

    MITRE: ATLAS AML.T0025 · ATLAS AML.T0086 · ATLAS AML.T0072 · ATT&CK T1090 · ATT&CK T1041 · ATT&CK T1567

    Egress and identity boundaries constrain where a compromised model path can send data or open a connection. This directly limits exfiltration over cyber means and via agent tool invocation and denies reverse-shell callbacks. It bounds reach; it does not prevent the initial injection.

    Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

Evidence required

  • Threat model covering LLM-specific attack paths
  • Records of injection/jailbreak test suites and results
  • Architecture diagram showing trust boundaries around model and tools
  • Incident playbooks referencing AI-specific abuse scenarios
More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution

Engineering philosophy

Treat the model as an untrusted co-processor inside a zero-trust boundary. Security controls belong in the application and platform layers—never solely in prompt wording. Defense in depth spans input validation, output filtering, tool mediation, identity, and runtime isolation.

Why it matters

AI surfaces expand the attack surface: prompt injection, data exfiltration via tools, jailbreaks, model theft, and poisoned retrieval. A chatbot that 'mostly works' can still become an incident response event when an attacker turns natural language into a privileged API.

Common failures

  • Relying on system prompts alone to enforce security policy
  • Passing untrusted retrieval or user content into privileged tool contexts
  • Logging full prompts/completions that contain secrets or PII
  • No output schema enforcement—free-form text executes downstream logic
  • Missing abuse rate limits distinct from normal product quotas

Severity & risk

Severity
critical
Impact if violated
Risk level
critical
Typical residual risk (impact × likelihood)

Engineering best practices

  • Separate instruction channels from data channels; never concatenate untrusted data into system instructions without mediation
  • Apply least privilege to every tool and retrieval corpus the model can touch
  • Fail closed on policy violations; prefer refusal over silent degradation for security decisions
  • Version and review security policies the same way you review firewall rules

Automatic validations

  • CI security tests for known injection payloads against critical flows
  • Runtime policy engines rejecting disallowed tool calls
  • Schema validation on structured model outputs
  • Anomaly detection on tool-call volume and destination

Manual validations

  • Periodic adversarial review of new tools and prompts
  • Architecture review of trust boundaries before Level 3 launch
  • Tabletop exercises for data-exfiltration via the AI path

Examples

  • A support agent refuses to call refund APIs when the refund amount exceeds policy, regardless of user phrasing
  • RAG documents containing 'ignore previous instructions' cannot elevate privileges
  • MCP servers expose only scoped tools with server-side authorization independent of the model

References

Crosswalks

Show 31 peer mappingsexpand
  • Secure & Resilient Secure and Resilient

    NIST AI Risk Management Framework · aligns-with

  • Annex A AI system controls (selected themes)

    ISO/IEC 42001 · partial

  • LLM01 Prompt Injection

    OWASP Top 10 for Large Language Model Applications · supports

  • LLM05 Improper Output Handling

    OWASP Top 10 for Large Language Model Applications · supports

  • LLM07 System Prompt Leakage

    OWASP Top 10 for Large Language Model Applications · aligns-with

  • C2.1 Prompt Injection Defenses

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C2.2 Content & Policy Screening

    OWASP AI Application Security Verification Standard (AISVS) · partial

  • C5.1 Authentication

    OWASP AI Application Security Verification Standard (AISVS) · aligns-with

  • C7.1 Output Format Enforcement

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C7.2 Hallucination Detection & Mitigation

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C7.3 Output Safety

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C7.4 Source Attribution & Citation Integrity

    OWASP AI Application Security Verification Standard (AISVS) · aligns-with

  • C9.3 Component Isolation and Tool Authorization

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C10.1 Component Integrity

    OWASP AI Application Security Verification Standard (AISVS) · partial

  • C10.2 Authentication & Authorization

    OWASP AI Application Security Verification Standard (AISVS) · partial

  • C10.3 Secure Transport

    OWASP AI Application Security Verification Standard (AISVS) · partial

  • C10.4 Schema, Message, and Input Validation

    OWASP AI Application Security Verification Standard (AISVS) · partial

  • C11.1 Model Alignment, Safety, and Robustness Testing and Training

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C11.2 Membership-Inference and Model-Inversion Mitigation

    OWASP AI Application Security Verification Standard (AISVS) · partial

  • C11.3 Model-Extraction Defense

    OWASP AI Application Security Verification Standard (AISVS) · partial

  • C11.4 Model Runtime Anomaly Detection

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • CWE-22 Path Traversal

    OpenCRE (Open Common Requirements Enumeration) · partial

  • CWE-502 Deserialization of Untrusted Data

    OpenCRE (Open Common Requirements Enumeration) · partial

  • CWE-78 OS Command Injection

    OpenCRE (Open Common Requirements Enumeration) · aligns-with

  • CWE-79 Cross-site Scripting (XSS)

    OpenCRE (Open Common Requirements Enumeration) · partial

  • L1 Foundation Models

    CSA MAESTRO (Multi-Agentic Threat Model) · supports

  • L6 Security & Compliance

    CSA MAESTRO (Multi-Agentic Threat Model) · supports

  • emergent-covert-coordination Emergent Covert Coordination

    CSA MAESTRO (Multi-Agentic Threat Model) · aligns-with

  • heterogeneous-multi-agent-exploits Heterogeneous Multi-Agent Exploits

    CSA MAESTRO (Multi-Agentic Threat Model) · aligns-with

  • CC9 Risk Mitigation

    SOC 2 Trust Services Criteria · evidence-for

  • Security Security

    AWS Well-Architected Framework · aligns-with

Future evolution

Expect standardized machine-readable AI threat taxonomies, portable policy packs across providers, and attestation of model-path controls analogous to cloud security posture management.