Dependency ordering of foundational conditions for safe agentic Artificial…

Research Question

The foundational conditions for safe agentic AI deployment in a regulated financial institution are not independent, they form a dependency graph in which policy coherence is a prerequisite for information architecture, which is a prerequisite for access control, which is a prerequisite for safe agent credential scoping, which is a prerequisite for safe Retrieval-Augmented Generation (RAG) deployment over organisational knowledge, which is a prerequisite for safe deployment of the deployment pipeline gate itself. What is the correct characterisation of this dependency ordering? What is the consequence of deploying at any layer before the layer below it is satisfied, is the consequence merely increased risk, or does it constitute a control failure under any applicable regulatory framework? And does any existing framework, zero trust, operational resilience, or AI governance, explicitly encode this dependency ordering, or must it be constructed as a novel contribution?

Findings

(Populated from Section 6 Synthesis above.)

Executive Summary

• The best-supported dependency ordering for safe agentic deployment is coherent machine-checkable policy in the delegated domain, then representable information architecture and access boundaries, then scoped machine identity and delegation, then permission-safe Retrieval-Augmented Generation (RAG) or other knowledge access, and only then a deployment pipeline gate that can verify those artefacts.
• Violating the order at the first layer can begin as a governance defect, but once the institution deploys machine-speed automation that claims to enforce or rely on the incoherent lower layer, the consequence becomes a current or foreseeable control failure rather than a neutral risk increase.
• Violating the order at the access, credential, or RAG layers is more clearly a control failure because the relevant companion items and zero-trust sources already treat weak permission representation and over-broad machine action as technically or architecturally unsafe.
• No single reviewed framework explicitly encodes this full five-step ordering, so the contribution here is a novel synthesis built from zero-trust control objects, operational-resilience obligations, AI-governance functions, and staged-maturity analogy rather than a quotation from one governing text.

Key Findings

1. Safe agentic deployment is best modelled as a dependency chain in which coherent policy for the delegated domain must exist before access objects can be represented, access objects must be represented before least-privilege machine identity can be scoped, that identity model must exist before knowledge retrieval can be called permission-safe, and all four must exist before a deployment gate can validate anything meaningful.
2. The first layer is not whole-enterprise policy perfection but coherent policy at the delegated control domain, because bounded local typed controls can succeed before full policy-estate remediation, yet even those local controls fail if the governing rule set is contradictory or not synchronised across phases.
3. Information architecture and access representation are a hard technical prerequisite for agent credential scoping because a machine identity cannot be constrained to task-level least privilege unless the institution can state which resources exist, how they are classified, and which permissions belong to the job the agent is allowed to perform.
4. Agent credential scoping is logically necessary for autonomous or cached permission-safe RAG, while purely live user-delegated retrieval slightly qualifies the claim by reducing copied-state risk without eliminating the need for a coherent acting identity and access model.
5. The deployment pipeline is the strongest enforceable enterprise chokepoint after maker access already exists, but it becomes a real control gate only when lower-layer artefacts such as policy bundles, identity declarations, access classifications, and retrieval boundaries are available for deterministic checking.
6. Deploying an upper layer before the layer below it is satisfied is not merely an incremental risk increase once the missing lower layer is known, because machine-speed automation removes human pacing and turns missing prerequisites into active control failures or clear foreseeable-control-failure conditions.
7. No reviewed zero-trust, prudential, operational-resilience, or AI-governance framework states the full five-layer ordering explicitly, because the frameworks define control objects and lifecycle duties but leave the exact remediation sequence to institutional design.
8. The closest existing analogue is staged maturity thinking from the Capability Maturity Model, which supports the idea that higher-order capability depends on lower-order discipline, but the specific mapping from policy coherence to RAG and deployment gating remains a novel synthesis rather than a standard maturity model already accepted by regulators.

Assumptions

• None.

Analysis

• Dependency graph: coherent delegated-domain policy -> representable information architecture and access boundaries -> scoped machine identity and delegation -> permission-safe RAG and tool access -> deployment pipeline approval gate.
• Layer 1, policy coherence: the minimum bar is one authoritative, current, testable policy artefact for the delegated domain. Board test: can the institution point to one machine-checkable source of truth that the agent or gate actually evaluates?
• Layer 2, information architecture and access representation: the minimum bar is stable resource classification plus a permission model that can be rendered as metadata or live source authorization. Board test: can the institution compute a reliable allow-set for a given task without manual reconstruction?
• Layer 3, agent credential scoping: the minimum bar is a separate machine identity or explicit delegation chain whose effective permissions are narrower than the estate maximum and attributable end to end. Board test: can every automated action be traced to an actor identity and justified as least privilege for that task?
• Layer 4, permission-safe RAG: the minimum bar is retrieval behavior that stays inside the acting identity's boundary and updates correctly when permissions change. Board test: can the institution explain how retrieval, embeddings, and permission changes remain aligned for the chosen architecture?
• Layer 5, deployment pipeline gate: the minimum bar is a gate that blocks promotion unless the lower-layer artefacts are present, current, and policy-consistent. Board test: would the gate fail closed if policy, identity, or access evidence is missing or stale?
• Evidence was weighted toward sources that define control objects and obligations directly, then toward companion items that test the mechanism on the relevant control surface, and only then toward maturity-model analogy for the novelty assessment.

Risks, Gaps, and Uncertainties

• ISO/IEC 42001 evidence is limited to public summaries because the normative text is paywalled.
• DORA evidence is strongest on official control domains and weaker on article-level wording because the official reader path was unreliable in this runtime.
• The edge from credential scoping to RAG is strongest for autonomous or cached retrieval architectures and slightly weaker for narrowly interactive live source retrieval.
• The Capability Maturity Model (CMM) analogy supports staged dependence conceptually, but it does not by itself validate the domain-specific order of the five layers.

Open Questions

• What is the smallest practical delegated-policy domain for which machine-checkable coherence can be certified before broader estate remediation?
• Which live retrieval architectures can preserve user-bound permissions strongly enough to relax copied-index prerequisites without reintroducing hidden side channels?
• What proof artefact should a regulated institution require from a low-code platform before treating the native publish path as subordinate to the external deployment gate?

sources

• [x] Policy coherence as a machine-checkable prerequisite — - companion item on machine-checkable policy coherence
• [x] Permission-safe Retrieval-Augmented Generation (RAG) in enterprise information architectures — - companion item on information architecture and permission-safe retrieval
• [x] Access control amplification under agentic operations — - companion item on least privilege and agent credential scope
• [x] Implicit rate-limiting controls removed by agentic AI — - companion item on blast-radius amplification once automation removes human pacing
• [x] Deployment pipeline as the only enforceable control gate — - companion item on release-time enforcement
• [x] Systems capability debt and agentic AI operational risk synthesis — - foundational context for sequencing and novelty
• [x] Regulatory and standards preconditions for deployment of agentic AI systems — - regulatory consequence base
• [x] NIST SP 800-207: Zero Trust Architecture — - zero-trust control objects and least-privilege session model
• [x] NIST Artificial Intelligence Risk Management Framework (AI RMF) 1.0 publication page — - official framework publication page
• [x] NIST Artificial Intelligence Risk Management Framework (AI RMF) Core — - official statement on govern, map, measure, and manage sequencing
• [x] NIST Artificial Intelligence Risk Management Framework (AI RMF) Playbook — - official playbook and voluntary tailoring guidance
• [x] ISO/IEC 42001:2023 standard page — - official Artificial Intelligence Management System (AIMS) standard page
• [x] ISO 42001 explained — - official public explanation of governance, data, and lifecycle controls
• [x] APRA CPS 230: Operational Risk Management — - official operational-risk and resilience standard
• [x] Digital Operational Resilience Act (DORA) official text — - official Regulation (EU) 2022/2554 text
• [x] European Securities and Markets Authority (ESMA) DORA overview — - official summary of DORA control domains
• [x] Capability Maturity Model for Software (Version 1.1) — - official Software Engineering Institute (SEI) maturity-model source
• [x] Key Practices of the Capability Maturity Model Version 1.1 — - official Software Engineering Institute (SEI) elaboration of maturity levels