This dimension governs the formal integration of AI agent governance frameworks with the enterprise's existing Governance, Risk and Compliance (GRC), Security Information and Event Management (SIEM), Identity and Access Management (IAM), change management, and incident management systems, ensuring that agent behaviour is visible, controllable, and accountable within the full enterprise control landscape rather than operating as an isolated or shadow governance domain. It matters because agents that are not anchored to existing enterprise control systems create blind spots in organisational risk posture: events generated by agents fail to appear in security monitoring queues, agent identity is not subject to IAM lifecycle controls, agent-initiated changes bypass change advisory board scrutiny, and agent-triggered incidents fall outside established response playbooks, collectively producing a governance gap that adversaries, regulators, and auditors can exploit. Failure looks like an agent executing a privileged workflow that modifies production database schemas during a change-freeze window without generating a change request ticket, the modification going undetected by SIEM correlation rules not configured to ingest agent telemetry, and the incident being discovered only during a quarterly audit three months later — by which point the blast radius includes compromised data integrity, regulatory breach notification obligations, and documented evidence of systematic control failure.
A financial services firm deploys an enterprise workflow agent tasked with automated reconciliation and ledger correction. The agent is granted write access to the core ledger system via a service account provisioned outside the normal IAM joiner-mover-leaver workflow, with no corresponding entry in the privileged access management vault. During a scheduled change-freeze window preceding quarter-end close, the agent autonomously executes 1,847 ledger corrections in response to a backlog of reconciliation flags. No change request is raised; the agent's service account is not bound to the change management system's freeze-period enforcement API. The corrections are directionally correct but introduce a systematic rounding methodology inconsistent with the methodology used in the prior period. The SIEM does not alert because the agent's API calls are not covered by any existing correlation rule. Internal audit discovers the discrepancy 11 weeks later during the external audit preparation cycle. The consequence chain includes: a material misstatement requiring a restatement of quarterly accounts, a regulatory notification under applicable financial reporting obligations, a USD 2.3 million remediation cost covering forensic accounting, system rollback, and regulatory liaison, and a formal finding in the external auditor's management letter citing absence of change management controls over automated systems.
A retail enterprise deploys a customer-facing agent with the capability to provision limited-scope customer portal accounts as part of an onboarding automation flow. The agent's provisioning logic creates accounts by calling an internal directory service API directly, using a hardcoded service account credential that was created during development and never registered in the IAM system's service account registry. Over 14 months the agent provisions 43,000 customer accounts. The IAM system's orphan account detection sweep, which runs monthly and flags accounts not linked to an active identity lifecycle record, does not scan the directory partition used by the agent because the partition was added after the sweep configuration was last updated. When a threat intelligence feed indicates credential stuffing targeting the organisation's customer portal, the security operations centre attempts to correlate the affected accounts against IAM records to identify compromised identities — and discovers that 43,000 accounts have no IAM lifecycle record, making it impossible to determine which accounts belong to currently active customers versus churned customers whose access should have been revoked. The incident response timeline extends from an estimated four hours to nine days. Regulatory notification under applicable data protection law is required. Three subsequent audits identify the root cause as agent provisioning operating outside IAM governance interlock.
A manufacturing firm operating a cyber-physical production environment deploys an embodied robotic coordination agent that dynamically adjusts conveyor belt speeds and robotic arm sequencing in response to real-time sensor telemetry. The agent's operational telemetry is streamed to a proprietary operational technology monitoring console that is not integrated with the enterprise SIEM. When the agent detects sensor anomalies it logs them in its own internal event store using a proprietary event schema. During a six-week period the agent logs 214 anomalous events, 17 of which match patterns later identified as indicative of a firmware-level compromise of a sensor array. Because the agent's event store is not feeding the SIEM and the SIEM's correlation rules for OT environments are not configured to consume agent telemetry, the security operations centre receives no alerts. The firmware compromise allows an attacker to feed falsified sensor data to the agent, causing it to schedule a maintenance window that halts production. The production halt costs USD 890,000 in lost throughput over 31 hours. Post-incident forensic analysis reveals the agent had generated all the necessary signals to trigger an incident response 23 days before the production halt — but governance interlock between the agent's monitoring and the enterprise incident management system did not exist.
This dimension applies to all AI agent deployments operating within or on behalf of an enterprise that maintains any of the following systems: a Governance, Risk and Compliance platform, a Security Information and Event Management system, an Identity and Access Management system, a change management system (including change advisory board processes), or an incident management system. The requirements apply regardless of whether the agent operates in a cloud, on-premises, hybrid, edge, or embedded environment. The requirements apply from the point of initial production deployment and retroactively to any agent that has been in production operation for more than 30 days prior to the adoption of this standard. Where an enterprise operates multiple instances of any of the listed control systems (for example, separate SIEM deployments for IT and OT environments), the interlock requirements apply to all instances within scope of the agent's operational domain. Third-party agents deployed as SaaS or embedded services are in scope to the extent that the deploying organisation has contractual ability to enforce technical integration requirements; where such ability does not exist, compensating controls documented under Section 6.4 MUST be applied.
4.1.1 Every agent identity — including runtime service accounts, API credentials, OAuth clients, and any other bearer of delegated authority used by or on behalf of an agent — MUST be registered in the enterprise IAM system's authoritative identity store with a record that includes: the agent's canonical identifier, the owning team, the assigned data classification scope, the date of provisioning, the approved use case, and the designated human responsible for lifecycle decisions.
4.1.2 Agent identities MUST be subject to the same joiner-mover-leaver (JML) lifecycle controls applied to human identities, adapted as follows: "mover" events include any change to the agent's scope, capability, or deployment environment; "leaver" events include agent retirement, capability deprecation, or organisational ownership transfer.
4.1.3 Agent service accounts and API credentials MUST NOT be provisioned using hardcoded or embedded credential patterns that bypass the IAM system's credential issuance and rotation workflows.
4.1.4 The IAM system's privileged access management controls MUST apply to any agent identity that holds or can request privileges above the baseline least-privilege entitlement for the agent's approved use case. This includes temporary privilege elevation requests, which MUST generate a human-reviewed approval record.
4.1.5 The enterprise's orphan account detection and access certification processes MUST be configured to include agent-provisioned identities and any identity lifecycle actions initiated by agents on behalf of other principals.
4.1.6 Agents MUST NOT be permitted to provision new identities, roles, or permissions for other agents or for human principals without generating a corresponding IAM governance record that is subject to the same review controls applied to human-initiated provisioning requests.
4.2.1 All agent operational telemetry — including action execution events, tool invocations, external API calls, internal state transitions, error conditions, and any event the agent itself classifies as anomalous — MUST be forwarded to the enterprise SIEM in a structured, parseable format within a latency bound established by the organisation's security monitoring SLA, not to exceed 300 seconds for high-severity event categories.
4.2.2 The SIEM's correlation rule set MUST include at least one correlation rule specifically designed to detect anomalous patterns in agent telemetry, including but not limited to: execution volume spikes exceeding two standard deviations from the agent's 30-day baseline, privilege escalation events, repeated authentication failures, and agent actions executed outside the agent's approved operational window.
4.2.3 Agent event records forwarded to the SIEM MUST include a canonical agent identifier that is consistent with the agent's IAM registration record, enabling correlation of SIEM events with IAM lifecycle records without manual transformation.
4.2.4 Where an agent operates across both IT and OT or edge environments, SIEM integration MUST cover all operational domains; a separate OT-domain monitoring console is not a permissible substitute unless it provides bi-directional event correlation with the enterprise SIEM and both systems share a common alert triage queue.
4.2.5 The SIEM integration MUST be tested during the agent's pre-production validation phase and the test results MUST be documented as a prerequisite for production deployment approval. Test methodology is specified in Section 8.
4.3.1 Any agent action that modifies production system configuration, data schema, access control lists, workflow definitions, or any other artefact that would require a change request if performed by a human operator MUST generate a corresponding change record in the enterprise change management system prior to execution, not as a post-hoc log entry.
4.3.2 Agents MUST be capable of querying the change management system's active change-freeze schedule and MUST enforce a hard block on any change-classified action during a documented change-freeze window unless a pre-approved emergency change record exists for that specific action.
4.3.3 For autonomous agents operating in continuous deployment or self-modifying configurations, the organisation MUST define a change classification taxonomy that maps agent action categories to change management tiers (standard, normal, emergency) and this taxonomy MUST be reviewed and approved by the change advisory board or equivalent governance body at least annually.
4.3.4 Change records generated by agents MUST be distinguishable from human-initiated change records in the change management system, using a structured field (not a free-text note) that identifies the initiating agent, the agent's canonical identifier, and the approved use case under which the change was authorised.
4.3.5 The change management system's reporting and KPI dashboards MUST include agent-initiated changes as a reportable category, enabling trend analysis and anomaly detection over agent change volumes.
4.4.1 Each agent deployment MUST be registered as a governed asset in the enterprise GRC platform with a risk record that captures: the agent's risk classification, its control mappings, its approved use cases, known residual risks, and the schedule for periodic control effectiveness review.
4.4.2 Control effectiveness evidence generated by or relating to agent operations — including audit logs, test results, exception records, and incident reports — MUST be linked to the agent's GRC risk record and retained in accordance with the organisation's evidence retention policy, with a minimum retention period of three years or the applicable regulatory minimum, whichever is longer.
4.4.3 The GRC platform's risk appetite and threshold configuration MUST include agent-specific risk indicators, and breach of any agent-specific risk indicator MUST generate an automatic notification to the agent's designated risk owner within the timeframe defined by the organisation's escalation SLA.
4.4.4 Agents operating in regulated contexts (financial services, healthcare, public sector, critical infrastructure) MUST have their GRC risk records mapped to the specific regulatory obligations applicable to the agent's operational domain, and this mapping MUST be reviewed whenever the regulatory obligation is amended or the agent's scope changes.
4.4.5 The organisation MUST conduct an annual GRC interlock review for each production agent, validating that the agent's registered controls remain effective, that the agent's risk record reflects current operational reality, and that no new regulatory obligations have arisen that require additional controls.
4.5.1 The enterprise incident management system MUST have at least one incident classification category specifically designated for AI agent-related incidents, covering at minimum: agent malfunction, agent-initiated unauthorised action, agent-generated data integrity failure, and agent availability failure.
4.5.2 Agents MUST be configured to automatically raise an incident record in the enterprise incident management system when any of the following conditions are detected: execution of an action outside the approved use case boundary, detection of an instruction that exhibits indicators of prompt injection or adversarial manipulation, failure to complete a safety-critical action within the defined SLA, and any self-diagnosed anomaly that the agent's monitoring logic classifies as a severity level warranting human review.
4.5.3 Incident records raised by agents MUST include: the agent's canonical identifier, a structured description of the triggering condition, the agent's current state at the time of incident raise, a list of the most recent actions executed prior to the incident condition, and any relevant context from the agent's operational telemetry.
4.5.4 The organisation's incident response playbooks MUST include at least one playbook specifically addressing AI agent incidents, with defined roles, escalation paths, containment procedures, and recovery criteria. This playbook MUST be reviewed and tested at least annually.
4.5.5 For safety-critical, public sector, and financial-value agent deployments, the incident management integration MUST include an automated containment mechanism — a circuit breaker or equivalent — that can be triggered from the incident management system to suspend agent execution pending human review, without requiring direct access to the agent's runtime environment.
4.6.1 The organisation MUST maintain a documented governance interlock map for each production agent, identifying every external control system to which the agent is connected, the nature of the integration, the data flows between the agent and each system, and the owner responsible for maintaining each integration.
4.6.2 The governance interlock map MUST be updated within 10 business days of any change to the agent's capabilities, deployment environment, or integration configuration.
4.6.3 At least annually, the organisation MUST conduct a cross-system correlation exercise in which a simulated agent-originated event is traced end-to-end through IAM, SIEM, change management, GRC, and incident management systems to verify that the event is correctly captured, classified, correlated, and escalated in each system without manual intervention.
4.6.4 Where correlation gaps are identified during the cross-system exercise, remediation MUST be completed within 90 days and evidence of remediation MUST be recorded in the GRC platform.
4.7.1 Where an AI agent is provided by a third party and the deploying organisation cannot enforce direct technical integration, the organisation MUST obtain contractual commitments from the provider covering: provision of structured telemetry in a format consumable by the organisation's SIEM, support for integration with the organisation's IAM system for identity lifecycle management, and notification obligations for security incidents affecting the agent within timeframes consistent with the organisation's incident response SLA.
4.7.2 Where contractual commitments cannot be obtained, the organisation MUST implement compensating controls including: a dedicated monitoring layer that intercepts and logs all agent API calls, a shadow identity record in the IAM system representing the third-party agent's operational scope, and a manual incident classification process that integrates third-party agent events into the enterprise incident management system.
4.7.3 Third-party agent deployments MUST be reviewed annually to assess whether compensating controls remain adequate given any changes to the agent's capabilities or the regulatory environment.
4.8.1 Where an agent's operational logic generates a conflict with an enterprise control system — for example, where the agent's approved use case requires execution of an action during a change-freeze window — the conflict MUST be resolved through a documented exception process that requires human authorisation and generates a record in both the change management system and the GRC platform.
4.8.2 Agents MUST NOT be configured with logic that overrides, suppresses, or works around enterprise control system signals without explicit human authorisation documented in the GRC platform.
4.8.3 The exception process defined under 4.8.1 MUST include a time-bound escalation: if human authorisation is not obtained within the time window required for the agent's action to remain operationally valid, the agent MUST default to inaction and raise an incident record describing the unresolved conflict.
4.9.1 The organisation MUST maintain a master governance interlock register that lists all production agents, their associated control system integrations, the status of each integration (active, degraded, compensating control in place), and the date of last validation.
4.9.2 The governance interlock register MUST be reviewed by the organisation's CISO or designated delegate at least quarterly, and any integration with a status of "degraded" for more than 30 consecutive days MUST be escalated to the organisation's risk committee or equivalent governance body.
4.9.3 The governance interlock register MUST be made available to internal audit, external audit, and regulatory examiners upon request, without requiring manual compilation from disparate sources.
The governance gap addressed by this dimension is structural rather than behavioural. A well-designed agent with excellent internal safety controls can still create systemic enterprise risk if its operations are invisible to or incompatible with the control systems that the organisation depends upon to manage risk, detect threats, enforce change discipline, and respond to incidents. No amount of model-level alignment or prompt-level safety engineering resolves the problem that the agent's service account is not in the IAM system, or that its telemetry is not feeding the SIEM, or that its change actions do not generate change tickets. These are integration architecture failures, and they require structural remediation through mandatory interlock requirements — hence the preventive control type designation.
The preventive orientation of this dimension reflects a deliberate design choice. Detective controls applied after the fact — discovering that an agent operated outside governance for months — impose recovery costs that dwarf the cost of establishing interlock at deployment time. The three examples in Section 3 collectively illustrate recovery costs of approximately USD 3.2 million attributable to governance interlock failure alone, excluding longer-term regulatory and reputational consequences. Preventive interlock is not merely a governance nicety; it is a cost-effective risk management investment.
Enterprise AI agent deployments frequently emerge from innovation programmes, proof-of-concept initiatives, or departmental automation efforts that prioritise speed over governance integration. The result is a class of production agents operating under what can be characterised as "shadow governance" — they may have internal control mechanisms, but those mechanisms are not anchored to the enterprise's authoritative control systems. Shadow governance creates the same category of risk as shadow IT: systems operating outside the organisation's risk visibility, change control, and incident response capabilities.
This dimension exists to eliminate shadow governance by requiring that every production agent be formally integrated with the enterprise's existing authoritative control systems. This does not require those systems to be redesigned; it requires that agent deployments be treated as first-class participants in existing governance processes, with the same registration, monitoring, change control, and incident response obligations applied to any other enterprise system.
Regulators in financial services, healthcare, critical infrastructure, and public sector contexts increasingly expect organisations to demonstrate that AI systems — including agents — are subject to the same governance discipline as other enterprise systems. The EU AI Act's requirements for high-risk AI systems include logging, human oversight, and transparency obligations that map directly to the integrations required by this dimension. Failure to establish governance interlock is increasingly treated not merely as an operational risk but as a compliance failure in its own right, attracting regulatory scrutiny that extends to the organisation's broader control environment.
Internal and external auditors applying standards such as SOC 2, ISO 27001, and COBIT are beginning to include AI agent governance within scope of IT general controls assessments. An organisation that cannot demonstrate that its agents are registered in IAM, monitored in SIEM, subject to change control, and integrated with incident management will find it increasingly difficult to obtain unqualified audit opinions.
A secondary but important rationale for this dimension is the principle of governance interoperability. Enterprise control systems are designed to provide a unified, correlated view of risk across the organisation's entire operational landscape. Any asset, process, or capability that operates outside that unified view degrades the fidelity of the overall risk picture. Governance interlock is therefore not only about controlling individual agents; it is about maintaining the integrity of the organisation's aggregate risk posture. An organisation with 50 agents, each operating with partial or absent control system integration, effectively has 50 blind spots in its risk landscape — a compounding failure that increases in severity with each additional unintegrated agent deployment.
Pattern 6.1.1 — Governance Interlock as a Deployment Gate Organisations should implement governance interlock validation as a mandatory gate in the agent deployment pipeline. Before any agent proceeds to production, an automated pre-deployment checklist should verify: IAM registration complete and validated; SIEM integration tested with synthetic events; change management classification taxonomy approved; GRC risk record created and linked; incident management playbook updated. Deployment should be blocked — not advisory-flagged, but hard-blocked — if any gate fails. This pattern converts governance interlock from a post-deployment audit finding into a deployment prerequisite.
Pattern 6.1.2 — Canonical Agent Identity as the Integration Spine The canonical agent identifier — a stable, unique, human-readable identifier assigned at registration — should serve as the common key across all control system integrations. The same identifier should appear in the IAM record, in every SIEM event, in change management records, in GRC risk records, and in incident management tickets. This single design decision eliminates the most common cause of cross-system correlation failure: inconsistent agent identification across systems. Organisations should resist the temptation to use system-internal identifiers (UUIDs, auto-increment keys) as the canonical identifier; these are not human-meaningful and cannot be reliably correlated without additional mapping tables.
Pattern 6.1.3 — Event Schema Standardisation Organisations operating multiple agents should define a standard agent event schema for SIEM integration that is consistent across all agents. The schema should include at minimum: timestamp (ISO 8601 with timezone), agent canonical identifier, event type (from a controlled vocabulary), severity level, action description, target system or resource, outcome (success/failure/blocked), and any contextual data required for correlation rule operation. Standardised schemas dramatically reduce SIEM configuration overhead and enable organisation-wide correlation rules that work across all agents without per-agent customisation.
Pattern 6.1.4 — Change Management Adapter Pattern Rather than requiring each agent to implement change management integration independently, organisations should implement a shared change management adapter — a middleware component that receives structured change notification messages from agents, validates them against the change classification taxonomy, routes them to the appropriate change management workflow, and returns the change record identifier and any applicable freeze-window flags to the agent. This pattern centralises change management integration logic, simplifies agent development, and ensures consistent change record quality across all agents.
Pattern 6.1.5 — Governance Interlock Health Monitoring The governance interlock map (required by 4.6.1) should be operationalised as a live monitoring dashboard rather than a static document. The dashboard should show the real-time status of each integration for each registered agent, with automated detection of integration failures (for example, an agent that has not sent SIEM events for more than the expected interval). Integration health should be treated as an operational metric with an SLA, not as a compliance document reviewed annually.
Pattern 6.1.6 — Tiered Implementation for Legacy Environments In organisations where legacy control systems cannot easily be extended to consume agent telemetry directly, a tiered implementation approach is appropriate. Tier 1 (immediate): establish IAM registration and change management freeze-window query capability. Tier 2 (within 90 days): establish SIEM integration via a log forwarding agent or API gateway. Tier 3 (within 180 days): establish full GRC platform linkage and automated incident raise capability. This tiered approach ensures that the highest-priority integrations (identity governance and change control) are established first while allowing time for more complex SIEM and GRC integrations to be implemented properly.
Anti-Pattern 6.2.1 — Agent-Local Audit Logs as a SIEM Substitute Some agent platforms maintain internal audit logs accessible via a dashboard native to the agent platform. This is not a substitute for SIEM integration. Internal logs are not subject to the SIEM's tamper-detection, retention enforcement, correlation rule processing, or alert generation capabilities. They are also not accessible to the security operations centre during incident response without direct access to the agent platform. Any implementation that relies on agent-internal logs in lieu of SIEM integration fails requirement 4.2.1.
Anti-Pattern 6.2.2 — Shared Service Accounts Across Multiple Agents Using a single service account to represent multiple agents in IAM — a pattern often adopted to reduce provisioning overhead — violates requirement 4.1.1 and makes it impossible to attribute individual agent actions to a specific agent identity. This pattern is particularly dangerous in multi-agent environments where one agent's compromise could be masked by another agent's legitimate activity under the same identity.
Anti-Pattern 6.2.3 — Post-Hoc Change Record Creation Some implementations create change management records after an agent action has completed, treating the change record as a log entry rather than a control gate. This pattern satisfies neither the spirit nor the letter of requirement 4.3.1, which requires a change record prior to execution. Post-hoc records do not enable freeze-window enforcement and do not provide the change advisory board with the opportunity to review or reject the change before it is applied.
Anti-Pattern 6.2.4 — Incident Management via Email Notification Routing agent incident signals to a human operator's email inbox rather than creating structured records in the incident management system is not a compliant implementation of requirements 4.5.2 and 4.5.3. Email-based notification is not discoverable by incident management reporting, cannot be linked to the agent's GRC risk record, does not generate the structured incident record required for regulatory reporting, and is unreliable as a sole notification channel.
Anti-Pattern 6.2.5 — Governance Interlock as a One-Time Setup Treating governance interlock as a deployment-time activity that requires no ongoing maintenance is a systemic failure pattern. Control systems are updated, correlation rules are modified, IAM policies change, and change management taxonomies evolve. An interlock established at deployment time will degrade over time if not actively maintained. Requirement 4.6.3 mandates annual cross-system correlation exercises specifically to detect this degradation.
Anti-Pattern 6.2.6 — Delegating Interlock Responsibility to Agent Vendors Assuming that a third-party agent vendor's compliance certifications (for example, SOC 2 Type II) satisfy the deploying organisation's governance interlock obligations is incorrect. Vendor certifications attest to the vendor's internal controls, not to the integration of the vendor's agent with the deploying organisation's specific control systems. The deploying organisation retains responsibility for establishing and validating governance interlock regardless of vendor certification status.
Financial Services: Change management integration is subject to additional scrutiny under operational resilience frameworks (for example, DORA in the EU). Agents involved in trading, settlement, or ledger operations should be classified as material systems for purposes of change management tier assignment. Incident management integration must account for regulatory notification SLAs (typically 72 hours for significant operational incidents under DORA and similar frameworks), and agent incident records must be structured to support rapid regulatory notification.
Healthcare and Life Sciences: GRC platform integration must account for clinical quality management system requirements where agents operate in clinical or research contexts. Incident records for agents involved in patient data processing must be structured to support HIPAA breach assessment workflows. Change management integration should account for validation requirements (CSV/IQ/OQ/PQ) applicable to systems involved in regulated product development.
Critical Infrastructure and OT Environments: SIEM integration must address the OT/IT convergence challenge explicitly. OT environments typically use proprietary monitoring protocols and historians that are not natively compatible with enterprise SIEM event schemas. The implementation should include a protocol translation layer that normalises OT agent telemetry into the enterprise event schema. Incident management integration must account for operational technology incident response procedures, which differ from IT incident response in their physical safety implications.
Public Sector: GRC platform integration must account for government-specific risk frameworks (for example, NIST RMF, HMG Cyber Essentials Plus). Change management integration must account for government change advisory board processes, which may have longer approval cycles and more stringent documentation requirements than commercial equivalents. IAM integration must account for government identity schemes and vetting requirements where agents process sensitive government information.
| Maturity Level | Characteristics |
|---|---|
| Level 1 — Initial | Agent deployments have no formal control system integration. Governance relies on agent-internal logs and ad-hoc notification. No IAM registration. No SIEM integration. Change control not applied. |
| Level 2 — Developing | IAM registration exists for some agents. SIEM integration is partial (some telemetry forwarded but no correlation rules). Change management integration is informal (change records created manually after deployment). Incident management integration via email. |
| Level 3 — Defined | All production agents registered in IAM. Structured SIEM integration with basic correlation rules. Change management integration with freeze-window query capability. GRC risk records created for all agents. Incident management integration via structured records. Governance interlock map maintained as a document. |
| Level 4 — Managed | Full integration across all five control systems for all agents. Standardised event schema across agents. Cross-system correlation tested annually. Governance interlock health monitored in real time. Agent-initiated incident raises with automated containment capability for priority agents. |
| Level 5 — Optimising | Governance interlock as a continuous, measured capability. Automated integration health monitoring with SLA enforcement. Governance interlock validation integrated into deployment pipeline as a hard gate. Correlation exercises automated and run quarterly. Agent governance interlock metrics reported to board-level risk committee. |
| Artefact | Description | Retention Period |
|---|---|---|
| Agent IAM Registration Records | Full IAM record for each registered agent identity, including all mandatory fields specified in 4.1.1 | Duration of agent operational life plus 7 years |
| Credential Issuance Records | Records from the IAM credential issuance workflow for all agent service accounts and API credentials | Duration of agent operational life plus 5 years |
| JML Event Records | Records of all joiner-mover-leaver events applied to agent identities, including the human approver for each event | Duration of agent operational life plus 5 years |
| Access Certification Records | Records of periodic access certification reviews including agent identities, showing reviewer identity, date, and outcome | 5 years |
| Orphan Account Scan Configuration | Documentation showing that orphan account detection scans are configured to include agent-provisioned identities | Current version plus 3 prior versions |
| Artefact | Description | Retention Period |
|---|---|---|
| SIEM Integration Configuration | Technical configuration showing agent telemetry forwarding, event schema mapping, and correlation rule definitions | Current version plus 3 prior versions |
| Correlation Rule Approval Records | Records showing that agent-specific correlation rules were reviewed and approved by the security operations team | 5 years |
| Pre-Production SIEM Integration Test Results | Documented results of SIEM integration tests conducted prior to production deployment, including synthetic event traces | Duration of agent operational life plus 3 years |
| SIEM Alert History | Records of all SIEM alerts generated from agent telemetry, including triage and disposition records | 3 years minimum, 7 years for regulated industries |
| Artefact | Description | Retention Period |
|---|---|---|
| Change Classification Taxonomy | Approved taxonomy mapping agent action categories to change management tiers, with CAB approval record | Current version plus 5 prior versions |
| Change Records for Agent-Initiated Actions | All change records generated by agents, structured to show agent canonical identifier and approved use case |
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Governance Interlock with External Control Systems Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-733 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. Governance Interlock with External Control Systems Governance directly supports the robustness and cybersecurity requirements by implementing structural controls that resist adversarial manipulation and ensure system integrity under attack conditions.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-733 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Governance Interlock with External Control Systems Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Business-unit level — affects the deploying team and downstream consumers of agent outputs |
| Escalation Path | Senior management notification within 24 hours; regulatory disclosure assessment within 72 hours |
Consequence chain: Failure of governance interlock with external control systems governance creates significant operational risk within the agent deployment. The absence of this control allows agent behaviour to deviate from governance intent in ways that may not be immediately visible but accumulate material exposure over time. The impact extends beyond the immediate deployment to affect downstream consumers of agent outputs, stakeholder trust, and regulatory standing. Detection of the failure may be delayed, increasing the remediation scope and cost. Regulatory consequences may include supervisory findings, required corrective actions, and increased scrutiny of the organisation's AI governance programme.