There is a reliable pattern in model risk management: the cheapest controls are the ones nobody funds, because at design time the system has not yet embarrassed anyone. Runtime guardrails (Part III.C) are what an institution buys after an agent has done something memorable. Design-time controls are what a mature institution buys so the memorable thing is structurally difficult: the agent that cannot reach the wire-transfer API does not need a heroic monitor to stop it using one.
This part covers five design surfaces for agentic systems: (1) governance and provenance of the data that trains, tunes, and contextually feeds agents; (2) AI system impact assessment as a mandatory design gate; (3) least-privilege design of tools, permissions, and credentials; (4) the secure supply chain behind models, frameworks, and tools; and (5) memory and context architecture treated as deliberate control surfaces. The recurring theme: design-time constraint is not hygiene but a measurable oversight multiplier, in a controlled backdoor-detection experiment on coding agents, a small reviewer model's recall against sabotage rose from 54.5% on unconstrained agents to 90.9% once substrate constraints were enforced (figures as reported in the abstract; arxiv.org/abs/2607.02389). Every dollar of design-time constraint makes every downstream control cheaper.
SR 11-7 readers should recognize the posture: this is the leg of the standard whose scope covers model development, implementation, and use, extended to systems that act.
DES-01: Agent Data Inventory and Governance Plan
Objective. Ensure every dataset that trains, fine-tunes, or is retrievable by an agent is inventoried, owned, and governed before the agent is built.
Control. No agentic system enters development without a documented data governance plan covering: enumeration of all training/fine-tuning corpora (including vendor base-model disclosures where available), all retrieval/RAG corpora, and all runtime context feeds; a named data owner per source; documented licensing and consent basis; fitness-for-purpose criteria; and retention/deletion rules. The inventory is versioned and kept current.
Implementation (financial enterprise). Extend the SR 11-7 model inventory with a data-lineage annex per agent: corpus, owner, license/consent basis, sensitivity classification (MNPI, PII, customer confidential), permitted uses. Where a vendor foundation model's training data is undisclosed, record the gap explicitly as a residual risk accepted by the model owner and second line: never leave the cell blank. Community best practices for open training datasets (arxiv.org/abs/2501.08365) provide a sourcing and documentation checklist for internally assembled corpora. [practice guidance: not directly source-backed]: gate dataset onboarding through the same change control used for model changes.
Maturity. Baseline: static inventory with named owners. Enhanced: automated lineage capture; quarterly owner attestation. Frontier: per-record provenance (DES-02) with automated policy checks at ingestion.
Ownership. 1st line: product owner and data engineering maintain the inventory. 2nd line: model risk/data governance challenges completeness and fitness. 3rd line: audit tests inventory accuracy against deployed systems.
Evidence. Data-lineage annex; owner attestations; licensing documentation; onboarding change tickets.
Mappings. NIST AI RMF MAP/GOVERN; ISO/IEC 42001 AIMS; EU AI Act data-governance obligations (article not sourced in the sources cited here); SR 11-7/OCC 2011-12 model development & data quality; DORA n/a.
Sources. arxiv.org/abs/2501.08365 (T2), https://arxiv.org/abs/2501.08365; 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/
DES-02: Training-Data Provenance Instrumentation and Post-Hoc Auditability
Objective. Make it technically possible to answer, after the fact, "was this record (or this copyrighted/confidential source) in the training data?"
Control. For internally trained or tuned models, provenance is instrumented at build time, record-level where feasible, and the institution maintains at least one validated post-hoc audit capability (membership/provenance testing) for models whose training data it does not fully control.
Implementation (financial enterprise). A real toolchain now exists: record- and token-level provenance frameworks (arxiv.org/abs/2607.13037, flagged provisional claim in the cited research; a design pattern, not a validated product), data isotopes letting an owner detect use of their records in a trained network (arxiv.org/abs/2208.13893), copyright-content detection in VLM training data (proceedings.mlr.press/v267/duarte25a.html), post-hoc diagnosis of a model's data mixture (arxiv.org/abs/2605.30348), and watermark radioactivity, which makes training on watermarked LLM outputs detectable (arxiv.org/abs/2402.14904), directly relevant when policy forbids distilling from third-party model outputs. Model validation should adopt at least one such technique per model class, treated like any other validation tool. For vendor models, require training-data attestations and reserve audit rights.
Maturity. Baseline: dataset-level lineage; vendor attestations. Enhanced: a validated membership/provenance test at validation time. Frontier: record-level provenance in the training pipeline; radioactivity/isotope checks in the release gate.
Ownership. 1st line: ML platform instruments pipelines. 2nd line: model validation runs and challenges provenance tests. 3rd line: audit samples provenance claims end-to-end.
Evidence. Provenance test reports in the validation package; pipeline lineage logs; vendor attestation letters.
Mappings. NIST AI RMF MAP/MEASURE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 data quality & developmental evidence; DORA n/a.
Sources. arxiv.org/abs/2607.13037 (T1, provisional claim), https://arxiv.org/abs/2607.13037; arxiv.org/abs/2208.13893 (T2), https://arxiv.org/abs/2208.13893; proceedings.mlr.press/v267/duarte25a.html (T2), https://proceedings.mlr.press/v267/duarte25a.html; arxiv.org/abs/2605.30348 (T2), https://arxiv.org/abs/2605.30348; arxiv.org/abs/2402.14904 (T2): https://arxiv.org/abs/2402.14904
DES-03: Poisoning-Resistant Data Acquisition
Objective. Prevent adversarial contamination of the data that shapes agent behavior, at both training and retrieval time.
Control. All web-scale or third-party data acquisition for training, tuning, or retrieval corpora passes through documented integrity controls: source allowlisting or trust-tiering, snapshot pinning with content hashes, anomaly screening at ingestion, and quarantine of unverified additions. The threat model explicitly includes implanted behaviors that survive downstream safety training.
Implementation (financial enterprise). the cited research canon establishes that poisoning web-scale training datasets is a practical, low-cost attack (Poisoning Web-Scale Training Datasets is Practical) and that deliberately trained deceptive behaviors can persist through subsequent safety training (Sleeper Agents, "Sleeper Agents"). Consequence: post-training alignment cannot launder a poisoned corpus, so integrity must be enforced at acquisition. Pin and hash crawled snapshots; diff retrieval corpora between versions; require human review of anomalous additions to any corpus an agent treats as authoritative (policy manuals, rate sheets). Screen production-derived fine-tuning data for injection artifacts. [practice guidance: not directly source-backed]: assign retrieval corpora the integrity tier of the decisions they feed.
Maturity. Baseline: hash-pinned snapshots, source allowlists. Enhanced: ingestion anomaly screening; corpus diffs each refresh. Frontier: scheduled red-team poisoning exercises against your own pipeline.
Ownership. 1st line: data engineering operates ingestion controls. 2nd line: information security and model risk set trust-tier policy. 3rd line: audit tests the pipeline against the threat model.
Evidence. Ingestion control specs; snapshot hashes; corpus diff logs; poisoning red-team reports.
Mappings. NIST AI RMF MAP/MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 data quality/conceptual soundness; DORA ICT risk management (data integrity).
Sources. Poisoning Web-Scale Training Datasets is Practical (T2); Sleeper Agents (T2)
DES-04: Memorization and Training-Data Extraction Risk Controls
Objective. Prevent agents from leaking memorized training data (customer PII, MNPI, proprietary text) through outputs or tool calls.
Control. Any corpus containing confidential or personal data used in training or tuning receives a documented memorization risk assessment before use, and resulting models are tested for extractability before deployment. Where risk cannot be bounded, confidential data stays out of weights and is served through governed retrieval.
Implementation (financial enterprise). The cited studies document that training data can be extracted from LLMs (Extracting Training Data from Large Language Models) and that extraction scales to production models (Scalable Extraction of Training Data from (Production) Language Models): converting memorization into a live confidentiality exposure: a fine-tune on raw complaint narratives is a potential disclosure channel. Defaults: de-identify before tuning; prefer retrieval with query-time access control over baking confidential text into weights; include extraction probes in pre-deployment testing for sensitive-tuned models. Note the agentic amplifier: an agent with tool access can exfiltrate what a chat model could only recite, pair with DES-08 egress limits.
Maturity. Baseline: sensitive data excluded or de-identified. Enhanced: extraction probes in the validation suite. Frontier: quantitative memorization budgets with sign-off thresholds, re-tested at each refresh.
Ownership. 1st line: ML engineering de-identifies and probes. 2nd line: privacy office and validation set thresholds. 3rd line: audit verifies sensitive-corpus handling end-to-end.
Evidence. Memorization risk assessments; extraction-probe results; data-minimization design records.
Mappings. NIST AI RMF MEASURE/MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 developmental evidence; GDPR/privacy aspect [practice guidance mapping — GDPR text not in the sources cited here].
Sources. Extracting Training Data from Large Language Models (T2); Scalable Extraction of Training Data from (Production) Language Models (T2)
DES-05: AI System Impact Assessment as a Design Gate
Objective. Require a structured, documented impact assessment before any agentic system is approved for build or material change.
Control. Every proposed agentic system, and every material expansion (new tools, higher autonomy, new customer population), triggers an AI system impact assessment aligned to ISO/IEC 42005:2025, dispositioned before development funding or deployment approval. The assessment covers intended purpose, affected parties, foreseeable misuse, and the consequences of the agent's actions, not just its outputs. Cross-reference: GOV-10 is the control of record for the AI impact assessment; DES-05 is its design-time execution, extended with agent-specific content (action space, blast radius, reversibility), and instrument ownership follows GOV-10.
Implementation (financial enterprise). ISO/IEC 42005:2025 is the international standard for AI system impact assessment (iso.org/standard/42005; webstore.iec.ch/en/publication/107659) and slots into an ISO/IEC 42001 AIMS as the design-stage assessment discipline. Public templates accelerate adoption: Canada's Algorithmic Impact Assessment is a published questionnaire-based scoring instrument (open.canada.ca), and UNESCO's Ethical Impact Assessment offers a structured tool tied to the Recommendation on the Ethics of AI (unesco.org/ethics-ai/en/eia; unesdoc.unesco.org). For agents, extend the template with: enumerated action space and blast radius per tool; autonomy requested vs. justified; reversibility of the worst permitted action. Route through the committee that owns model approval, with second-line challenge recorded.
Maturity. Baseline: 42005-aligned assessment at approval. Enhanced: re-assessment triggers wired to change management (new tool = new assessment). Frontier: quantified impact scoring integrated with risk appetite and the autonomy ladder (Part II).
Ownership. 1st line: product owner completes it. 2nd line: model risk/compliance challenges and dispositions. 3rd line: audit tests trigger discipline, did every material change re-open the assessment?
Evidence. Completed assessment with disposition; change-triggered re-assessments; challenge records.
Mappings. NIST AI RMF MAP; ISO/IEC 42001 AIMS (42005 as companion standard); EU AI Act (article not sourced in the sources cited here); SR 11-7 model development & use approval; DORA n/a.
Sources. iso.org/standard/42005 (T1), https://www.iso.org/standard/42005; webstore.iec.ch/en/publication/107659 (T1), https://webstore.iec.ch/en/publication/107659; open.canada.ca/data/en/dataset/5423054a-093c-4239-85be-fa0b36ae0b2e (T1), https://open.canada.ca/data/en/dataset/5423054a-093c-4239-85be-fa0b36ae0b2e; unesco.org/ethics-ai/en/eia (T1), https://www.unesco.org/ethics-ai/en/eia; unesdoc.unesco.org/ark:/48223/pf0000386276 (T2), https://unesdoc.unesco.org/ark:/48223/pf0000386276
DES-06: Human-Rights and Customer-Impact Assessment for High-Stakes Agentic Scope
Objective. Apply a deeper, rights-focused assessment when an agent's action space touches customers' access to credit, insurance, funds, or redress.
Control. Agentic systems whose permitted actions can materially affect individual customers (declining, pricing, freezing, escalating, reporting) undergo a fundamental-rights/human-impact assessment in addition to DES-05, using a recognized methodology, with affected-stakeholder perspectives documented.
Implementation (financial enterprise). The Council of Europe's HUDERIA provides a published methodology for risk and impact assessment of AI systems from the standpoint of human rights, democracy and the rule of law (rm.coe.int CAI(2024)16rev2; coe.int programme page), piloted with businesses (coe.int "HUDERIA in Action" Ukraine pilot). Participatory approaches aligned with EU AI Act fundamental-rights impact assessment are emerging in the literature (PaFRIA, doi.org/10.1145/3805689.3806497). Practically, fuse this with existing fair-lending/UDAAP review: the rights assessment identifies who can be harmed by which permitted action, feeding Part VI (FCO) testing scope. [practice guidance: not directly source-backed]: assess sequence risk, individually benign actions (flag account → hold disbursement → adverse letter) composing into an unreviewed adverse decision.
Maturity. Baseline: rights assessment for customer-decisioning agents. Enhanced: stakeholder input documented; findings tracked to closure. Frontier: refreshed on autonomy changes and linked to outcome monitoring (Part III.D).
Ownership. 1st line: product/design teams run it. 2nd line: compliance/fair-lending owns methodology and challenge. 3rd line: audit reviews coverage of high-stakes agents.
Evidence. Assessment reports; stakeholder-input records; remediation tracking.
Mappings. NIST AI RMF MAP/GOVERN; ISO/IEC 42001 AIMS; EU AI Act fundamental-rights impact aspect (article not sourced in the sources cited here); SR 11-7 use approval; ECOA/UDAAP aspect [practice guidance mapping].
Sources. rm.coe.int/cai-2024-16rev2-methodology-for-the-risk-and-impact-assessment-of-arti/1680b2a09f (T1), https://rm.coe.int/cai-2024-16rev2-methodology-for-the-risk-and-impact-assessment-of-arti/1680b2a09f; coe.int/en/web/artificial-intelligence/huderia-risk-and-impact-assessment-of-ai-systems (T1), https://www.coe.int/en/web/artificial-intelligence/huderia-risk-and-impact-assessment-of-ai-systems; doi.org/10.1145/3805689.3806497 (T2): https://doi.org/10.1145/3805689.3806497; coe.int/en/web/digital-governance/news/-/asset_publisher/xvn9udjv9qug/content/huderia-in-action-council-of-europe-s-ai-risk-and-impact-assessment-methodology-piloted-with-businesses-in-ukraine (T2), https://www.coe.int/en/web/digital-governance/news/-/asset_publisher/xvn9udjV9qug/content/huderia-in-action-council-of-europe-s-ai-risk-and-impact-assessment-methodology-piloted-with-businesses-in-ukraine
DES-07: Agent Identity, Ownership, and Lifecycle by Design
Objective. Ensure every agent is a first-class, individually identifiable principal with a named owner and a bounded lifecycle from the day it is designed.
Control. No agent is built without: a unique machine identity distinct from any human account and from other agents; a named accountable human owner; a written statement of intent and scope; registration in the agent inventory; and a defined lifecycle including automatic expiration or recertification. Shared or ambient credentials are prohibited by design. Cross-reference: GOV-03/GOV-04 are the controls of record for agent inventory registration and named ownership; DES-07 is their design-time enforcement, identity created before build, implemented on the IAM stack.
Implementation (financial enterprise). Practitioner guidance on governing agents under NIST AI RMF and ISO/IEC 42001 converges on exactly this spine: each agent needs "a defined owner, a clear intent, a bounded scope of access, and an explicit lifecycle," with formal onboarding/registration, automatic expiration for temporary agents, and audit trails attributing every meaningful action to a specific identity (helpnetsecurity.com 2026, T3, vendor-authored; use as checklist, not authority). The same source flags that 42001 was not written for autonomous agents: an existing certificate does not automatically cover an agent fleet. These controls are the delta. Regulation is heading the same way: the Warner AI AGENT Act discussion draft (June 2026, not yet introduced; provisions paraphrased from the Senate release) is built around registered, revocable, scope-limited "custodial user agents" with traceable delegated action, identity and accountability as the regulatory unit. Implement on the existing IAM stack: agents enter the directory as non-human principals; recertification rides the standing access-review cycle. The CSA Agentic NIST AI RMF Profile (labs.cloudsecurityalliance.org) is the cited research's highest-tier enterprise-agent-controls mapping, cited here as a resource pointer only, its internal structure is not yet corpus-verified.
Maturity. Baseline: inventory + owner + unique identity per agent. Enhanced: automatic expiry, recertification, per-action identity attribution in logs. Frontier: fleet-wide identity graph including sub-agent delegation (Part III.E).
Ownership. 1st line: engineering registers agents; owners attest. 2nd line: IAM/security governance sets identity policy; model risk ties the register to the model inventory. 3rd line: audit reconciles running agents against the register.
Evidence. Agent register extract; IAM records with owners and expiry; recertification records; orphan-agent findings (ideally none).
Mappings. NIST AI RMF GOVERN/MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 model inventory aspect; DORA ICT risk management (identity/access).
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/; warner.senate.gov/newsroom/press-releases/warner-unveils-discussion-draft-of-legislation-to-create-innovative-market-for-secure-artificial-intelligence-agents (T1, provisional claim), https://www.warner.senate.gov/newsroom/press-releases/warner-unveils-discussion-draft-of-legislation-to-create-innovative-market-for-secure-artificial-intelligence-agents/; labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1 (T2), https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/
DES-08: Least-Privilege Tool and Permission Scoping
Objective. Grant each agent the minimum tool set, per-tool permissions, and data egress needed for its stated intent, and make the grant enforceable outside the model.
Control. Tool access is deny-by-default. Each granted tool is scoped (allowed operations, parameter constraints, rate/value limits, permitted data domains) in a machine-enforceable policy that lives outside the agent's prompt and cannot be modified by model output. High-consequence tools (payments, trading, account maintenance, mass communication) additionally require the runtime gates of Part III.C.
Implementation (financial enterprise). The research base treats privilege control as an enforceable layer, not prompt etiquette: Progent demonstrates securing agents through a dedicated privilege-control mechanism (arxiv.org/abs/2504.11703), and ToolSafety targets safety of LLM agent tool invocations (aclanthology.org/2025.emnlp-main.714). Benchmarks for tool-agent-user interaction in realistic domains (τ-bench, arxiv.org/abs/2406.12045) let scoping decisions be exercised before deployment: hand the scoped policy to the eval team (Part III.B) as a testable artifact. Derive each scope from the DES-07 statement of intent: a collections-outreach agent gets read access to its assigned queue, templated-send on one channel with volume caps, nothing else. Deviations are logged at the enforcement point, not in the model's self-report. Recall the DES-04 amplifier: scoping is also your exfiltration control.
Maturity. Baseline: deny-by-default allowlists enforced in the tool gateway. Enhanced: parameter-level constraints and value/rate caps; scope diffs at change control. Frontier: automated scope-minimization proposals from observed usage, human-approved tightening (never automatic loosening).
Ownership. 1st line: platform engineering operates enforcement; product owners request scopes. 2nd line: security architecture and model risk approve scopes and challenge breadth. 3rd line: audit tests enforcement against the approved policy.
Evidence. Signed scope policies; tool-gateway configuration exports; denied-call logs; scope change tickets.
Mappings. NIST AI RMF MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 model use & limitations; DORA ICT risk management (access control).
Sources. arxiv.org/abs/2504.11703 (T2), https://arxiv.org/abs/2504.11703; aclanthology.org/2025.emnlp-main.714 (T2), https://aclanthology.org/2025.emnlp-main.714/; arxiv.org/abs/2406.12045 (T2): https://arxiv.org/abs/2406.12045
DES-09: Short-Lived, Delegation-Bounded Credential Architecture
Objective. Ensure the credentials an agent wields cannot outlive their purpose or exceed the authority of the human they serve.
Control. Agents authenticate with short-lived, dynamically issued credentials: never static secrets in configuration or prompts. Delegated authority is always strictly narrower than that of the delegating human or service. Issuance, use, and revocation are logged per agent identity; revocation is executable in real time. Control of record: DES-09 is the control of record for short-lived agent credentials; MAS-04 implements it for multi-agent estates.
Implementation (financial enterprise). Practitioner guidance for governing agents under NIST/ISO frameworks specifies this posture: short-lived, dynamically issued credentials rather than static secrets; delegated authority narrower than the human it supports; real-time permission revocation; behavioral baselining; recurring privilege-creep assessments (helpnetsecurity.com 2026, T3, vendor-shaped but the correct default). Implement on existing secrets-management and workload-identity infrastructure: tokens scoped to the DES-08 policy; TTLs in minutes for high-consequence scopes; refresh contingent on the agent remaining registered and unexpired (DES-07). Prohibit credential pass-through of a human's full session; issue a derived, down-scoped token instead. [practice guidance: not directly source-backed]: drill the revocation path quarterly; an unexercised revocation path may not be credited as an operating control.
Maturity. Baseline: no static secrets; per-agent credentials with TTLs. Enhanced: down-scoped delegation tokens; automated privilege-creep review. Frontier: continuous credential risk scoring keyed to autonomy and data sensitivity, with automatic step-down on anomaly.
Ownership. 1st line: platform/IAM engineering operates issuance. 2nd line: security governance sets TTL and delegation policy. 3rd line: audit tests for static secrets and over-broad delegation.
Evidence. Secrets-scanner results; issuance/revocation logs; delegation-scope comparisons; revocation drill records.
Mappings. NIST AI RMF MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 internal controls aspect; DORA ICT risk management (authentication).
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/
DES-10: User-Level Permission Model: Specify, Derive, Enforce
Objective. Design agent permission systems so that what a user authorizes is faithfully translated into policy and actually enforced at run time: three distinct problems that must each be solved.
Control. For any agent acting on behalf of a person (customer or employee), the design documents three separately testable layers: how permissions are specified (interface and internal representation), how internal policies are derived from user input, and how they are enforced at run time. Product sign-off requires evidence at the enforcement layer, not the interface layer. Permissions are scope-limited and revocable by the authorizing person.
Implementation (financial enterprise). A 2026 University of Washington survey, 21 permission-system proposals compared against five commercial agents, supplies both the risk framing and the decomposition. On risk: prompt injection and hallucination "can cause agents to leak private information to third parties," and agents "also present the more active danger of performing sensitive tasks, such as bank transactions, without the user's intent or authorization" (arxiv.org/abs/2607.13718; abstract-verified quotations). On the gap: "Much of this work has focused on product-level approaches, where agentic system developers determine and apply the same security policies and permissions to all users. Yet different users have different needs and preferences, necessitating support for user-level permissions policies in agentic AI systems." The survey's taxonomy separates how systems "specify user-level permissions policies… derive internal policies from user input; and enforce those policies at run-time," and reports gaps between commercial agents and the literature. The design and procurement question this yields: show me where the policy is enforced, not where it is displayed. The Warner discussion draft (paraphrased; see DES-07) frames the same requirement statutorily, authorization that is transparent, documented, limited in scope, and revocable.
Maturity. Baseline: documented specify/derive/enforce design with revocation. Enhanced: derivation fidelity tested against stated intent; enforcement tested adversarially. Frontier: per-user policy customization with formal verification of enforcement for high-consequence actions.
Ownership. 1st line: product and platform engineering design and test all three layers. 2nd line: compliance validates the customer-authorization flow; model risk challenges derivation fidelity. 3rd line: audit traces sampled authorizations through to enforcement events.
Evidence. Permission-model design document; derivation-fidelity and enforcement test reports; revocation logs; customer disclosures.
Mappings. NIST AI RMF GOVERN/MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 model use aspect; UDAAP/consumer-authorization aspect [practice guidance mapping].
Sources. arxiv.org/abs/2607.13718 (T1): https://arxiv.org/abs/2607.13718; warner.senate.gov/newsroom/press-releases/warner-unveils-discussion-draft-of-legislation-to-create-innovative-market-for-secure-artificial-intelligence-agents (T1, provisional claim), https://www.warner.senate.gov/newsroom/press-releases/warner-unveils-discussion-draft-of-legislation-to-create-innovative-market-for-secure-artificial-intelligence-agents/
DES-11: Environmental Constraints as an Oversight Substrate
Objective. Engineer the agent's environment (access control, network policy, enforced conventions) so oversight and monitoring become materially more effective, not merely so bad actions are blocked.
Control. Every agent runs inside an engineered constraint envelope defined at design time: filesystem/repository access limits, network egress policy, enforced conventions where applicable, and environment-level guardrails that hold regardless of model behavior. The envelope is documented as an input to monitoring design (Part III.D), because it changes what monitors can catch.
Implementation (financial enterprise). Winninger (ICML 2026 workshop) applies human-engineering-team management controls (access control, network policies, enforced coding conventions) as an "oversight substrate" for coding agents, independent of any monitor: in a controlled backdoor-detection experiment, a small reviewer model's recall rose from 54.5% against unconstrained agents to 90.9% with substrate constraints enforced (arxiv.org/abs/2607.02389; figures from the abstract, abstract-only evidence). The lesson generalizes: constraints shrink the space of plausible behavior, making cheap monitors effective, bankable for institutions that cannot afford frontier-scale monitoring. For developer-facing agents: branch protections, dependency allowlists, CI conventions at the platform level. For operational agents: network segmentation and API-gateway policy. Record the envelope in the validation package so the eval team (Part III.B) tests the agent as constrained.
Maturity. Baseline: documented envelope per agent class. Enhanced: envelope co-designed with monitoring; monitor effectiveness measured with and without constraints. Frontier: standardized reusable platform profiles with measured oversight-multiplier effects.
Ownership. 1st line: platform engineering implements envelopes. 2nd line: security architecture approves; model risk includes them in validation scope. 3rd line: audit verifies envelopes match documentation in production.
Evidence. Envelope specifications; infrastructure-as-code exports; monitor-effectiveness comparisons; validation package references.
Mappings. NIST AI RMF MANAGE/MEASURE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 internal controls & monitoring linkage; DORA ICT risk management.
Sources. arxiv.org/abs/2607.02389 (T2): https://arxiv.org/abs/2607.02389
DES-12: Secure Development and Attestation for the Agent Stack
Objective. Hold the software stack that builds and runs agents (pipelines, frameworks, orchestration, serving) to secure software development practice, with attestation from suppliers.
Control. All components of the agent stack, internal and procured, are developed under a secure software development framework; suppliers of critical components provide secure-development attestations; acquisition follows a documented cyber-supply-chain risk management (C-SCRM) process before onboarding.
Implementation (financial enterprise). The US federal supply-chain regime is ready-made scaffolding: OMB M-22-18 establishes the binding policy of requiring secure software development practices of suppliers, operationalized through CISA's Secure Software Development Attestation Form, a template for what to demand from agent-framework and orchestration vendors. The ESF recommended-practices guides give role-specific checklists for developers and suppliers, and CISA's Software Acquisition Guide structures the C-SCRM questionnaire for enterprise buyers. Apply these to the pieces AI programs habitually exempt: the agent framework pulled from a public registry, the orchestration layer, tool-adapter libraries. Vendor governance beyond the software artifact is Part III.F (TPR); this control owns the engineering diligence.
Maturity. Baseline: attestations on file for critical components; internal pipelines under the enterprise SSDF program. Enhanced: acquisition questionnaires and dispositions for all agent-stack components. Frontier: continuous supplier posture monitoring with re-attestation on major releases.
Ownership. 1st line: engineering and procurement collect attestations. 2nd line: third-party risk and security governance set requirements. 3rd line: audit samples components for attestation coverage.
Evidence. Supplier attestation forms; C-SCRM questionnaires and dispositions; SSDF conformance records.
Mappings. NIST AI RMF GOVERN/MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 vendor model aspect; DORA ICT third-party risk.
Sources. bidenwhitehouse.archives.gov/wp-content/uploads/2022/09/m-22-18.pdf (T1), https://bidenwhitehouse.archives.gov/wp-content/uploads/2022/09/M-22-18.pdf; cisa.gov/resources-tools/resources/secure-software-development-attestation-form (T1), https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form; media.defense.gov/2022/sep/01/2003068942/-1/-1/0/esf_securing_the_software_supply_chain_developers.pdf (T1), https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF; cisa.gov/sites/default/files/2024-08/securing_the_software_supply_chain_suppliers_508.pdf (T1), https://www.cisa.gov/sites/default/files/2024-08/SECURING_THE_SOFTWARE_SUPPLY_CHAIN_SUPPLIERS_508.pdf; cisa.gov/resources-tools/resources/software-acquisition-guide-government-enterprise-consumers-software-assurance-cyber-supply-chain (T1): https://www.cisa.gov/resources-tools/resources/software-acquisition-guide-government-enterprise-consumers-software-assurance-cyber-supply-chain
DES-13: Model, Artifact, and Tool Provenance: Signing and Integrity Verification
Objective. Guarantee that the model weights, adapters, prompts, tool definitions, and datasets an agent loads in production are exactly the artifacts that were approved.
Control. Every deployable AI artifact (weights, fine-tune adapters, system prompts, tool/MCP definitions, retrieval indexes) is cryptographically signed at build, verified at load, and traceable to its build via provenance metadata meeting a defined supply-chain integrity level. Unsigned or tampered artifacts fail closed. Tool definitions are additionally protected against post-approval mutation ("rug pulls") and namespace impersonation ("tool squatting").
Implementation (financial enterprise). The cited sources inform the pattern: SLSA supply-chain levels define graded provenance requirements (SLSA); model signing and provenance extends signing to ML artifacts (practice guidance; no specific source cited); MLOps supply-chain security references collect pipeline-hardening practice (practice guidance; no specific source cited). For the agent-specific surface, ETDI proposes mitigating tool squatting and rug-pull attacks in the Model Context Protocol via OAuth-enhanced tool definitions and policy-based access control (arxiv.org/abs/2506.01333). The insight to internalize even without adopting ETDI: a tool definition is a supply-chain artifact, version-pin it, hash it, re-approve on any change, because an agent that trusts a mutated tool description has been reprogrammed without anyone touching the model. Wire verification into the serving path: the model gateway refuses unsigned weights; the tool gateway refuses definitions whose hash is off the approved manifest.
Maturity. Baseline: signed weights and pinned tool definitions verified at load. Enhanced: SLSA-graded provenance for the full artifact set including prompts and indexes. Frontier: end-to-end verified lineage from training data (DES-02) through build to serving, examinable on demand.
Ownership. 1st line: ML platform implements signing/verification. 2nd line: security architecture sets integrity levels; model risk ties artifact manifests to inventory records. 3rd line: audit tests fail-closed behavior and manifest accuracy.
Evidence. Signing/verification configuration; approved-artifact manifests; load-time rejection logs; provenance metadata samples.
Mappings. NIST AI RMF MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 implementation & change control; DORA ICT risk management (integrity).
Sources. SLSA (T2); arxiv.org/abs/2506.01333 (T3): https://arxiv.org/abs/2506.01333
DES-14: Memory and Context Architecture as Designed Control Surfaces
Objective. Treat what an agent remembers, retrieves, and holds in context as deliberate architectural decisions with risk consequences: scoped, provenance-tagged, and inspectable.
Control. The design of every agentic system specifies: (a) memory tiers (per-task ephemeral, per-user, shared/long-term) with explicit write criteria, retention limits, and deletion paths; (b) provenance and trust tags on all material entering context (user input, retrieved documents, tool outputs, other agents' messages), with untrusted content never silently acquiring instruction-level authority; (c) isolation boundaries so one customer's or task's data cannot leak into another's context; (d) inspectability, an auditor can reconstruct what was in context and memory when a given action was taken.
Implementation (financial enterprise). The architectural specifics here are predominantly [practice guidance: not directly source-backed], but the risk premises are source-backed: injected context "can cause agents to leak private information to third parties" and drive "sensitive tasks, such as bank transactions, without the user's intent or authorization" (arxiv.org/abs/2607.13718); implanted behaviors can persist through safety training (Sleeper Agents), a warning that transfers to persistent memory, which is post-deployment learning by another name; and practical corpus poisoning (Poisoning Web-Scale Training Datasets is Practical) applies to memory stores and retrieval indexes as much as training sets. Concretely: default agents to ephemeral memory and require a documented case for persistence; route memory writes for high-autonomy agents through DES-03-style trust-tiering; tag retrieved passages with source and tier so runtime policy (Part III.C) treats low-trust content as data, never instructions; log memory writes and context assembly with the action trail (Part III.D). Retention and deletion must satisfy records-management and privacy obligations: a long-term memory store full of customer utterances is a records system and must be brought under records-management governance.
Maturity. Baseline: documented memory tiers, retention rules, per-customer isolation. Enhanced: provenance tags on all context entries; trust-gated memory writes; context reconstruction available for audit. Frontier: memory-integrity monitoring (poisoning detection on the store) and enforced instruction/data separation in context assembly.
Ownership. 1st line: platform and product engineering own the architecture. 2nd line: model risk, privacy, and records management challenge retention, isolation, and trust design. 3rd line: audit performs context-reconstruction tests on sampled actions.
Evidence. Memory/context architecture document; retention/deletion configuration; provenance-tag schema; context reconstruction demonstrations; records-management sign-off.
Mappings. NIST AI RMF MAP/MANAGE; ISO/IEC 42001 AIMS; EU AI Act (article not sourced in the sources cited here); SR 11-7 conceptual soundness & internal controls; GDPR/records aspect [practice guidance mapping]; DORA ICT risk management (data integrity).
Sources. arxiv.org/abs/2607.13718 (T1): https://arxiv.org/abs/2607.13718; Sleeper Agents (T2); Poisoning Web-Scale Training Datasets is Practical (T2)