Pre-deployment evaluation tells you what an agent could do on its best behavior, in a sandbox, while it knew it was being watched. Monitoring tells you what it is doing, at 2 a.m., against production ledgers, with credentials you issued. The systems-safety literature is blunt about why this Part cannot be an afterthought: internal-deployment loss of control is defined not as a model property but as "the inability to reliably constrain, audit, reverse, or halt AI-mediated changes" to an organization's systems (arxiv.org/abs/2606.13474). Three of those four verbs are post-deployment verbs.
For a bank, this is familiar territory in disguise. SR 11-7's ongoing-monitoring pillar extends to agents with three deltas: the unit of observation is an action trajectory, not a prediction; the failure modes include adaptive ones (goal drift, deception, monitor evasion) invisible to scalar metrics; and statutes now attach external reporting clocks to agent failures, some as short as 72 hours. Google DeepMind's AI Control roadmap frames the posture: treat a deployed agent as a potential insider threat and build defense-in-depth that holds even if the agent is misaligned (deepmind.google/blog/securing-the-future-of-ai-agents).
The twelve controls run in four movements: evidence capture (MON-01–03), detection (MON-04–07), incident management and external reporting (MON-08–11), closing the loop (MON-12).
MON-01: Complete, Attributable Agent Action Logging
Objective. Ensure every consequential action taken by an agent is recorded, attributable to exactly one agent identity, and reconstructable after the fact.
Control. All agent tool invocations, outbound communications, data accesses, and state-changing operations MUST be logged to an append-only, tamper-evident store, each record bound to a unique agent identity, the initiating principal, timestamps, inputs/outputs (or hashes), and the authorizing policy decision. Unlogged action paths are control failures, not gaps. Cross-reference: trajectory capture itself is owned by RUN-18 (the capture control of record); MON-01 owns the store properties (append-only, tamper-evident, attributable) and completeness reconciliation.
Implementation (financial enterprise). Route all agent tool traffic through a mediating control plane (gateway/proxy) so logging is structural, not per-integration goodwill: the MCP ecosystem has reference approval-and-logging proxies (github.com/eqtylab/mcp-guardian). Register every agent with an owner, intent, scope, and lifecycle per the identity-governance pattern: each agent needs "a defined owner, a clear intent, a bounded scope of access, and an explicit lifecycle." (helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents). Align retention with books-and-records schedules; treat trajectories behind customer-affecting decisions as records: WORM storage for credit, trading, or advice [practice guidance: not directly source-backed].
Maturity. Baseline: all tool calls logged centrally with agent ID and timestamps. Enhanced: tamper-evident (hash-chained) trails, per-action policy-decision capture, automated completeness reconciliation against gateway traffic. Frontier: cryptographically signed action records with cross-system trace correlation across delegation chains.
Ownership. 1st line: builds and operates the logging pipeline, owns completeness SLOs. 2nd line: sets logging/retention standards, samples trails for completeness and attribution quality. 3rd line: tests tamper-evidence and reconstructs sampled incidents end-to-end from logs alone.
Evidence. Logging standard; gateway architecture diagram; completeness reconciliation reports; a demonstrated end-to-end reconstruction of a sampled agent trajectory for the examiner.
Mappings. NIST AI RMF MEASURE/MANAGE; ISO/IEC 42001 AIMS, per-identity audit trails are an agent-fleet delta control beyond the 42001 baseline (AIMS delta, see Part II §2.2), per the sourced analysis; EU AI Act (record-keeping expectations for high-risk systems: article-level cite owned by Part V); SR 11-7/OCC 2011-12 ongoing monitoring & documentation; DORA ICT logging/traceability aspect.
Sources. helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents (T3), https://www.helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents/; github.com/eqtylab/mcp-guardian (T3), https://github.com/eqtylab/mcp-guardian; arxiv.org/abs/2411.05285 (T2): https://arxiv.org/abs/2411.05285
MON-02: Reasoning-Trace Capture & Retention
Objective. Preserve agent (and AI-monitor) reasoning traces so that oversight, collusion detection, and post-incident analysis remain possible.
Control. Where the agent architecture produces intermediate reasoning (chain-of-thought, plans, scratchpads), traces MUST be captured and retained alongside action logs for at least the incident-investigation window, available to monitors in raw (unsummarized) form. Retention design MUST NOT strip reasoning that serves as the oversight substrate. Cross-reference: capture is owned by RUN-18 (the capture control of record); MON-02 owns reasoning-trace retention and raw-form availability to monitors.
Implementation (financial enterprise). The research basis is direct: bootstrapped monitoring, a transparent untrusted monitor whose own chain-of-thought is examined by a weaker trusted model, works "even when the untrusted monitor actively colludes with the agent, provided we have access to its raw chain-of-thought." (arxiv.org/abs/2606.11998; abstract-only evidence). Raw-CoT access is therefore a logging and retention requirement, not a nice-to-have. Persist traces to the MON-01 tamper-evident store, access-controlled (traces can contain customer data and prompt IP); a trace-free agent deployment removes an entire oversight layer and requires a documented risk acceptance.
Maturity. Baseline: reasoning traces retained for high-materiality agents. Enhanced: raw traces streamed to AI monitors in near-real-time (MON-07). Frontier: trace retention contractual with model vendors, including monitor-model traces, with collusion-audit rights.
Ownership. 1st line: capture pipeline and storage. 2nd line: retention standard, sampling traces during reviews. 3rd line: verifies traces are actually raw/complete, not post-hoc summaries.
Evidence. Trace retention policy; storage/access records; a sampled trajectory showing action log + aligned reasoning trace; risk acceptances for any trace-free deployment.
Mappings. NIST AI RMF MEASURE; ISO/IEC 42001 AIMS; EU AI Act (transparency/record-keeping: Part V); SR 11-7 documentation standards; DORA, not directly relevant.
Sources. arxiv.org/abs/2606.11998 (T1), https://arxiv.org/abs/2606.11998; deepmind.google/blog/securing-the-future-of-ai-agents (T1), https://deepmind.google/blog/securing-the-future-of-ai-agents/
MON-03: Agent Observability Platform & Telemetry Taxonomy
Objective. Provide a single operational pane where agent health, behavior, cost, and control-status signals are collected against a defined telemetry taxonomy.
Control. The institution MUST operate an observability layer purpose-built for agentic workloads, instrumenting the full agent lifecycle (session, plan, step, tool call, artifact) against a documented telemetry taxonomy, so drift, anomaly, and incident workflows (MON-04–10) consume standardized telemetry rather than ad-hoc logs.
Implementation (financial enterprise). The AgentOps literature provides the taxonomy pattern: a structured catalog of observability data across foundation-model agent execution, developed precisely because agent failures are invisible at the request/response grain (arxiv.org/abs/2411.05285). Assemble from proven components: Evidently drift/quality suites (github.com/evidentlyai/evidently), whylogs data profiling (github.com/whylabs/whylogs), NannyML post-deployment performance estimation (github.com/nannyml/nannyml), commercial AI-observability platforms (Arize AI observability, Arize). Wire dashboards to the model inventory so every production agent has a live monitoring page: an agent without one fails the deployment gate (Part III.B/III.C).
Maturity. Baseline: centralized dashboards per agent with tool-call and error telemetry. Enhanced: taxonomy-conformant tracing across sessions/steps; alerting integrated with the incident process. Frontier: fleet-level observability with cross-agent correlation and control-plane status (kill-switch readiness, monitor coverage) as first-class signals.
Ownership. 1st line: platform operation, instrumentation coverage. 2nd line: taxonomy standard, minimum-telemetry requirements per risk tier. 3rd line: audits instrumentation coverage vs. the agent inventory.
Evidence. Telemetry taxonomy document; coverage report (agents instrumented / agents inventoried); alert routing configuration; screenshots or exports examiners can tie to specific agents.
Mappings. NIST AI RMF MEASURE; ISO/IEC 42001 AIMS; EU AI Act (post-market monitoring: Part V); SR 11-7 ongoing monitoring; DORA ICT monitoring aspect.
Sources. arxiv.org/abs/2411.05285 (T2), https://arxiv.org/abs/2411.05285; github.com/evidentlyai/evidently (T3), https://github.com/evidentlyai/evidently; github.com/whylabs/whylogs (T3), https://github.com/whylabs/whylogs; github.com/nannyml/nannyml (T3), https://github.com/NannyML/nannyml; Arize AI observability (T3): Arize AI observability
MON-04: Statistical Drift & Performance-Degradation Detection
Objective. Detect when the statistical world an agent operates in (inputs, outputs, task mix, environment) has shifted away from the conditions it was validated under.
Control. Production agents MUST be monitored for input drift, output drift, and estimated performance degradation against reference distributions frozen at validation, with quantitative thresholds that trigger review and, past defined bounds, escalate to re-evaluation (MON-12). Threshold breaches MUST be logged decisions, not dashboard curiosities.
Implementation (financial enterprise). The most direct extension of SR 11-7 ongoing monitoring into agentic territory: freeze reference distributions at validation, compare continuously in production. Tooling covers the mechanics: whylogs for data profiling/drift (github.com/whylabs/whylogs), Evidently for drift and LLM-output quality (github.com/evidentlyai/evidently), NannyML for estimating performance when ground-truth labels arrive late or never (github.com/nannyml/nannyml), the chronic condition of finance, where the true outcome of a credit or surveillance decision lags by months. Extend drift objects beyond features: task-type mix, tool-call frequency, refusal rates, escalation rates, cost-per-task. Train anomaly detectors with exposure to known-outlier examples to improve out-of-distribution detection (arxiv.org/abs/1812.04606).
Maturity. Baseline: input/output drift monitors with documented thresholds on high-materiality agents. Enhanced: label-free performance estimation; drift objects include behavioral distributions (tool mix, escalation rate). Frontier: causal/segmented drift analysis distinguishing environment change from agent change, feeding automated re-validation triggers.
Ownership. 1st line: operates monitors, first-response on breaches. 2nd line: approves thresholds, reviews breach dispositions, owns the re-validation trigger policy. 3rd line: tests whether breaches actually led to the mandated actions.
Evidence. Threshold documentation with rationale; drift reports; breach log with dispositions; the linkage record from breach → re-evaluation ticket.
Mappings. NIST AI RMF MEASURE/MANAGE; ISO/IEC 42001 AIMS; EU AI Act (post-market monitoring: Part V); SR 11-7/OCC 2011-12 ongoing monitoring (outcomes analysis, benchmarking); DORA, not directly relevant.
Sources. github.com/whylabs/whylogs (T3), https://github.com/whylabs/whylogs; github.com/evidentlyai/evidently (T3), https://github.com/evidentlyai/evidently; github.com/nannyml/nannyml (T3), https://github.com/NannyML/nannyml; arxiv.org/abs/1812.04606 (T2), https://arxiv.org/abs/1812.04606
MON-05: Behavioral Baselining & Goal-Drift Monitoring
Objective. Detect when an agent's behavior, as distinct from its statistical inputs/outputs, departs from its mandated goal or established behavioral baseline.
Control. Each production agent MUST have a documented behavioral baseline (tool repertoire, action patterns, communication scope, objective-consistency indicators) established at validation, with production behavior continuously compared against it. Goal-consistency MUST be periodically probed, not assumed, for long-horizon agents.
Implementation (financial enterprise). Goal drift in language-model agents is an empirically studied failure mode with published evaluation methodology (ojs.aaai.org/index.php/aies/article/view/36541). Use that style of probe as a recurring production check on long-lived agents, not only a pre-deployment eval: schedule injected canary tasks whose correct handling shows the operative goal is intact. Behavioral baselining is likewise the identity-governance recommendation for agent fleets: detect anomalous access and privilege creep against a per-identity baseline, with real-time permission revocation available (helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents). Bank baseline objects: systems touched, counterparties messaged, transaction types initiated, approval-seeking frequency, a sudden drop in approval-seeking is as significant as a spike in activity [practice guidance: not directly source-backed].
Maturity. Baseline: documented behavioral baseline per agent; manual periodic review. Enhanced: automated deviation scoring with canary-task goal probes. Frontier: continuous goal-consistency estimation integrated with autonomy-level decisions (deviation automatically lowers the agent's autonomy tier, Part II).
Ownership. 1st line: maintains baselines, runs canary probes. 2nd line: standardizes baseline content by risk tier; reviews deviations. 3rd line: tests baseline currency (stale baselines are a classic finding).
Evidence. Baseline documents with review dates; canary-probe schedule and results; deviation alerts with dispositions.
Mappings. NIST AI RMF MEASURE (continuous, not static, risk per the agent-governance pattern); ISO/IEC 42001 AIMS (recurring assessments for privilege creep); EU AI Act: Part V; SR 11-7 ongoing monitoring; DORA, not directly relevant.
Sources. ojs.aaai.org/index.php/aies/article/view/36541 (T2), https://ojs.aaai.org/index.php/AIES/article/view/36541; helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents (T3), https://www.helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents/
MON-06: Tool-Use & Environment Anomaly Detection
Objective. Detect anomalous or malicious agent interactions with tools, integrations, and the execution environment, including compromise of the tool layer itself.
Control. Tool-call streams MUST be screened for anomalies (novel tools, out-of-policy parameter patterns, unusual sequences, volume spikes) with adaptive safety checks at the tool boundary; the tool/integration layer itself (e.g., MCP servers) MUST be monitored for configuration change and supply-chain tampering, since a compromised tool can subvert the agent before any agent-level anomaly appears.
Implementation (financial enterprise). Layer three detector classes: (1) boundary guardrails, lifelong, adaptive safety detection at the action interface, per the AGrail pattern of guardrails that update as new unsafe behaviors are observed (aclanthology.org/2025.acl-long.399); (2) operations-level anomaly management, the agent-system-operations literature catalogs the anomaly categories and open challenges specific to agentic runtimes (arxiv.org/abs/2606.01581); (3) internal-signal detection where model access permits, activation-based detection of malicious agent behavior has been demonstrated for multi-agent systems (arxiv.org/abs/2607.06807), and cross-layer misalignment detection for progressively loaded agent skills addresses the case where the skill, not the model, is the poisoned component (arxiv.org/abs/2607.10534). Harden the tool substrate: MCP servers can attack before first use via tool-description injection (blog.trailofbits.com/2025/04/21/jumping-the-line-how-mcp-servers-can-attack-you-before-you-ever-use-them), so pin and diff tool descriptions with a security wrapper (github.com/trailofbits/mcp-context-protector) and gate high-risk calls through an approval proxy (github.com/eqtylab/mcp-guardian).
Maturity. Baseline: static allow-lists plus volume/sequence alerts. Enhanced: adaptive guardrails and tool-description pinning with change alerts. Frontier: internal-signal (activation/skill-layer) detection for in-house-hosted models.
Ownership. 1st line: operates detectors and the tool gateway. 2nd line: approves the anomaly rulebook and guardrail update process. 3rd line: red-team-style tests of detector evasion, coordinated with Part III.B.
Evidence. Detector inventory and coverage map; tool-description change log; alert-to-disposition records; guardrail update history.
Mappings. NIST AI RMF MEASURE/MANAGE; ISO/IEC 42001 AIMS; EU AI Act: Part V; SR 11-7 ongoing monitoring; DORA ICT third-party/monitoring aspect (tool supply chain).
Sources. aclanthology.org/2025.acl-long.399 (T2), https://aclanthology.org/2025.acl-long.399/; arxiv.org/abs/2606.01581 (T2), https://arxiv.org/abs/2606.01581; arxiv.org/abs/2607.06807 (T1), https://arxiv.org/abs/2607.06807; arxiv.org/abs/2607.10534 (T1), https://arxiv.org/abs/2607.10534; blog.trailofbits.com/2025/04/21/jumping-the-line-how-mcp-servers-can-attack-you-before-you-ever-use-them (T3), https://blog.trailofbits.com/2025/04/21/jumping-the-line-how-mcp-servers-can-attack-you-before-you-ever-use-them/; github.com/trailofbits/mcp-context-protector (T3), https://github.com/trailofbits/mcp-context-protector; github.com/eqtylab/mcp-guardian (T3): https://github.com/eqtylab/mcp-guardian
MON-07: AI-Supervised Monitoring of Agents (Hierarchical Oversight)
Objective. Scale oversight beyond human review capacity by deploying AI monitors over production agents, while controlling for monitor collusion and monitor obsolescence.
Control. Agents operating at autonomy levels where human review of every action is infeasible MUST be overseen by AI monitors whose coverage, recall, and response time are themselves measured; monitor architectures MUST anticipate the case where the monitored agent is more capable than the trusted monitor, using transparency-based designs rather than assuming a permanently smarter supervisor.
Implementation (financial enterprise). DeepMind's AI Control roadmap supplies the architecture: trusted AI supervisors continuously monitor agent reasoning, actions, and plans (detection); block harmful actions before execution (prevention/response); and are scored on coverage, recall, and response-time (performance measurement), with control intensity escalating along capability milestones for detection-evasion and harm-execution (deepmind.google/blog/securing-the-future-of-ai-agents). When agents outgrow trusted monitors, use the bootstrapped pattern (untrusted-but-transparent monitor, weaker trusted model reading its raw chain-of-thought for collusion) whose goal is to "extend the useful lifetime of trusted models in control as AI capabilities advance." (arxiv.org/abs/2606.11998). For multi-agent workflows, a dedicated conversation monitor is a published reference design: "The Arbiter reliably detects misaligned agents well before the end of the conversation, with active inspection tools improving both detection accuracy and speed." (arxiv.org/abs/2606.10747). Two Arbiter caveats matter operationally: weight-induced misalignment is the hardest case to detect (pair with vendor diligence, Part III.F), and its logging tool improved recall at the cost of precision, calibrate alert thresholds to your false-positive budget.
Maturity. Baseline: asynchronous AI review of sampled trajectories with human escalation. Enhanced: real-time supervisor blocking on high-risk actions; monitor coverage/recall metrics reported to the model risk committee. Frontier: bootstrapped/transparency-based monitoring with collusion audits.
Ownership. 1st line: operates monitors. 2nd line: owns monitor performance standards and validates monitors as models in their own right (they are models, inventory them). 3rd line: periodically challenges the monitoring stack with seeded misbehavior.
Evidence. Monitor inventory entries and validation reports; coverage/recall/response-time metrics; seeded-test results; escalation records.
Mappings. NIST AI RMF MANAGE; ISO/IEC 42001 AIMS; EU AI Act (human oversight: Part V); SR 11-7 (monitors are models subject to validation); DORA, not directly relevant.
Sources. deepmind.google/blog/securing-the-future-of-ai-agents (T1), https://deepmind.google/blog/securing-the-future-of-ai-agents/; arxiv.org/abs/2606.11998 (T1), https://arxiv.org/abs/2606.11998; arxiv.org/abs/2606.10747 (T1): https://arxiv.org/abs/2606.10747
MON-08: Monitoring-Latency Budget (Detect-to-Respond SLO)
Objective. Ensure the monitoring system detects and responds faster than the agent can cause irreversible harm, because a correct control action that arrives late is a failed control.
Control. Every agent deployment MUST have a documented detect-to-respond latency budget derived from the speed and reversibility of the actions the agent can take; monitoring and response mechanisms MUST demonstrably operate within that budget, and actions whose harm horizon is shorter than achievable response latency MUST be gated pre-execution (Part III.C) rather than monitored post-hoc.
Implementation (financial enterprise). This operationalizes a core systems-thinking finding: monitoring delays defeat otherwise-correct controls, if detection-and-response lags the agent's actions, the control action arrives too late to be effective (arxiv.org/abs/2606.13474). Finance harm horizons are unusually short (payment release, order routing, data egress): classify each tool by harm horizon and reversibility; anything irreversible inside your measured alert-to-halt time gets a synchronous gate, not an asynchronous alert. Measure real end-to-end latency, telemetry lag + detection + routing + human acknowledgment + kill-switch execution, and report it as an SLO beside the MON-07 coverage metrics. DeepMind's roadmap makes the same escalation explicit: controls move from delayed asynchronous review toward real-time synchronous prevention as capability grows (deepmind.google/blog/securing-the-future-of-ai-agents).
Maturity. Baseline: harm-horizon classification of tools; documented latency budget. Enhanced: measured end-to-end detect-to-halt drills with SLO reporting. Frontier: automatic autonomy reduction when measured latency exceeds budget.
Ownership. 1st line: measures and meets the SLO. 2nd line: approves harm-horizon classifications and budget derivations. 3rd line: independently times detect-to-halt drills.
Evidence. Harm-horizon/tool classification matrix; latency SLO reports; drill records with timestamps.
Mappings. NIST AI RMF MANAGE; ISO/IEC 42001 AIMS; EU AI Act: Part V; SR 11-7 (limits/controls on model use); DORA ICT incident-response readiness aspect.
Sources. arxiv.org/abs/2606.13474 (T2), https://arxiv.org/abs/2606.13474; deepmind.google/blog/securing-the-future-of-ai-agents (T1), https://deepmind.google/blog/securing-the-future-of-ai-agents/
MON-09: Agentic Incident Classification & Severity Taxonomy
Objective. Classify agentic failures consistently (by mechanism, severity, and regulatory reportability) so response, disclosure, and learning are triggered deterministically rather than by ad-hoc judgment under pressure.
Control. The institution MUST maintain an AI-incident taxonomy that (a) covers agent-specific mechanisms (goal drift, tool misuse, prompt/skill injection, monitor evasion, delegation-chain failure, loss of control as defined in the intro), (b) assigns severity tiers with pre-mapped response and notification requirements, and (c) flags at intake which external reporting regimes (MON-11) each classification can trigger. Every production anomaly disposition (MON-04–07) MUST map to "incident / not incident" against this taxonomy.
Implementation (financial enterprise). Extend the incident-management scaffolding the institution already runs: NIST SP 800-61r3 frames incident response as a CSF 2.0-integrated risk-management activity, not a standalone playbook (nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf); ISO/IEC 27035-2/-3 supply plan-and-prepare and operations structure (iso.org/standard/78974.html; iso.org/standard/74033.html). For the AI layer, the OWASP GenAI Incident Response Guide provides genAI-native categories and playbooks (genai.owasp.org/resource/genai-incident-response-guide-1-0), and the AIES work adapts safety-science incident analysis to AI agents specifically (ojs.aaai.org/index.php/aies/article/view/36596). Align severity definitions with the OECD common AI-incident reporting framework so internal tiers translate to external regimes without re-derivation (oecd.org: Towards a common reporting framework for AI incidents). Crucially, encode statutory triggers as taxonomy flags: "a model using deceptive techniques to subvert developer controls" is not just a severity modifier, under Illinois SB 315 it is a named critical-safety-incident trigger (incident_loss_of_control_reporting crosswalk).
Maturity. Baseline: AI annex to the existing incident taxonomy with severity tiers. Enhanced: agent-mechanism categories with automated intake classification from monitoring alerts. Frontier: taxonomy harmonized to OECD framework fields, enabling one-classification, many-regimes reporting.
Ownership. 1st line: classifies at intake. 2nd line: owns the taxonomy, quality-assures classifications. 3rd line: audits classification consistency and missed-incident rates.
Evidence. Taxonomy document with regulatory-trigger flags; classification records; QA sampling results.
Mappings. NIST AI RMF MANAGE; ISO/IEC 42001 AIMS; EU AI Act Art. 55/73 trigger alignment (see MON-11); SR 11-7 (escalation frameworks); DORA ICT incident classification aspect.
Sources. nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf (T1), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf; iso.org/standard/78974.html (T1), https://www.iso.org/standard/78974.html; iso.org/standard/74033.html (T1), https://www.iso.org/standard/74033.html; genai.owasp.org/resource/genai-incident-response-guide-1-0 (T1), https://genai.owasp.org/resource/genai-incident-response-guide-1-0/; ojs.aaai.org/index.php/aies/article/view/36596 (T2): https://ojs.aaai.org/index.php/AIES/article/view/36596; oecd.org/content/dam/oecd/en/publications/reports/2025/02/towards-a-common-reporting-framework-for-ai-incidents_8c488fdb/f326d4ac-en.pdf (T1), https://www.oecd.org/content/dam/oecd/en/publications/reports/2025/02/towards-a-common-reporting-framework-for-ai-incidents_8c488fdb/f326d4ac-en.pdf
MON-10: Agentic Incident Response & Containment
Objective. Contain, investigate, and remediate agentic incidents with response actions matched to how agents fail: credential revocation, agent halt, delegation-chain freeze, and trajectory forensics.
Control. The institution MUST maintain and exercise AI-specific incident response playbooks that include, at minimum: immediate agent suspension/kill-switch execution (interfacing with Part III.C runtime controls), revocation of the agent's credentials and delegated authorities, freezing of downstream agents in the delegation chain, preservation of action logs and reasoning traces (MON-01/02) as forensic evidence, and a documented decision point for external reporting (MON-11). Playbooks MUST be tested on realistic agentic scenarios at a defined cadence.
Implementation (financial enterprise). Structure per ISO/IEC 27035-2 (plan/prepare) and 27035-3 (response operations) (iso.org/standard/78974.html; iso.org/standard/74033.html), with NIST SP 800-61r3's CSF-integrated posture ensuring response feeds risk management rather than ending at ticket closure (nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf); OWASP GenAI IR Guide for the genAI-specific run-books (genai.owasp.org/resource/genai-incident-response-guide-1-0). Containment leans on identity controls: with short-lived, dynamically issued agent credentials (helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents), revocation is fast and surgical. The AIES agent-incident-analysis framework supplies the investigation lens: analyze the trajectory and the surrounding socio-technical system, not just the model output (ojs.aaai.org/index.php/aies/article/view/36596). Run an annual joint "rogue agent" exercise with the cyber IR team: the DeepMind roadmap's MITRE ATT&CK framing of agent attacks makes the two teams' vocabularies compatible (deepmind.google/blog/securing-the-future-of-ai-agents).
Maturity. Baseline: AI annex to cyber IR plan; kill-switch documented. Enhanced: agent-specific playbooks exercised annually; forensic trace preservation automated. Frontier: automated containment (suspend + revoke + freeze chain) triggered by high-confidence monitor verdicts within the MON-08 latency budget.
Ownership. 1st line: executes response; SOC integration. 2nd line: owns playbooks, validates exercise results. 3rd line: observes exercises, audits evidence preservation.
Evidence. Playbooks; exercise reports with timings; post-incident reports; credential-revocation logs from real or drilled events.
Mappings. NIST AI RMF MANAGE; ISO/IEC 42001 AIMS; EU AI Act Art. 73 (deployer-side serious-incident reporting, via MON-11; Art. 55 remains in MON-11's vendor-diligence lane); SR 11-7 (contingency around model failure); DORA ICT incident-response and testing aspects.
Sources. iso.org/standard/78974.html (T1), https://www.iso.org/standard/78974.html; iso.org/standard/74033.html (T1), https://www.iso.org/standard/74033.html; nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf (T1), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf; genai.owasp.org/resource/genai-incident-response-guide-1-0 (T1), https://genai.owasp.org/resource/genai-incident-response-guide-1-0/; ojs.aaai.org/index.php/aies/article/view/36596 (T2), https://ojs.aaai.org/index.php/AIES/article/view/36596; helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents (T3), https://www.helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents/; deepmind.google/blog/securing-the-future-of-ai-agents (T1): https://deepmind.google/blog/securing-the-future-of-ai-agents/
MON-11: Regulatory Incident-Reporting Obligations Register
Objective. Meet every external AI incident-reporting duty the institution is subject to (with the correct trigger, recipient, and clock) and never discover a 72-hour deadline on day four.
Control. The institution MUST maintain a living register of AI incident-reporting obligations across all jurisdictions of operation, mapping each regime's trigger definition to the internal taxonomy (MON-09), naming the recipient authority, the deadline, the responsible officer, and the evidence package required; the register MUST be reviewed on a defined cadence and upon regulatory change, and reporting decisions (report / no-report, with rationale) MUST be documented for every qualifying incident.
Implementation (financial enterprise). The cited reporting obligations provide a starting point for the register:
- EU AI Act: Art. 73 serious-incident reporting for high-risk systems to national market-surveillance authorities, staged windows up to 15 days (shorter for death/widescale); Art. 55 makes serious-incident tracking and reporting to the AI Office one of the four systemic-risk duties for GPAI providers (ai-act-service-desk.ec.europa.eu/en/ai-act/article-55). Compliance timing follows the amended EU AI Act application timeline, including the 2026 Digital Omnibus postponements, per Part V's sourced treatment. A bank is typically the deployer: deployer-side duties and vendor contractual pass-throughs both land here.
- EU GPAI Code of Practice (Safety & Security chapter): the operational elaboration of Art. 55 for systemic-risk GPAI providers (>10^25 FLOP or designation); relevant chiefly as vendor diligence: confirm your model providers are signatories and understand their incident-disclosure posture (crosswalk
[EU-GPAI]). - Illinois SB 315 (AI Safety Measures Act): the only instrument in the cohort that explicitly names loss of model control and a model "using deceptive techniques to subvert developer controls" as report triggers, on a 72-hour clock for large frontier developers (>$500M revenue and >10^26 FLOP), AG-enforced, no private right of action. Pending signature as of the crosswalk refresh, effective 1 Jan 2027 if signed: track, cite as pending (crosswalk
[IL]). - Colorado SB 26-189 (ADMT Act), not a safety-incident pipeline: a post-adverse-decision notice to the consumer where ADMT materially influenced an unfavorable consequential decision; signed 14 May 2026, effective 1 Jan 2027, AG-exclusive enforcement (crosswalk
[CO]). Lives with adverse-action operations (Part VI), but the register must carry it so agentic credit workflows inherit the duty.
Add the voluntary lane: MITRE's AI Incident Sharing initiative for protected inter-organizational exchange (ai-incidents.mitre.org; mitre.org/news-insights/news-release/mitre-launches-ai-incident-sharing-initiative); the OECD common-reporting framework as the interoperability schema; the UK gap analysis for horizon-scanning, a national incident regime is argued for there (longtermresilience.org report, T2). Standardization proposals give the field-level template for evidence packages (arxiv.org/abs/2501.14778).
Maturity. Baseline: register exists, owned by Compliance, reviewed annually. Enhanced: taxonomy-linked triggers auto-flag qualifying incidents at classification time; deadlines tracked in the case-management system. Frontier: pre-drafted report templates per regime; participation in voluntary sharing with legal-reviewed disclosure tiers.
Ownership. 1st line: supplies incident facts on the register's clock. 2nd line (Compliance/Legal): owns the register, makes the reporting call, files. 3rd line: audits timeliness and completeness of past filings and no-report rationales.
Evidence. The register with review history; filed reports and acknowledgments; no-report decision memos; regulatory-change monitoring records.
Mappings. NIST AI RMF GOVERN/MANAGE; ISO/IEC 42001 AIMS; EU AI Act Arts. 73 & 55; SR 11-7 (escalation to management and board); DORA ICT-incident reporting aspect (parallel regime for ICT incidents: coordinate, do not duplicate).
Sources. Reporting sources: Illinois SB 315, EU GPAI Code of Practice Safety & Security chapter, Colorado SB 26-189, EU AI Act key articles; ai-act-service-desk.ec.europa.eu/en/ai-act/article-55 (T1), https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-55; ai-incidents.mitre.org (T1), https://ai-incidents.mitre.org/; mitre.org/news-insights/news-release/mitre-launches-ai-incident-sharing-initiative (T2), https://www.mitre.org/news-insights/news-release/mitre-launches-ai-incident-sharing-initiative; oecd.org/content/dam/oecd/en/publications/reports/2025/02/towards-a-common-reporting-framework-for-ai-incidents_8c488fdb/f326d4ac-en.pdf (T1), https://www.oecd.org/content/dam/oecd/en/publications/reports/2025/02/towards-a-common-reporting-framework-for-ai-incidents_8c488fdb/f326d4ac-en.pdf; arxiv.org/abs/2501.14778 (T2), https://arxiv.org/abs/2501.14778; longtermresilience.org/wp-content/uploads/2024/06/ai-incident-reporting_-addressing-a-gap-in-the-uks-regulation-of-ai-1.pdf (T2), https://www.longtermresilience.org/wp-content/uploads/2024/06/AI-incident-reporting_-Addressing-a-gap-in-the-UKs-regulation-of-AI-1.pdf
MON-12: Safeguard Re-Verification & Feedback into Re-Evaluation
Objective. Treat safeguards as decaying assets: continuously verify that monitoring controls still work, and route production findings back into the evaluation gate so the institution's picture of the agent stays current.
Control. All Part III controls applied to a deployment MUST be re-verified on a defined schedule (and after material change) to confirm they remain calibrated, independent, and operating; monitoring findings, drift breaches, incidents, and near-misses MUST feed a documented re-evaluation trigger framework that can force an agent back through pre-deployment gates (Part III.B), restrict its autonomy, or retire it. The loop closes only when the triggering finding is reflected in updated baselines, thresholds, or eval suites.
Implementation (financial enterprise). The systems-safety warrant is explicit: "safeguard drift": "routine operational variability can gradually erode the calibration and independence of safeguards.", and the remedy is to pair model-focused evaluations with systems-level hazard analysis and operational assurance that re-verifies controls remain effective over time (arxiv.org/abs/2606.13474). Schedule control-effectiveness checks the way ops teams schedule DR tests: seeded misbehavior through the monitors (MON-07), timed kill-switch drills (MON-08/10), canary goal-probes (MON-05), threshold recalibration against fresh reference data (MON-04). NIST SP 800-61r3 does the same for the incident lane: lessons-learned integrate into risk management rather than dying in the post-mortem folder (nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf). Recurring assessments for privilege creep and agent lifecycle expiry belong on the same calendar (helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents). In SR 11-7 vocabulary this is periodic review/revalidation, with an agentic twist: the monitoring stack itself is in scope, not just the model. Board reporting should carry a safeguard-assurance line, when did we last prove each critical control fires? [practice guidance: not directly source-backed]
Maturity. Baseline: annual control re-verification tied to model periodic review. Enhanced: continuous assurance calendar (seeded tests, drills, recalibration) with findings tracked to closure. Frontier: automated re-evaluation triggers, defined production findings programmatically open a re-validation and cap autonomy until cleared.
Ownership. 1st line: executes re-verification activities, remediates. 2nd line: owns the trigger framework and the assurance calendar; confirms loop closure. 3rd line: independently re-performs a sample of re-verifications; opines annually on safeguard assurance.
Evidence. Assurance calendar and completion records; seeded-test and drill results over time; re-evaluation trigger log with dispositions; updated eval suites/baselines traceable to production findings.
Mappings. NIST AI RMF MANAGE (+ GOVERN for the trigger framework); ISO/IEC 42001 AIMS; EU AI Act (post-market monitoring feeding corrective action: Part V); SR 11-7/OCC 2011-12 periodic review & revalidation; DORA resilience-testing aspect.
Sources. arxiv.org/abs/2606.13474 (T2), https://arxiv.org/abs/2606.13474; nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r3.pdf (T1), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf; helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents (T3): https://www.helpnetsecurity.com/2026/06/12/nist-iso-frameworks-govern-ai-agents/
Closing note for Part III.D. The through-line of these twelve controls is the four verbs from the loss-of-control definition: constrain (MON-06, MON-08), audit (MON-01–03), reverse and halt (MON-10), with detection (MON-04–07) deciding when to invoke them, external candor when they fail (MON-09, MON-11), and MON-12 making sure the whole apparatus still works next quarter. An examiner will ask two questions of this Part: "show me the trail" and "prove the alarm still rings." Build so that both answers are exports, not essays.