← Domains & pillars

Model & Prompt LifecycleView domain

APRF-02

Prompt Engineering

Treat prompts as versioned production artifacts with regression control.

Purpose

Manage system, developer, and tool prompts as first-class production artifacts—versioned, reviewed, tested, and rolled back like application code.

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.

  • PRM-M1L3 · DefinedTier 2 · ProductionhybridE3

    Every production prompt shall carry an immutable version identifier and a named owner in a registry (or equivalent versioned store)—with zero unversioned production prompts and zero prompts missing an owner.

    Artifact
    Prompt registry (or versioned prompt store) listing production prompts with immutable version IDs + Owner field populated for each production prompt; query showing 0 unversioned / 0 missing-owner
    Pass condition
    100% of production prompts have an immutable version ID and named owner; 0 unversioned production prompts (registry evidence measuredAt ≤90 days). If the system ships no production prompts (templates, system prompts, or managed prompt configs), score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Make the exact prompt serving production identifiable, attributable, and immutable.

    Threats mitigated

    Configuration DriftRepudiationPrompt Injection

    Protects

    PromptsAudit TrailRuntime

    MITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.

    Unversioned prompts make it impossible to establish what instructions were in force during an incident or to prove a change was reviewed. Versioning is the precondition for rollback, evaluation attachment, and forensic reconstruction.

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

  • PRM-M2L3 · DefinedTier 2 · ProductionhybridE3

    Production prompt releases shall go through human (or equivalent) review and link a passing eval artifact before promotion, with promote-without-review-and-eval blocked on the release path.

    Artifact
    Change records linking prompt versions to review IDs and eval pass artifacts + CI/registry gate (or equivalent) blocking promote without review + eval
    Pass condition
    100% of production prompt releases in the last 30 days have a review ID and eval pass artifact; promote-without-both is blocked (release evidence measuredAt ≤90 days). If no production prompt releases occur, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Ensure prompt changes are reviewed and backed by evaluation evidence before release.

    Threats mitigated

    Harmful Content GenerationPrompt InjectionMisinformationInsider Misuse

    Protects

    PromptsUsersSafety

    MITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.

    Prompts carry security-relevant instructions, so an unreviewed edit can silently delete a safety constraint with no code change and no deployment signal. Review plus attached evaluation makes that change visible and measurable before it reaches users.

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

  • PRM-M3L3 · DefinedTier 2 · ProductionhybridE3

    Production systems shall restore a prior prompt version within a documented RTO without a full application redeploy—proven by a timed restore test in the last 90 days.

    Artifact
    Prompt rollback procedure documenting RTO and restore without full app redeploy + Timed restore test record showing prior prompt version restored within RTO (≤90 days)
    Pass condition
    Prior prompt version restored in ≤ documented RTO without full app redeploy; demonstrated in the last 90 days (restore evidence measuredAt ≤90 days). If no production prompts exist, score NOT_APPLICABLE.

    Why this control exists

    Threat map

    Allow rollback to a prior prompt version without redeploying unrelated services.

    Threats mitigated

    Harmful Content GenerationDenial of ServiceConfiguration Drift

    Protects

    PromptsUsersAvailabilitySafety

    MITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.

    Prompt rollback coupled to a full service deploy is too slow to be usable during a live safety incident. Independent rollback keeps time to containment within minutes; no adversary technique maps.

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

Evidence required

  • Prompt registry with versions, owners, and change history
  • Eval reports linked to prompt releases
  • Rollback procedure documentation
More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution

Engineering philosophy

Prompts are code. They change behavior, create regressions, and carry security and cost implications. Informal edits in dashboards without lineage are an anti-pattern for production AI.

Why it matters

Silent prompt drift is a leading cause of quality and safety regressions. Without versioning and eval gates, teams cannot answer what changed when production behavior breaks.

Common failures

  • Editing production prompts directly in a vendor console with no history
  • No golden-set regression tests when prompts change
  • Mixing business logic, safety policy, and tone in one unmaintainable blob
  • Different prompts per environment with no promotion path

Severity & risk

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

Engineering best practices

  • Store prompts in source control or a versioned registry with CI promotion
  • Separate safety/policy prompts from product/UX prompts where possible
  • Measure token cost impact of prompt changes alongside quality
  • Document intended failure modes and refusal behavior in the prompt contract

Automatic validations

  • CI blocks deploy if prompt hash lacks associated eval pass
  • Diff reviews in pull requests for prompt files
  • Token budget checks against historical baselines

Manual validations

  • Peer review of safety-critical prompt sections
  • Product review of tone and policy alignment for major releases

Examples

  • A coding agent system prompt is tagged v47; a quality drop triggers rollback to v46 in minutes
  • Marketing copy prompts and refund-policy prompts live in separate modules with different owners

References

Crosswalks

  • §8 Operation

    ISO/IEC 42001 · supports

  • LLM01 Prompt Injection

    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.3 Output Safety

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C9.3 Component Isolation and Tool Authorization

    OWASP AI Application Security Verification Standard (AISVS) · supports

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

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • C11.4 Model Runtime Anomaly Detection

    OWASP AI Application Security Verification Standard (AISVS) · supports

  • CC8 Change Management

    SOC 2 Trust Services Criteria · evidence-for

  • Generative AI Lens Generative AI Lens (themes)

    AWS Well-Architected Framework · aligns-with

Future evolution

Industry-standard prompt manifests (SBOM-like) and signed prompt releases for regulated environments.