Governance Configuration Control

2. Summary

Governance Configuration Control governs the versioning, change control, and rollback of mandate configurations that define AI agent behaviour. This is the protocol that ensures the governance rules themselves — the mandates, policies, and rule sets that every other protocol depends on — are managed with the same rigour as the operations they govern. Without AG-007, every other protocol in the framework operates on an unstable foundation: boundaries can shift without record, limits can be relaxed without accountability, and the historical governance posture of the organisation becomes unknowable. The critical distinction is between mandate enforcement (AG-001) and mandate management (AG-007). AG-001 governs what limits are applied and ensures agents cannot exceed them. AG-007 governs how those limits are defined, who changes them, when changes occur, what the prior configuration was, and whether the organisation can return to a known-good state when something goes wrong. AG-007 also addresses a dangerous attack vector: configuration manipulation as a governance bypass — an adversary who cannot breach the enforcement mechanism may instead target the configuration that defines the enforcement rules, changing the rules rather than breaking them.

3. Example

Scenario A — Configuration Manipulation to Bypass Enforcement: An attacker gains access to the mandate configuration system for an AI agent managing customer data access at a telecommunications company. The attacker cannot bypass the data access enforcement mechanism (AG-001 is properly implemented), so instead they modify the mandate configuration to add "all customer records" to the permitted data scope. The change is made at 02:00 on a Saturday. The agent, now operating under the modified mandate, exports 2.4 million customer records to an external staging location. At 04:00, the attacker reverts the mandate configuration to its original state. On Monday morning, the compliance team sees no anomalies in the current configuration and the data exfiltration is not discovered until customer data appears on the dark web three weeks later.

What went wrong: The mandate configuration could be changed without independent authorisation and without triggering any alert. No change frequency monitoring detected the brief relaxation and restoration pattern. The configuration change log either did not exist or was not reviewed. The attacker targeted the configuration rather than the enforcement mechanism — a governance bypass through policy manipulation rather than policy violation. Consequence: 2.4 million customer records compromised. GDPR Article 33 breach notification required within 72 hours of discovery — but discovery was delayed by three weeks. Regulatory fine under GDPR Article 83 for inadequate technical measures. Personal data breach litigation. Reputational damage.

Scenario B — Mandate Drift Through Incremental Changes: A financial services firm deploys an AI agent for trade execution with a mandate limiting individual trade values to GBP 100,000 and daily aggregate to GBP 500,000. Over eighteen months, the operations team makes 47 incremental changes to the mandate in response to business requests. Each individual change is small and appears reasonable — a 10% increase here, a new instrument type there. But the cumulative effect is that the mandate now permits individual trades of GBP 850,000 and daily aggregates of GBP 4.2 million. When an FCA examination occurs, the firm cannot demonstrate that the current configuration was formally approved at these levels, because each change was made individually without reference to the cumulative drift from the original approved configuration.

What went wrong: Configuration changes were tracked individually but cumulative drift was not assessed. No baseline comparison mechanism existed to flag that the current configuration had diverged significantly from the last formally approved version. Change authorisation existed for individual changes but not for the aggregate effect of multiple changes. Consequence: FCA enforcement action for operating outside approved risk parameters. Requirement to revert to the last formally approved configuration immediately, causing business disruption. Potential personal liability under the Senior Managers and Certification Regime.

Scenario C — Rollback Failure During Incident Response: An AI agent managing automated procurement begins approving purchase orders that violate the organisation's supplier diversity policy due to a recent mandate configuration change that inadvertently removed the supplier diversity constraint. The compliance team detects the issue within two hours and attempts to roll back to the prior mandate version. However, the configuration management system stores only the current active configuration — prior versions were overwritten. The team attempts to reconstruct the original configuration from documentation, but the documentation is outdated and does not reflect several intermediate changes. The organisation is forced to shut down the procurement agent entirely while the configuration is rebuilt manually over three days.

What went wrong: The configuration management system did not maintain immutable version history. Rollback was not possible because prior versions were overwritten. Documentation was not kept in sync with actual configuration. The recovery time was measured in days rather than seconds. Consequence: Three days of procurement agent downtime, requiring manual processing of all purchase orders. Supplier diversity compliance violations during the two-hour exposure window. Audit finding for inadequate configuration management.

4. Requirement Statement

Scope: This dimension applies to all mandate configurations, governance rule sets, and policy definitions that determine agent behaviour. This includes operational boundary definitions (AG-001 mandates), rate limit configurations (AG-004), delegation policies (AG-009), temporal authority definitions (AG-010), human oversight thresholds (AG-019), and any other parameter or policy that influences how governance controls operate. If changing a value would alter the governance posture of any agent, that value is within scope. The scope encompasses the full lifecycle of configuration management: creation, modification, activation, deactivation, and retention. Retention must align with regulatory requirements — typically seven years for financial services under SOX and MiFID II, six years under HIPAA, and as determined by sectoral regulation for other industries.

4.1. A conforming system MUST version every mandate configuration with a unique identifier, such that any historical version can be unambiguously referenced.

4.2. A conforming system MUST log mandate changes with: who authorised the change, when it was made, and what changed (the full prior state and the full new state).

4.3. A conforming system MUST support rollback to any prior mandate version within a defined recovery window, restoring the exact prior configuration.

4.4. A conforming system MUST ensure that actions in-flight at the time of a mandate change are completed under the mandate version that governed their initiation.

4.5. A conforming system SHOULD require authorisation from a role independent of the agent operator for mandate changes — enforced technically, not by process alone.

4.6. A conforming system SHOULD retain mandate version history for a minimum of 7 years.

4.7. A conforming system SHOULD monitor configuration change frequency, with alerts triggered when the rate of changes exceeds defined thresholds — unusually rapid cycling may indicate evasion through temporary relaxation and restoration.

4.8. A conforming system MAY implement staged mandate deployment with canary testing before full activation, allowing new configurations to be tested against a subset of agent traffic before organisation-wide rollout.

5. Rationale

An organisation's governance posture is defined not by its current configuration but by the complete, auditable history of its configuration over time. Without that history, governance is a claim that cannot be verified. Mandate configurations are not static — business requirements change, risk appetites evolve, new regulations take effect, and operational contexts shift. Mandate configurations will be modified. The question is whether those modifications are controlled, auditable, and reversible, or whether they happen informally, without record, and without the ability to undo mistakes.

In regulated industries, the ability to demonstrate the governance configuration that was active at any historical point is not merely good practice — it is a legal and regulatory requirement. When a regulator examines an organisation's AI agent governance, they will ask not only "what are your current limits?" but "what were your limits six months ago when this incident occurred?" and "who authorised the change from the previous limits to the current ones?" Without immutable versioning and attribution, these questions are unanswerable.

AG-007 also closes a subtle but dangerous attack vector: configuration manipulation as a governance bypass. An adversary who cannot breach the enforcement mechanism (AG-001) may instead target the configuration that defines the enforcement rules. If mandate configurations can be changed without authorisation, without audit trail, or without detection of anomalous change patterns, then the structural enforcement becomes meaningless — the attacker simply changes the rules rather than breaking them. This is the difference between picking a lock and having a copy of the key. AG-007 ensures that the keys to governance configuration are controlled with the same rigour as the locks they open.

The failure mode extends beyond intentional attacks. Accidental misconfigurations and configuration drift — the gradual divergence of a configuration from its approved baseline through individually reasonable changes — are equally dangerous. Without versioning and rollback, recovery from any misconfiguration requires manual reconstruction, which is slow and error-prone. A rollback that takes seconds in a versioned system takes days in an unversioned one — and during those days, the agent either operates under an incorrect configuration or is shut down entirely.

6. Implementation Guidance

Store mandate configurations as immutable versioned objects. Each activation creates a new version; prior versions are never modified. Maintain a current-version pointer that can be updated atomically. In-flight action tracking should record the mandate version ID at initiation and enforce that version throughout the action lifecycle.

Recommended patterns:

• Immutable Object Store. Store each version as an immutable object in a content-addressable store. Each version is identified by the hash of its content, making tampering detectable. A separate pointer identifies the active version. Changes write a new object and update the pointer atomically with the change log entry.
• Event-Sourced Configuration. Represent configuration as an event stream. Each change is a delta event. The current configuration is derived by replaying the stream. Rollback replays events up to a specified point. This pattern enables temporal queries — determining what configuration was active at any historical point — which is essential for regulatory examinations.
• Dual-Control Configuration Pipeline. Require two independent authorisations for each change. The requestor submits a proposed change; an independent authoriser approves or rejects it. Only approved versions can be activated. This directly implements separation of duties required by SOX and expected by the FCA.

Anti-patterns to avoid:

• Storing configuration in mutable files. Organisations commonly store mandate configurations in JSON or YAML files that are overwritten with each change. This destroys version history. Even if changes are logged separately, the log and the configuration can diverge, and the log cannot be used to reconstruct prior configurations if it records only the fact of a change rather than the full prior state.
• Versioning without attribution. Some organisations implement version control for configurations but do not enforce authenticated attribution for each change. A version history that shows what changed and when, but not who authorised the change, is insufficient for regulatory purposes and useless for accountability.
• Testing rollback only in isolation. Organisations test rollback in a clean environment but not under production conditions. A rollback that works when no agents are processing actions may fail or create inconsistencies when agents have in-flight actions that reference the outgoing configuration version. Rollback testing must include scenarios where actions are in progress during the transition.
• Treating configuration changes as purely operational decisions. Mandate configuration changes alter the governance posture of the organisation. A change that raises a transaction limit or adds a new permitted action type is a governance decision, not merely an operational adjustment. Without appropriate authorisation levels — typically independent of the agent operations team — configuration changes can bypass the governance intent.
• No change frequency monitoring. Even with versioning and attribution, an attacker with legitimate access can manipulate configurations by making rapid changes — relaxing a limit, allowing a prohibited action, then restoring the original configuration. Without monitoring for anomalous change frequency, this pattern is invisible in a point-in-time review.

Industry Considerations

Financial Services. Configuration management must integrate with existing change management frameworks. The FCA expects impact assessment, independent authorisation, testing, and post-implementation review for changes to systems and controls. Version history retention should align with record-keeping obligations — typically 7 years for MiFID II. SOX auditors will examine whether changes to control definitions are authorised, documented, tested, and reversible. An uncontrolled change to a mandate configuration is equivalent to an uncontrolled change to a financial control, which constitutes a control deficiency or potentially a material weakness.

Healthcare. Changes affecting clinical agent behaviour should require clinical governance approval, not just technical approval. HIPAA requires periodic access control configuration review. Version history must be retained for a minimum of 6 years under HIPAA record retention requirements. Changes to data access mandates that affect patient information scope require assessment against HIPAA minimum necessary requirements.

Critical Infrastructure. Configuration changes affecting safety-critical parameters should require formal safety assessment (e.g., HAZOP analysis) before approval. IEC 62443 requires security configurations be managed under a formal change management process. Rollback must be tested under simulated operational conditions to verify that transitions do not create unsafe transient states. The consequences of a misconfiguration in safety-critical systems may include physical harm — rollback speed is a safety-relevant metric.

Maturity Model

Basic Implementation — The organisation maintains versioned mandate configuration files with unique identifiers for each version. Changes are logged in a change management system or version control repository with timestamps and author attribution. A rollback procedure exists and has been documented, allowing restoration of any prior version. In-flight actions are tracked against the mandate version that was active when they were initiated. At this level, the organisation meets the mandatory requirements but may have architectural weaknesses: the version history and the active configuration may reside in the same system, change frequency monitoring is manual if it exists at all, and the separation between the person making changes and the person authorising them may not be enforced technically.

Intermediate Implementation — Mandate configurations are stored as immutable objects in a dedicated configuration store. Each change creates a new version; prior versions are never modified or deleted. A current-version pointer is updated atomically when a new configuration is activated. Change authorisation requires a separate approval from a role independent of the agent operator, enforced by the configuration management system (not by process alone). Change frequency is monitored automatically, with alerts triggered when the rate of configuration changes exceeds defined thresholds. Rollback is a single-step operation that updates the current-version pointer to a prior version. The configuration store maintains a cryptographic chain linking each version to its predecessor, enabling tamper detection.

Advanced Implementation — All intermediate capabilities plus: configuration changes are subject to automated impact analysis before activation, assessing how the proposed change would affect agent behaviour under historical action patterns. Staged deployment (canary testing) allows new configurations to be tested against a subset of agent traffic before full activation. Configuration drift detection continuously compares the active configuration against the approved baseline. Independent audit has verified that the versioning, attribution, rollback, and tamper detection mechanisms meet regulatory requirements. The configuration store operates on infrastructure independent of the agent runtime, with separate access controls and monitoring.

7. Evidence Requirements

Required artefacts:

• Version history for all mandate configurations. The actual version store, showing every version with unique identifiers, timestamps, and content. This is the configuration itself, not a description of it.
• Change log with authorisation records. Records showing who requested each change, who authorised it, when authorisation was granted, and when the change was activated. Attribution must be authenticated, not self-reported.
• Rollback procedure and tested recovery time. Documented procedure for rolling back to any prior version, with test results showing the time required to complete a rollback under realistic conditions including in-flight actions.
• In-flight transaction protection documentation. Technical documentation showing how the system ensures that actions initiated under one mandate version complete under that version even if a new version is activated during execution.

Retention requirements:

• Mandate version history and change logs: minimum 7 years for regulated financial services; minimum 6 years for healthcare; minimum 3 years otherwise. The full version history — not just the current configuration — must be retained.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-007 compliance requires verifying both the configuration management mechanism and the operational integrity of changes under real-world conditions.

Test 8.1: Version Integrity

• Stimulus: Make a series of configuration changes and verify that each creates a distinct version with a unique identifier. Confirm that prior versions remain unmodified by comparing their content and checksums before and after subsequent changes.
• Expected behaviour: Each change creates a new version. Prior versions are immutable. Attempting to modify a prior version is either prevented or detected.
• Pass criteria: All versions are distinct, uniquely identified, and prior versions remain byte-identical after subsequent changes.
• Fail criteria: Any prior version is modified by a subsequent change, or versions cannot be uniquely identified.

Test 8.2: Attribution Verification

• Stimulus: Make configuration changes through different user accounts and verify that each change log entry correctly identifies the authorising user, the timestamp, and the specific content of the change. Attempt to make a change without authentication.
• Expected behaviour: Each change is attributed to the authenticated user. Unauthenticated changes are blocked.
• Pass criteria: Every change is attributed with authenticated identity, timestamp, and full change content. Unauthenticated changes are rejected.
• Fail criteria: Any change lacks attribution, or an unauthenticated change is accepted.

Test 8.3: Rollback Under Load

• Stimulus: Activate a new mandate configuration, then rollback to a prior version while agents are actively processing actions.
• Expected behaviour: The restored configuration is byte-identical to the original version. In-flight actions are not disrupted — they complete under their original mandate version. New actions after rollback operate under the restored version.
• Pass criteria: Rollback produces a byte-identical restoration. No in-flight action is evaluated against an inconsistent configuration. The transition is clean.
• Fail criteria: The restored configuration differs from the original, or in-flight actions are disrupted during the transition.

Test 8.4: In-Flight Protection

• Stimulus: Initiate a long-running agent action, then change the mandate configuration while the action is in progress.
• Expected behaviour: The action completes under the mandate version that was active when it was initiated, not the newly activated version.
• Pass criteria: The action is evaluated against its initiating mandate version throughout its lifecycle.
• Fail criteria: The action is evaluated against the new mandate version, or the mandate version changes mid-action.

Test 8.5: Change Frequency Anomaly Detection

• Stimulus: Make rapid successive configuration changes — simulating a relaxation, prohibited action window, and restoration pattern.
• Expected behaviour: The monitoring system detects and alerts on the anomalous change frequency.
• Pass criteria: The rapid change pattern triggers an alert within the defined monitoring interval.
• Fail criteria: Rapid configuration cycling goes undetected by monitoring.

Test 8.6: Unauthorised Change Prevention

• Stimulus: Attempt to activate a configuration change without the required independent authorisation (where dual-control is implemented).
• Expected behaviour: The change is blocked until independent authorisation is provided.
• Pass criteria: No configuration change is activated without the required authorisation pathway.
• Fail criteria: A configuration change is activated without required authorisation.

Conformance Scoring

• Score 0: No mandate versioning exists — configurations can be changed without record.
• Score 1: Versioning exists but rollback or attribution is incomplete — changes are tracked but the organisation cannot restore prior configurations or cannot identify who authorised each change.
• Score 2: Full versioning, attribution, and rollback implemented — every change is versioned, attributed, and reversible, and in-flight actions are protected during transitions.
• Score 3: Verified by independent audit of change control procedures — an independent party has examined the configuration management system and confirmed it meets all mandatory and recommended requirements.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
SOX	Section 404 (Internal Controls — Change Management)	Direct requirement
FCA SYSC	13 (Operational Risk — Change Management)	Direct requirement
ISO 27001	Annex A, A.12.1.2 (Change Control)	Direct requirement
FCA PS21/3	Building Operational Resilience	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks)	Supports compliance
GDPR	Article 83 (Inadequate Technical Measures)	Supports compliance

SOX — Section 404 (Internal Controls — Change Management)

Section 404 requires management to assess and external auditors to attest to the effectiveness of internal controls over financial reporting. Change management is a core component of this assessment. For AI agent governance, the mandate configuration is the control definition — it specifies what limits are enforced. SOX auditors will examine whether changes to these control definitions are authorised, documented, tested, and reversible. An uncontrolled change to a mandate configuration is equivalent to an uncontrolled change to a financial control, which constitutes a control deficiency or potentially a material weakness.

Specific SOX requirements that map to AG-007 include: documentation of all changes to control configurations, evidence of authorisation for each change, retention of change history for the audit period (minimum 7 years for financial records), and the ability to demonstrate the control configuration that was active at any historical point relevant to financial reporting.

FCA SYSC — 13 (Operational Risk)

SYSC 13 requires firms to manage operational risk, including the risk arising from changes to systems and controls. For AI agent deployments, mandate configuration changes are system changes that directly affect operational risk. The FCA expects firms to have change management procedures that include: impact assessment before changes are made, authorisation from an appropriate level of management, testing of changes before deployment, and the ability to reverse changes if problems are identified.

The FCA has been particularly focused on operational resilience since the publication of PS21/3 (Building Operational Resilience). Configuration management for AI agent governance is directly relevant to a firm's ability to demonstrate that it can remain within its impact tolerances during and after changes to its governance controls.

ISO 27001 — Annex A, A.12.1.2 (Change Control)

ISO 27001 Annex A control A.12.1.2 requires that changes to the organisation, business processes, information processing facilities, and systems that affect information security be controlled. For AI agent governance, mandate configurations directly affect information security — a change to data access permissions, for example, can create an information security exposure. ISO 27001 requires a formal change management process with: documented change requests, impact and risk assessment, authorisation, testing, implementation procedures, and rollback plans.

FCA PS21/3 — Building Operational Resilience

PS21/3 requires firms to identify important business services, set impact tolerances, and ensure they can remain within those tolerances during disruptions. For firms using AI agents in important business services, mandate configuration changes are a potential disruption vector. A misconfiguration that causes an agent to operate outside approved parameters is a disruption to the important business service. AG-007's rollback capability directly supports the ability to recover within impact tolerances by restoring a known-good configuration within seconds rather than days.

ISO 42001 — Clause 6.1

Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Configuration control is a fundamental risk treatment for governance instability, ensuring that the rules governing AI agent behaviour are managed with formal change control, versioning, and rollback capability.

GDPR — Article 83 (Inadequate Technical Measures)

Where AI agents process personal data, changes to mandate configurations that affect data access scope are changes to technical measures under GDPR. An uncontrolled change that broadens an agent's data access scope beyond what is necessary for its purpose violates the data minimisation principle. AG-007 ensures that such changes are authorised, auditable, and reversible — providing the technical measure management that GDPR requires.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — uncontrolled configuration changes undermine the foundation of all governance controls

Consequence chain: Without governance configuration control, mandate configurations can be changed without audit trail, creating an opportunity to temporarily relax limits during an attack window. An adversary who cannot breach enforcement can instead change the rules — a governance bypass through policy manipulation rather than policy violation. Rollback capability is lost, making incident recovery dependent on manual reconstruction that takes days rather than seconds. The organisation cannot demonstrate its historical governance posture to regulators — when asked "what were your limits when this incident occurred?", the answer is "we do not know." Configuration drift through individually reasonable changes can accumulate to a governance posture that was never formally approved, creating regulatory exposure that is invisible until examined. The immediate technical failure is an uncontrolled or unattributed configuration change. The operational impact ranges from temporary governance gap (if the change is detected and reversed quickly) to sustained operation outside approved parameters (if drift is not detected). The business consequence includes regulatory enforcement action for inadequate change management, inability to demonstrate governance posture during audits, potential personal liability under senior manager accountability regimes, and in the case of intentional manipulation, criminal liability for falsifying governance controls.

Cross-reference notes: AG-007 governs the configuration that defines AG-001 (Operational Boundary Enforcement) boundaries — without AG-007, AG-001 enforcement operates on an uncontrolled, unauditable foundation. AG-006 (Tamper-Evident Record Integrity) protects the integrity of governance records while AG-007 ensures the governance configuration itself is versioned and tamper-evident — both are required for a complete governance history. AG-008 (Governance Continuity Under Failure) ensures governance continues operating during failure while AG-007 ensures configurations can be restored after failure. AG-009 (Delegated Authority Governance) delegation policies and AG-010 (Time-Bounded Authority Enforcement) temporal authority definitions are mandate configurations governed by AG-007 — changes to these rules must follow the same change control process.