Prompt Change Approval Governance requires that every material change to an AI agent's system prompt, instruction template, or behavioural directive undergoes a formal review and approval process before deployment. Changes to prompts are functionally equivalent to changes in an agent's operational mandate — a single altered sentence can shift tone, expand scope, remove safety constraints, or introduce bias. Without structured approval gates, prompt changes propagate to production unreviewed, creating drift between the organisation's intended agent behaviour and its actual behaviour. This dimension ensures that prompt modifications are treated with the same rigour as code changes in safety-critical software: proposed, reviewed by qualified personnel, tested against regression criteria, approved with attribution, and deployed through controlled release mechanisms.
Scenario A — Unapproved Prompt Edit Removes Safety Constraint: A customer-facing insurance agent uses a system prompt containing: "You MUST NOT provide coverage recommendations without first confirming the customer's existing policy details." A product manager, responding to user feedback about friction, edits the prompt directly in the configuration dashboard to remove this sentence. The change is saved at 14:32 on a Tuesday afternoon with no review. Within 4 hours the agent has provided 847 coverage recommendations to customers without confirming existing policies. 23 customers purchase duplicate coverage. The organisation faces regulatory complaints, refund obligations totalling £187,000, and a FCA investigation into mis-selling.
What went wrong: The prompt change was functionally equivalent to removing a compliance control, but it was treated as a minor configuration tweak. No review process existed. No one with compliance expertise assessed the change. No regression test verified that the safety constraint still held. The £187,000 exposure accumulated at machine speed because the agent served hundreds of customers per hour.
Scenario B — Gradual Prompt Erosion Through Incremental Edits: An enterprise workflow agent's system prompt undergoes 47 edits over 6 months. Each edit is small — a word changed here, a clause softened there. No single edit triggers concern. But the cumulative effect transforms the agent from a conservative, policy-adherent assistant into an overly permissive one that routinely approves exceptions the original prompt would have escalated. When an audit reviews agent decisions, the organisation cannot reconstruct which version of the prompt was active when specific decisions were made, because no change history exists.
What went wrong: Individual changes were small enough to seem harmless, but no mechanism tracked the cumulative drift from the original approved baseline. Without versioned history and periodic baseline comparison, the prompt's effective policy posture degraded without detection. This intersects with AG-125 (Prompt Drift Detection).
Scenario C — Prompt Change Deployed Without Regression Testing: A financial-value agent's system prompt is updated to include a new product category. The engineer making the change tests the new product flow and confirms it works. However, the added instructions inadvertently shift the tokenisation of existing instructions, causing the agent to misinterpret its per-transaction value ceiling. The original ceiling of £50,000 is effectively ignored in 3.2% of transactions. Over 2 weeks, 14 transactions totalling £312,000 exceed the intended limit before the anomaly is detected through routine monitoring.
What went wrong: The prompt change was tested only for the new feature, not for regression against existing critical behaviours. Prompt changes can have non-obvious cascading effects on instruction interpretation — a principle well understood in software engineering but frequently overlooked in prompt management.
Scope: This dimension applies to any AI agent deployment where the system prompt, instruction template, behavioural directive, or any text-based configuration that influences agent reasoning or behaviour can be modified after initial deployment. This includes: system prompts, few-shot examples, persona definitions, tool-use instructions, safety guardrail statements, output format directives, and any dynamically assembled prompt components. It applies regardless of whether prompts are stored in files, databases, configuration management systems, or embedded in application code. Read-only prompt configurations that are compiled into immutable deployment artefacts and cannot be changed without a full redeployment cycle are within scope of this dimension only at the redeployment boundary. The test is: can someone change what the agent is told to do without going through a controlled release process? If yes, this dimension applies.
4.1. A conforming system MUST require explicit approval from at least one designated reviewer before any material change to an agent's system prompt, instruction set, or behavioural directive is deployed to production.
4.2. A conforming system MUST maintain an immutable, timestamped log of every prompt change including the previous version, the new version, the identity of the proposer, the identity of the approver, and the rationale for the change.
4.3. A conforming system MUST define and document criteria for what constitutes a "material" prompt change requiring approval versus a non-material change (e.g., typographical correction) that may follow an expedited process.
4.4. A conforming system MUST prevent any unapproved prompt change from reaching production agent instances — enforcement at the deployment layer, not reliance on process compliance.
4.5. A conforming system MUST ensure that emergency prompt changes follow a documented emergency change procedure that includes retrospective review within a defined timeframe not exceeding 48 hours.
4.6. A conforming system SHOULD require that reviewers possess domain expertise relevant to the agent's operational context (e.g., compliance expertise for agents in regulated domains).
4.7. A conforming system SHOULD integrate prompt change approval with existing change management workflows (e.g., pull request reviews, change advisory boards) rather than creating parallel processes.
4.8. A conforming system SHOULD require regression testing of critical agent behaviours before approving prompt changes, using a defined test suite that covers safety constraints, compliance requirements, and core functional behaviours.
4.9. A conforming system MAY implement automated pre-screening of proposed prompt changes to flag removals of safety-critical keywords, constraint relaxations, or scope expansions for prioritised human review.
Prompts are the primary mechanism through which organisations define and constrain AI agent behaviour. A prompt change is not a cosmetic configuration update — it is a behavioural policy change. When an organisation modifies an agent's system prompt, it is changing what the agent will do, how it will respond, and what constraints it will observe. This makes prompt changes functionally equivalent to policy changes, and they should be governed accordingly.
The risk is amplified by three characteristics of prompt-driven systems. First, prompts are deceptively simple — they are natural language text, which creates a false sense that changes are low-risk and easily reversible. Second, prompt changes take effect immediately upon deployment, affecting every subsequent interaction without a gradual rollout unless explicitly engineered. Third, the effects of prompt changes are non-linear — a small textual change can produce disproportionate behavioural shifts due to the complex interaction between instructions, context, and model interpretation.
Without formal approval governance, organisations face three failure modes. The first is unauthorised scope expansion, where individuals with prompt access expand agent capabilities beyond the approved mandate without oversight. The second is accidental constraint removal, where well-intentioned edits inadvertently weaken safety constraints that the editor did not recognise as safety-critical. The third is untraceable behavioural change, where the organisation cannot determine what the agent was instructed to do at any historical point, making incident investigation, audit response, and regulatory compliance impossible.
The approval requirement is not bureaucracy for its own sake — it is the minimum structural control necessary to maintain the integrity of the organisation's AI governance posture. Every other prompt-related governance dimension (AG-095, AG-122, AG-125, AG-127) assumes that changes go through a controlled process. Without AG-359, those dimensions operate on an unstable foundation.
Prompt Change Approval Governance requires establishing a controlled pipeline through which all prompt modifications must flow before reaching production. The core mechanism is a gate — a point in the deployment process where a proposed change is held pending human review and explicit approval. The gate must be enforced structurally, not merely documented as a process expectation.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Prompt changes for agents handling financial transactions, advice, or regulated communications should be reviewed by compliance-qualified personnel. The FCA's expectations under SYSC 6.1.1R extend to AI agent configuration — a prompt change that alters how an agent provides financial guidance is a change to a controlled function. Firms should integrate prompt change approval with their existing change management framework and maintain audit trails sufficient for regulatory examination.
Healthcare. Prompt changes for clinical decision support agents must be reviewed against clinical safety standards. A prompt modification that changes how an agent interprets symptoms, recommends treatments, or triages patients is a clinical safety change. Review should include clinical expertise and, where applicable, alignment with NICE guidelines or equivalent clinical standards.
Public Sector. Prompt changes for agents interacting with citizens must be reviewed for bias, accessibility, and rights implications. A prompt change that alters how an agent handles vulnerable individuals, processes benefit claims, or communicates decisions may have equality and human rights implications requiring specialist review.
Basic Implementation — The organisation maintains prompt files in a shared repository with a documented expectation that changes will be reviewed before deployment. Review occurs through informal channels (e.g., messaging a colleague). Deployment is manual and does not structurally enforce the review requirement. Change history is available through repository version control. This level meets the minimum mandatory requirements but relies on process discipline rather than structural enforcement.
Intermediate Implementation — Prompts are managed in a version-controlled system with branch protection requiring at least one approving review. Deployment is automated through a CI/CD pipeline that checks approval status before deploying. Material change criteria are documented and auditable. Reviewers are designated based on domain expertise. Regression tests run automatically on proposed changes. Emergency changes follow a documented procedure with retrospective review. The change log is immutable and includes proposer, approver, rationale, and timestamp.
Advanced Implementation — All intermediate capabilities plus: automated diff analysis flags high-risk modifications for prioritised review. Changes are deployed through canary or staged rollouts with automated agent monitoring. The approval workflow integrates with the organisation's enterprise change management system. Approval decisions are risk-scored based on the nature and scope of the change. The organisation can demonstrate to regulators the complete chain of custody for every prompt version that was active at any point, including who approved it, what testing was performed, and what the behavioural impact was. Periodic baseline reviews compare the current prompt against the original approved version to detect cumulative drift.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Unapproved Change Rejection
Test 8.2: Change Log Completeness and Immutability
Test 8.3: Material Change Criteria Application
Test 8.4: Emergency Change Retrospective Review
Test 8.5: Reviewer Domain Expertise Verification
Test 8.6: Regression Suite Execution Before Approval
Test 8.7: Dual-Control Enforcement
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 17 (Quality Management System) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| NIST AI RMF | GOVERN 1.4, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 8.1 (Operational Planning and Control) | Direct requirement |
| DORA | Article 8 (ICT Risk Management — Change Management) | Supports compliance |
Article 17 requires providers of high-risk AI systems to implement a quality management system that includes procedures for design, development, and modification of the AI system. Prompt changes are modifications to the AI system's behaviour and therefore fall within scope. The requirement for documented change procedures, review processes, and traceability maps directly to AG-359's approval workflow, change logging, and evidence requirements. Organisations that allow uncontrolled prompt changes cannot demonstrate compliance with Article 17's quality management requirements.
For AI agents involved in financial operations, prompt changes that alter agent behaviour are changes to internal controls. SOX Section 404 requires that changes to internal controls are authorised, tested, and documented. A prompt change that alters how an agent processes financial transactions, calculates values, or applies business rules is a change to an internal control. The change must be authorised through the organisation's change management process, tested for impact on financial reporting, and documented with sufficient detail for external audit.
SYSC 6.1.1R requires firms to establish and maintain adequate policies and procedures for systems and controls. The FCA expects that changes to systems processing regulated activities are controlled, reviewed, and documented. Prompt changes for agents operating in regulated financial services are changes to a system processing regulated activities. The absence of prompt change controls would be a systems and controls deficiency.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Service-wide — all interactions with the affected agent from the point of the unapproved change until detection |
Consequence chain: An unapproved prompt change deploys to production, altering agent behaviour for every subsequent interaction. If the change removes a safety constraint, the agent immediately begins operating without that constraint across all concurrent and future sessions. At typical agent interaction volumes of 200-500 sessions per hour, a constraint removal can affect thousands of interactions before detection. The immediate technical failure is behavioural deviation from the approved governance posture. The operational impact depends on the nature of the change: a removed compliance constraint creates regulatory exposure; a scope expansion creates unauthorised action exposure; a tone shift creates reputational risk. The business consequence includes regulatory findings for inadequate change control, inability to demonstrate the approved governance posture at historical points, incident investigation costs, customer remediation costs, and potential personal liability for individuals who made or failed to prevent the change. The severity compounds over time — the longer an unapproved change remains in production, the larger the population of affected interactions and the more expensive the remediation.
Cross-references: AG-005 (Instruction Integrity Verification), AG-095 (Prompt Integrity Governance), AG-122 (Prompt Versioning & Rollback Control), AG-125 (Prompt Drift Detection), AG-127 (Prompt Testing & Validation Governance), AG-365 (Prompt Template Provenance Governance).