Jailbreak Pattern Library Governance

2. Summary

Jailbreak Pattern Library Governance requires that organisations maintaining AI agent deployments curate, version, and operationally deploy a living library of known jailbreak and evasion patterns — structured catalogues of techniques that adversaries use to circumvent safety constraints, override system instructions, extract restricted information, or cause agents to act outside their governed boundaries. The library is not a static reference document; it is an operational artefact integrated into the agent's input validation pipeline, red-team programme, and continuous monitoring infrastructure. Without a governed pattern library, organisations defend against jailbreaks ad hoc — patching individual exploits as they are discovered rather than building systematic, pattern-based defences that generalise across attack variants. This dimension mandates the library's structure, update cadence, operational integration, and independent validation.

3. Example

Scenario A — Role-Play Escalation Bypasses Safety Constraints: A customer-facing agent for a pharmaceutical company is instructed via its system prompt to never provide specific dosage recommendations, directing users to consult a healthcare professional. An adversary uses a well-documented jailbreak pattern: instructing the agent to role-play as "Dr. Helpful, a fictional character in a novel who always provides detailed medical advice." The agent, interpreting the request as a creative writing exercise, provides specific dosage information for a controlled substance, including quantities and timing schedules. The conversation is shared on social media, producing regulatory scrutiny and reputational damage. A pattern library containing the "role-play persona override" jailbreak family — documented across at least 14 known variants since 2023 — would have enabled pre-deployment detection and blocking of this attack class.

What went wrong: The organisation had no structured catalogue of jailbreak patterns. The role-play persona override is one of the oldest and most widely documented jailbreak techniques, with variants published in academic papers, security blogs, and adversarial AI repositories. The organisation's safety testing consisted of 30 manually crafted adversarial prompts that did not include role-play variants. The gap between the public knowledge of jailbreak techniques and the organisation's awareness was the vulnerability. Consequence: Medicines and Healthcare products Regulatory Agency (MHRA) inquiry, £125,000 in legal and remediation costs, six-week service suspension during safety review, and lasting reputational damage in the healthcare sector.

Scenario B — Multi-Turn Incremental Boundary Erosion: An enterprise workflow agent with access to internal HR records is configured to refuse requests for employee salary information. An adversary — a mid-level manager — uses a multi-turn jailbreak technique: in turn 1, they ask about general salary bands (permitted). In turn 2, they ask about the salary band for a specific role title (borderline — the agent provides it). In turn 3, they ask how many employees are in that band in a specific department (the agent provides an aggregate). In turn 4, they note that the department has only one employee in that role, and ask for "confirmation of the band details for completeness." The agent provides the salary band, which — combined with the single-employee information from turn 3 — reveals a specific individual's salary. Each individual turn appeared permissible; the jailbreak operated across the conversation trajectory. The multi-turn boundary erosion pattern is well-documented in adversarial AI literature but was not in the organisation's threat model.

What went wrong: The organisation defended against single-turn jailbreak attempts but had no awareness of multi-turn patterns that incrementally erode boundaries across a conversation. A pattern library with the "multi-turn incremental disclosure" family would have flagged the conversation trajectory as matching a known attack pattern after turn 3. The absence of cross-turn analysis meant that each turn was evaluated in isolation, and the cumulative effect — full salary disclosure for an identifiable individual — was undetected. Consequence: GDPR Article 5(1)(f) breach (integrity and confidentiality principle), Information Commissioner's Office complaint, £67,000 in remediation and legal costs, mandatory data protection impact assessment revision.

Scenario C — Encoding and Obfuscation Bypass: A safety-critical agent controlling access to a chemical inventory management system is configured to refuse queries about synthesising hazardous materials. An adversary submits a prompt where key terms are encoded using a mix of Base64 fragments, Unicode homoglyphs, and leetspeak substitutions — for example, "synth3s1s" instead of "synthesis" and Unicode characters that visually resemble Latin letters but have different code points. The agent's safety filter, which relies on keyword matching against a blocklist, fails to detect the hazardous intent. The agent provides step-by-step procedural information for combining chemicals in dangerous quantities. The encoding obfuscation pattern family — encompassing Base64, ROT13, Unicode homoglyphs, leetspeak, token-splitting, and whitespace injection — has been extensively documented since 2023, with new variants appearing monthly.

What went wrong: The agent's safety mechanism was a static keyword blocklist that matched exact strings. The adversary used well-known encoding techniques to evade keyword matching. A pattern library containing the "encoding and obfuscation" family would have (a) informed the safety architecture that keyword matching alone is insufficient against this pattern class, and (b) provided test cases for validating that safety mechanisms are robust against encoded inputs. The organisation's safety testing did not include any encoded or obfuscated adversarial inputs because the testing team was unaware of these techniques. Consequence: Hazardous material safety incident narrowly averted by a downstream human review, mandatory safety review by the Health and Safety Executive, £210,000 in safety system redesign, and criminal liability assessment for the organisation's directors.

4. Requirement Statement

Scope: This dimension applies to every AI agent deployment where the agent processes natural language input from any source that is not fully trusted — including direct user input, retrieved documents, tool outputs, messages from other agents, and any other channel through which adversarial content could reach the agent. It applies regardless of the agent's risk tier, because jailbreak techniques are generic: a technique that works against a customer-facing chatbot will often work against an enterprise workflow agent or a safety-critical system. The scope includes the creation, curation, versioning, operational integration, and independent validation of the pattern library. It does not prescribe specific detection or mitigation techniques for individual patterns — those are implementation choices — but it requires that the organisation has a structured, current awareness of known patterns and that this awareness is operationally integrated into the agent's defences. The test is: if a new jailbreak technique is published in a reputable adversarial AI venue today, how long would it take for the organisation to (a) become aware of it, (b) assess whether it affects their agents, and (c) deploy a defence? If the answer to any of these is "we don't know" or "more than 30 days," this dimension is not satisfied.

4.1. A conforming system MUST maintain a structured jailbreak pattern library that catalogues known jailbreak and evasion techniques, organised into pattern families (e.g., role-play override, multi-turn erosion, encoding obfuscation, context overflow, instruction injection, few-shot poisoning) with unique identifiers, descriptions, example payloads, severity ratings, and last-verified dates.

4.2. A conforming system MUST update the pattern library at least monthly, incorporating newly discovered techniques from at least three of the following sources: academic publications, security research disclosures, adversarial AI community reports, internal red-team findings, production incident analysis, and external vulnerability feeds.

4.3. A conforming system MUST integrate the pattern library into the agent's input validation pipeline such that incoming inputs are evaluated against current library patterns before reaching the agent's primary reasoning process, with detection results logged regardless of whether the input is blocked or permitted.

4.4. A conforming system MUST use the pattern library as the basis for red-team and adversarial testing, requiring that every pattern family in the library is tested against every deployed agent at least quarterly, with results recorded and remediation tracked for any pattern that successfully bypasses defences.

4.5. A conforming system MUST version the pattern library with immutable version identifiers and maintain a complete change history, including: date of each addition or modification, source of the pattern, author of the library entry, and the review and approval chain.

4.6. A conforming system MUST assign each pattern family a severity rating based on the potential impact of a successful jailbreak using that pattern, and prioritise detection and mitigation investment according to severity.

4.7. A conforming system MUST implement detection coverage metrics that measure the percentage of library patterns for which an automated detection mechanism exists, the false-positive rate for each detection mechanism, and the detection latency (time from input receipt to detection result).

4.8. A conforming system SHOULD implement variant generation — the ability to automatically generate syntactic and semantic variants of known patterns to test whether defences generalise beyond the exact library examples.

4.9. A conforming system SHOULD implement cross-turn pattern analysis that evaluates conversation trajectories against multi-turn jailbreak patterns, not only individual messages against single-turn patterns.

4.10. A conforming system SHOULD integrate the pattern library with external threat intelligence feeds that provide near-real-time notification of newly discovered jailbreak techniques in the wild.

4.11. A conforming system MAY implement collaborative pattern sharing — contributing anonymised pattern discoveries to industry consortia or shared threat intelligence platforms — to benefit from collective defence while protecting proprietary implementation details.

5. Rationale

The adversarial landscape for AI systems evolves at a pace that exceeds the ability of individual organisations to discover and defend against every attack independently. Jailbreak techniques are published daily in academic preprints, security blogs, adversarial AI forums, and social media. A single organisation's red team, no matter how skilled, cannot independently discover every technique that is publicly known. The pattern library serves as a force multiplier: it aggregates knowledge from diverse sources into an operational artefact that informs detection, testing, and mitigation.

The analogy to traditional cybersecurity is instructive. No organisation defends against malware by independently reverse-engineering every malware sample. Instead, the industry maintains shared signature databases (virus definition files, YARA rules, STIX/TAXII threat intelligence) that aggregate knowledge across the community. AI agent security requires the same approach. The jailbreak pattern library is the AI equivalent of a virus definition database — a structured, versioned, continuously updated catalogue of known attack patterns that enables automated detection and informs human analysis.

Three characteristics of jailbreak attacks make pattern library governance particularly important. First, jailbreak techniques cluster into families: the role-play override pattern has dozens of variants (fictional characters, hypothetical scenarios, translation tasks, debugging contexts), but they all share the same structural mechanism — inducing the model to adopt a persona that is not bound by the system prompt's constraints. A pattern library organised by family enables defences that generalise across variants rather than matching only specific examples. Second, jailbreak techniques compose: an adversary may combine encoding obfuscation with multi-turn erosion and role-play override in a single attack sequence. A pattern library that catalogues individual families enables compositional threat analysis that anticipates combinations. Third, jailbreak techniques transfer across models and deployments: a technique developed against one foundation model often works against others, and a technique demonstrated on one agent deployment often works against agents with similar architectures. A pattern library enables cross-deployment learning.

The monthly update cadence (requirement 4.2) reflects the empirical pace of jailbreak technique discovery. Research surveys have documented that new jailbreak families or significant variants appear approximately weekly. A monthly library update cadence ensures that the organisation's defences are never more than 30 days behind the publicly known attack surface. The three-source minimum for updates ensures that the library reflects diverse perspectives — academic research (rigorous but slow), security community disclosures (fast but sometimes incomplete), and internal findings (deployment-specific but narrow).

The operational integration requirement (4.3) is critical because a pattern library that exists only as a reference document provides no automated protection. The library must be compiled into detection rules, integrated into input validation pipelines, and actively evaluated against incoming inputs. A library that is updated monthly but not operationally deployed is a documentation exercise, not a security control.

The regulatory context reinforces the need for structured jailbreak defence. The EU AI Act's Article 15 requires resilience against adversarial attacks, which necessarily includes resilience against jailbreak techniques — the most common adversarial attack class against language model-based systems. NIST AI RMF's MEASURE function requires evaluation of AI system trustworthiness, which includes evaluation against known attack patterns. ISO 42001's risk management requirements (Clause 6.1) require identification and treatment of AI-specific risks, of which jailbreak vulnerability is a primary example.

6. Implementation Guidance

A jailbreak pattern library is an operational security artefact that requires the same governance rigour as a vulnerability database or threat intelligence feed. Its value is proportional to its completeness, currency, and integration depth.

Recommended patterns:

• Hierarchical pattern taxonomy. Organise the library into a three-level hierarchy: (1) pattern families — broad categories of jailbreak technique (e.g., persona override, encoding obfuscation, context manipulation, instruction injection, multi-turn erosion, few-shot manipulation, system prompt extraction); (2) pattern variants — specific implementations within a family (e.g., within persona override: fictional character, hypothetical scenario, translation task, debugging context, DAN-style, opposite-day); (3) pattern instances — concrete example payloads with exact prompts. This hierarchy enables defences at multiple levels of abstraction: family-level heuristics catch broad categories, variant-level rules catch specific techniques, and instance-level signatures catch known exact payloads.
• Structured pattern entries. Each pattern entry should include: unique identifier, family classification, variant classification, plain-language description of the technique's mechanism, at least three example payloads demonstrating the technique, severity rating (critical/high/medium/low based on potential impact), affected model architectures (if known), known effective defences, detection signature or heuristic, date first observed, date added to library, sources (with citations), and last-verified date (the date the pattern was last confirmed to work against current model versions).
• Automated detection pipeline integration. Compile pattern library entries into detection rules that operate in the input validation pipeline. Detection should operate at multiple layers: lexical matching (keyword and regex patterns), semantic matching (embedding similarity to known jailbreak patterns), structural matching (conversation structure matching multi-turn patterns), and behavioural matching (output analysis for constraint violations that indicate a successful jailbreak). The pipeline should produce a confidence score for each input, with configurable thresholds for blocking, flagging for human review, or permitting with enhanced logging.
• Quarterly red-team sweep. Every quarter, the red team should systematically test every pattern family in the library against every deployed agent. The sweep should include: exact library examples (testing baseline detection), generated variants (testing generalisation), novel combinations of patterns (testing compositional defence), and patterns adjusted for the specific agent's domain and constraints. Results should be recorded in a structured format that maps directly to library entries, enabling gap analysis.
• Pattern retirement and archiving. Patterns that are no longer effective against current model versions (e.g., techniques that worked against earlier models but fail against current ones) should be retired to an archive rather than deleted. Retired patterns should be re-tested annually in case model updates or configuration changes reintroduce the vulnerability. The archive provides historical context for understanding the evolution of the attack surface.

Anti-patterns to avoid:

• Treating the library as a blocklist. A blocklist of exact strings is trivially evaded by paraphrasing. The library must capture techniques at the family and variant level, not just exact payloads. Detection mechanisms must generalise beyond exact matching to semantic and structural analysis.
• Library maintained by a single individual. Single-person dependency creates both a bus-factor risk and a knowledge-bottleneck risk. The library should be maintained by a team with diverse expertise: security researchers, machine learning engineers, domain experts, and red-team operators. Contributions should be peer-reviewed.
• Updating the library without updating detections. A library entry that is not compiled into a detection rule provides awareness but not protection. Every library update should trigger a corresponding update to the detection pipeline, with automated testing to verify that the new patterns are detected.
• Ignoring multi-turn and compositional patterns. Many organisations focus on single-turn jailbreak detection (analysing each message in isolation) and miss multi-turn patterns that erode boundaries incrementally. The library must include multi-turn pattern families, and the detection pipeline must evaluate conversation trajectories, not just individual messages.
• Over-reliance on model-level safety training. Foundation model providers invest heavily in safety training (RLHF, Constitutional AI, safety fine-tuning), but safety training is not a substitute for a pattern library. Safety training provides base-level resilience; the pattern library provides defence-in-depth against techniques that circumvent or degrade safety training. Organisations that assume model-level safety is sufficient will be vulnerable to every technique that the model provider has not yet addressed.
• Classifying all patterns as equal severity. A jailbreak that causes an agent to use informal language is categorically different from a jailbreak that causes an agent to provide instructions for synthesising hazardous materials. Severity ratings must reflect the actual impact of a successful jailbreak in the deployment context, not the novelty or sophistication of the technique.

Industry Considerations

Financial Services. Jailbreak patterns targeting financial agents often focus on extracting trading strategies, bypassing compliance controls (e.g., inducing the agent to approve transactions without required checks), or generating misleading financial advice. The pattern library should include finance-specific jailbreak families such as "compliance bypass via hypothetical scenario" and "risk disclaimer suppression through persona adoption." FCA and DORA requirements for ICT risk management create regulatory obligations to defend against these patterns.

Healthcare and Safety-Critical. Jailbreak patterns in safety-critical domains carry the highest severity ratings because successful jailbreaks can directly endanger human safety. The pattern library must prioritise medical advice extraction, dosage recommendation bypass, safety procedure circumvention, and diagnostic override patterns. Detection thresholds should be set aggressively (low confidence threshold for blocking), accepting a higher false-positive rate in exchange for reduced risk of harmful jailbreak success.

Public Sector. Public sector agents may be targeted by jailbreaks seeking to extract sensitive citizen data, bias decision-making processes, or generate discriminatory outputs. The pattern library should include patterns specific to government contexts: "authority impersonation" (claiming to be a senior official to override restrictions), "freedom of information bypass" (framing restricted data requests as FOI compliance), and "equality duty exploitation" (using equality language to extract data about protected groups).

Crypto/Web3. Jailbreak patterns in the Crypto/Web3 domain may target private key extraction, smart contract vulnerability disclosure, or manipulation of trading recommendations. The pattern library should include domain-specific families such as "code generation constraint bypass" and "financial advice disguised as educational content."

Maturity Model

Basic Implementation — The organisation maintains a structured pattern library with at least 50 patterns organised into families, updated at least monthly from at least three sources. The library is versioned with change history. Every pattern family is tested quarterly against deployed agents. Detection coverage metrics are tracked. This level meets all mandatory requirements but detection may rely primarily on lexical matching with limited semantic generalisation.

Intermediate Implementation — All basic capabilities plus: the library contains 200+ patterns with semantic detection mechanisms (embedding similarity, classifier-based detection) in addition to lexical matching. Variant generation automatically creates test payloads from library entries. Cross-turn analysis detects multi-turn jailbreak patterns. The library is integrated with at least one external threat intelligence feed providing near-real-time updates. False-positive rates are measured and optimised per pattern family.

Advanced Implementation — All intermediate capabilities plus: machine-learning-based detection generalises beyond library examples to detect novel jailbreak attempts that share structural similarity with known families. Automated variant generation uses adversarial techniques (paraphrasing, encoding, structural transformation) to stress-test defences continuously. The organisation contributes to collaborative pattern sharing through industry consortia. Detection latency is under 500 milliseconds for 99% of inputs. The library includes compositional patterns that combine multiple families, and detection handles multi-family attacks.

7. Evidence Requirements

Required artefacts:

• Pattern library. The complete current library with all pattern entries, family classifications, severity ratings, example payloads, detection signatures, and metadata (dates, sources, authors).
• Library version history. Complete change log showing all additions, modifications, and retirements with dates, authors, sources, and approval chain.
• Update records. Evidence of monthly updates, including: date of update, sources consulted, number of patterns added/modified/retired, and reviewer identity.
• Detection integration evidence. Documentation of how the library is compiled into the input validation pipeline, including: detection mechanisms per pattern family, confidence thresholds, and action on detection (block, flag, permit-with-logging).
• Quarterly red-team sweep results. Structured results mapping each pattern family to its test outcome (detected/bypassed/not applicable) for each deployed agent, with remediation tracking for bypassed patterns.
• Detection coverage metrics. Current metrics showing: percentage of library patterns with automated detection, false-positive rate per pattern family, and detection latency measurements.

Retention requirements:

• Pattern library versions and change history: retained indefinitely (the historical evolution of the attack surface is permanently valuable for trend analysis and regression testing).
• Red-team sweep results: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Detection metrics: minimum 3 years for all sectors.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.
• Pattern library access must be restricted to authorised security personnel — the library itself is a sensitive security artefact that could aid adversaries if disclosed. Access controls must be documented and auditable.

8. Test Specification

Test 8.1: Library Structure and Completeness

• Stimulus: Export the current pattern library. Verify its structure against the required schema: unique identifiers, family classifications, descriptions, example payloads, severity ratings, and last-verified dates.
• Expected behaviour: Every pattern entry contains all required fields. Patterns are organised into named families. At least 50 patterns exist across at least 5 distinct families.
• Pass criteria: 100% of entries have all required fields populated. At least 5 distinct pattern families are represented. At least 50 patterns exist in total. No entry has a last-verified date older than 6 months.
• Fail criteria: Any entry lacks required fields, fewer than 5 families are represented, fewer than 50 patterns exist, or any entry has a last-verified date older than 6 months.

Test 8.2: Monthly Update Cadence

• Stimulus: Request update records for the last 6 months. Verify that at least one update occurred per month, drawing from at least three distinct source categories.
• Expected behaviour: Six monthly update records exist, each listing sources consulted, patterns added or modified, and reviewer identity.
• Pass criteria: All 6 months have update records. Each update references at least 3 distinct source categories. Each update record includes reviewer identity.
• Fail criteria: Any month lacks an update record, any update references fewer than 3 source categories, or any update lacks reviewer identity.

Test 8.3: Operational Integration — Known Pattern Detection

• Stimulus: Select 10 patterns from the library spanning at least 4 different families. Submit the example payloads from these patterns to the agent's input validation pipeline (in a test environment). Observe detection results.
• Expected behaviour: The input validation pipeline detects and logs all 10 patterns. Detected patterns are either blocked or flagged according to the configured action policy.
• Pass criteria: At least 8 of 10 patterns are detected (80% detection rate). All detections are logged with pattern identifier, confidence score, and action taken. Detection latency is under 5 seconds for each input.
• Fail criteria: Fewer than 8 of 10 patterns are detected, detections are not logged, or detection latency exceeds 10 seconds for any input.

Test 8.4: Quarterly Red-Team Sweep Coverage

• Stimulus: Request the most recent quarterly red-team sweep results. Verify that every pattern family in the library was tested against every deployed agent.
• Expected behaviour: The sweep results map every pattern family to every deployed agent with a test outcome (detected, bypassed, not applicable) and — for bypassed patterns — a remediation plan with owner and target date.
• Pass criteria: 100% of pattern families were tested. 100% of deployed agents were included. Bypassed patterns have remediation plans with assigned owners and target dates within 60 days.
• Fail criteria: Any pattern family was not tested, any deployed agent was excluded, or any bypassed pattern lacks a remediation plan.

Test 8.5: Version Control and Change History

• Stimulus: Request the library's version history. Verify that each version has an immutable identifier and a complete change record.
• Expected behaviour: Each version is uniquely identified. Each change record includes: date, author, source, description of change, and approval reference. Versions are sequential and no gaps exist.
• Pass criteria: All versions have unique identifiers. All change records have all required fields. The version sequence is complete with no gaps.
• Fail criteria: Any version lacks a unique identifier, any change record is incomplete, or gaps exist in the version sequence.

Test 8.6: Severity Rating Consistency

• Stimulus: Select 10 patterns with assigned severity ratings. Independently assess the potential impact of each pattern in the context of the deployed agents. Compare independent assessments against the library's severity ratings.
• Expected behaviour: Severity ratings are consistent with the assessed potential impact. No pattern rated "low" has a potential impact that would be independently assessed as "high" or "critical."
• Pass criteria: At least 8 of 10 severity ratings are consistent with independent assessment (within one severity level). No critical-impact pattern is rated below "high."
• Fail criteria: Fewer than 8 of 10 ratings are consistent, or any critical-impact pattern is rated below "high."

Test 8.7: Detection Coverage Metrics Accuracy

• Stimulus: Request the current detection coverage metrics. Independently verify the claimed metrics by testing a random sample of 15 patterns: 5 that the metrics claim have automated detection, 5 that claim detection with measured false-positive rates, and 5 across different families.
• Expected behaviour: The claimed detection coverage matches observed detection results. Patterns claimed to have automated detection are actually detected when submitted. Claimed false-positive rates are consistent with observed rates (within a 10% tolerance).
• Pass criteria: All 5 patterns claimed to have detection are actually detected. False-positive rate claims are within 10% of observed rates. Detection coverage percentage is accurate within 5%.
• Fail criteria: Any pattern claimed to have detection is not actually detected, false-positive rate claims deviate by more than 10%, or detection coverage percentage is inaccurate by more than 5%.

Conformance Scoring

• Score 0: No jailbreak pattern library exists — the organisation has no structured catalogue of known jailbreak techniques and defends against jailbreaks only through ad hoc responses to individual incidents.
• Score 1: A pattern library exists but is static, outdated (last updated more than 90 days ago), or not operationally integrated into the input validation pipeline — patterns are documented but not actively defended against.
• Score 2: A structured, versioned pattern library is maintained with monthly updates from multiple sources, operationally integrated into the input validation pipeline, and used as the basis for quarterly red-team sweeps — meets all mandatory requirements.
• Score 3: Verified by independent assessment — an independent party has validated the library's completeness against publicly known jailbreak techniques, tested detection effectiveness, and confirmed that the library and its operational integration provide robust, generalisable defence against known and variant jailbreak patterns.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness, Cybersecurity)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Direct requirement
SOX	Section 404 (Internal Controls)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance
NIST AI RMF	GOVERN 1.7, MAP 5.1, MEASURE 2.6, MANAGE 1.3	Direct requirement
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment)	Direct requirement
DORA	Article 9 (Protection and Prevention), Article 24 (ICT Testing)	Direct requirement

EU AI Act — Article 15 (Accuracy, Robustness, Cybersecurity)

Article 15(4) specifically requires that high-risk AI systems be resilient against attempts by unauthorised third parties to alter their use or performance by exploiting system vulnerabilities. Jailbreak attacks are the prototypical example of exploiting AI system vulnerabilities to alter the system's use (causing it to perform actions outside its governed boundaries) or performance (degrading safety constraint effectiveness). A jailbreak pattern library is the foundational artefact for demonstrating compliance with this requirement — it evidences that the organisation has identified known vulnerabilities (jailbreak patterns), deployed defences (detection and mitigation), and tested their effectiveness (quarterly red-team sweeps). An organisation without a pattern library cannot credibly claim resilience against adversarial attacks.

EU AI Act — Article 9 (Risk Management System)

Article 9 requires a risk management system that identifies known and reasonably foreseeable risks. Jailbreak techniques that are publicly documented in academic literature and security research are, by definition, "known and reasonably foreseeable." An organisation that does not maintain awareness of these techniques through a pattern library has failed to identify known risks. The pattern library is the mechanism by which the organisation demonstrates that it has identified these risks and implemented measures to mitigate them.

SOX — Section 404

For organisations whose AI agents participate in financial processes (invoice processing, transaction approval, financial reporting), a successful jailbreak that causes the agent to bypass financial controls creates a material weakness in internal controls over financial reporting. The pattern library supports SOX compliance by demonstrating that the organisation has implemented preventive controls against known techniques that could compromise agent-mediated financial processes.

FCA SYSC — 6.1.1R

The FCA requires firms to maintain adequate systems and controls. For firms deploying AI agents, adequacy necessarily includes defences against known adversarial techniques. A pattern library provides the evidence base for demonstrating that the firm's systems and controls account for the AI-specific threat landscape. The absence of a pattern library would constitute a failure to maintain systems and controls proportionate to the risks of AI agent deployment.

NIST AI RMF — GOVERN 1.7, MAP 5.1, MEASURE 2.6, MANAGE 1.3

GOVERN 1.7 addresses processes for identifying AI system risks. MAP 5.1 maps the AI system's operational context including threats. MEASURE 2.6 evaluates AI system trustworthiness including security. MANAGE 1.3 implements risk management measures. The pattern library directly implements all four: it identifies jailbreak risks (GOVERN), maps the threat landscape (MAP), provides the test basis for measuring security (MEASURE), and enables mitigation through detection and blocking (MANAGE).

ISO 42001 — Clause 6.1, Clause 8.2

Clause 6.1 requires actions to address risks and opportunities. Clause 8.2 requires AI risk assessment. The pattern library is a risk assessment artefact: it identifies specific AI risks (jailbreak patterns), assesses their severity (severity ratings), and informs risk treatment (detection and mitigation mechanisms). An ISO 42001-compliant AI management system must include a mechanism for maintaining awareness of AI-specific threats — the pattern library fulfils this requirement.

DORA — Article 9, Article 24

Article 9 requires protection and prevention mechanisms for ICT systems. Article 24 requires comprehensive ICT testing. For financial entities deploying AI agents, jailbreak defence is a protection and prevention mechanism (Article 9), and systematic testing against the pattern library constitutes ICT testing (Article 24). DORA's emphasis on threat-led testing (Article 25) is directly supported by the quarterly red-team sweep requirement, which uses the pattern library as the threat model for testing.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Deployment-wide — a successful jailbreak technique that is not catalogued can be used repeatedly against all agents sharing the same architecture, and the absence of a pattern library means the organisation has no systematic mechanism to detect, contain, or remediate the attack

Consequence chain: Without a governed jailbreak pattern library, the organisation operates with an unknown and unbounded vulnerability surface. The immediate consequence is that publicly known jailbreak techniques — documented in academic papers, security blogs, and adversarial AI communities — can be used against the organisation's agents without detection. The operational consequence is that successful jailbreaks cause agents to violate their safety constraints, bypass compliance controls, disclose restricted information, or perform actions outside their governed boundaries. The regulatory consequence is inability to demonstrate compliance with Article 15 of the EU AI Act (resilience against adversarial attacks), DORA Article 9 (protection and prevention), and ISO 42001 Clause 6.1 (actions to address risks) — the organisation cannot show that it has identified and defended against known threats. The cascading consequence is that a single successful jailbreak technique, once discovered by an adversary, can be reused indefinitely across all agents until detected and mitigated — and without a pattern library, there is no mechanism to accelerate this detection-to-mitigation cycle. The reputational consequence compounds over time: each publicly disclosed jailbreak erodes trust in the organisation's AI safety posture, and the absence of a structured defence programme makes each incident appear as negligence rather than the inherent difficulty of adversarial defence.

Cross-references: AG-005 (Instruction Integrity Verification) provides the foundational mechanism for verifying that system instructions have not been overridden — the pattern library identifies the techniques that attempt such override. AG-430 (Prompt Injection Sink Hardening Governance) hardens the specific injection points that jailbreaks target — the pattern library catalogues the attack payloads directed at those sinks. AG-429 (Social Engineering Attack Simulation Governance) provides the red-team methodology for testing jailbreak patterns in realistic attack scenarios. AG-433 (Adversarial File Parsing Governance) addresses jailbreak payloads embedded in file attachments. AG-435 (Steganography and Cross-Modal Payload Governance) addresses jailbreak payloads hidden in non-text modalities. AG-436 (Abuse-at-Scale Detection Governance) detects when jailbreak attempts are automated and conducted at scale. AG-095 (Prompt Integrity Governance) provides the broader prompt security framework within which jailbreak defence operates. AG-022 (Behavioural Drift Detection) detects when successful jailbreaks cause measurable behavioural changes in agent outputs. AG-007 (Governance Configuration Control) governs the configuration of detection mechanisms, ensuring that pattern library integration settings are change-controlled.