2026 04 26 access control amplification agentic operations

Access control amplification under agentic operations: whether existing frameworks address the worst-case permission inheritance problem

Research Question

Agents do not inherit a user's typical behaviour, they inherit the worst-case interpretation of that user's full permission set, because they operate without fatigue, attention limits, or working hours. An environment with incomplete least-privilege implementation therefore presents a materially different risk profile under agentic operation than under human operation. Do any existing frameworks, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207 Zero Trust Architecture (ZTA), NIST SP 800-53, Australian Prudential Regulation Authority (APRA) CPS 230, or the European Union (EU) Digital Operational Resilience Act (DORA), explicitly address this amplification mechanism, or must the argument be constructed from first principles?

Scope

In scope:

The specific mechanism by which agents operating continuously without fatigue, attention limits, or working hours inherit the worst-case interpretation of a user's full permission set rather than the user's typical-use subset
Whether NIST SP 800-207, NIST SP 800-53, APRA CPS 230, and DORA contain explicit provisions addressing this amplification mechanism, not merely general access control or least-privilege requirements, but language that specifically contemplates non-human automated principals operating at machine speed
Whether the argument can be made from first principles using operational risk or systems safety literature if no framework explicitly addresses it
The blast radius differential between human and agentic operation under identical permission sets
Whether any published technical guidance (e.g., NIST Artificial Intelligence Risk Management Framework (AI RMF), vendor security documentation) addresses the specific problem of agent credential scoping
Relationship to the least-privilege principle and the principle of minimal footprint in agentic systems

Out of scope:

General least-privilege architecture design (covered by NIST SP 800-207 and SP 800-53 directly)
The Retrieval-Augmented Generation (RAG)-specific access control problem (covered by the companion RAG item)
The policy coherence problem (covered by the companion policy coherence item)
The regulatory control-failure characterisation (covered by the completed regulatory preconditions item)

Constraints:

Distinguish between frameworks that explicitly name the amplification mechanism versus frameworks from which the argument must be inferred
Evidence claims about what frameworks say must reference the actual framework text or official summary, not secondary commentary
The New Zealand (NZ) Crown-owned bank context (Microsoft 365, Copilot Studio, Amazon Web Services (AWS) Bedrock) should inform the assessment of which frameworks are most applicable

Context

[fact; source: https://davidamitchell.github.io/Research/research/2026-04-26-agentic-ai-regulatory-preconditions-control-failure-assessment.html] The completed regulatory preconditions item, Regulatory and standards preconditions for deployment of agentic Artificial Intelligence (AI) systems, concluded that incomplete least-privilege access already constitutes a current or foreseeable control failure under APRA CPS 230, DORA, NIST SP 800-207, and International Organization for Standardization (ISO) 31000.
[inference; source: https://davidamitchell.github.io/Research/research/2026-04-26-agentic-ai-regulatory-preconditions-control-failure-assessment.html] That prior item inferred that agentic credential delegation across an estate that still lacks granular least privilege is already an architectural control failure under zero-trust principles, but it did not test whether any framework explicitly names the amplification mechanism itself.
This item tests that narrower question.

Approach

Framework text analysis for explicit amplification language: For each of NIST SP 800-207, NIST SP 800-53, APRA CPS 230, and DORA, search for provisions that explicitly address non-human automated principals, continuous operation without human-speed rate limiting, or the specific risk that automated systems operating on behalf of users present a different blast-radius profile than those same users operating manually.
NIST AI RMF and supplementary guidance: Check whether NIST AI RMF 1.0, NIST AI RMF Playbook, or NIST guidance on agentic AI addresses the amplification mechanism explicitly.
Operational risk and systems safety literature: If no framework explicitly addresses the amplification mechanism, construct the argument from the operational risk literature on automation, the speed-of-consequence literature, and systems safety literature on automation failure modes.
Vendor security guidance survey: Check whether Microsoft Copilot Studio, AWS Bedrock, and comparable vendor security documentation explicitly addresses the amplification problem and recommends specific mitigations (e.g., agent-specific service principals, reduced permission scopes, time-bounded credentials).
Synthesis: Produce a clear assessment of (a) whether the amplification argument is first-principles or framework-explicit for each named framework, (b) which evidence is strongest for a board risk committee versus a technical architecture audience, and (c) what the minimum control requirements are to address the amplification problem before agentic deployment.

Sources

Research Skill Output

(Full output from running the research skill, retained verbatim in the completed item. Sections 0-5 are the investigation, and section 6 seeds the Findings section below.)

§0 Initialise

[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554; https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10] Research question restated: do the named frameworks explicitly recognise that agentic systems amplify access risk because they can continuously exercise the full permission set available to a user or delegated identity, or does that mechanism have to be inferred from more general least-privilege, operational-risk, and resilience requirements?
[fact; source: https://davidamitchell.github.io/Research/research/2026-04-26-agentic-ai-regulatory-preconditions-control-failure-assessment.html; https://davidamitchell.github.io/Research/research/2026-04-26-systems-capability-debt-agentic-ai-risk-synthesis.html; https://davidamitchell.github.io/Research/research/2026-04-24-business-led-low-code-agent-governance.html] Prior work cross-reference: prior completed items in this repository already established that incomplete least privilege is a current or foreseeable control failure in regulated agent deployments, that systems capability debt amplifies downstream agent risk, and that durable low-code agent deployment depends on enforceable platform guardrails; this item narrows the question to whether the amplification mechanism itself is framework-explicit rather than merely inferable.
[fact; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] Constraint note: the raw EUR-Lex DORA text path was unreliable in this runtime, so official ESMA and EBA pages were used as the official-summary layer for DORA, while claims about the regulation's detailed chapter structure were limited to what those pages expose directly.
[fact; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] Output format confirmed: knowledge, written for both board-risk-committee and technical-architecture audiences.

§1 Question Decomposition

Root question: do existing frameworks explicitly describe access-control amplification under agentic operation, or must that risk narrative be assembled from adjacent control principles and newer agent-specific guidance?
A. Named-framework test
- A1. What does NIST Special Publication (SP) 800-207 explicitly say about subjects, sessions, and minimum privilege?
- A2. What does NIST SP 800-53 explicitly say about least privilege for users and processes acting on behalf of users?
- A3. What do Australian Prudential Regulation Authority (APRA) CPS 230 and the Digital Operational Resilience Act (DORA) explicitly require on operational controls, monitoring, and resilience?
- A4. Do any of those four frameworks explicitly name non-human principals operating continuously at machine speed as a distinct risk class?
B. Supplementary-guidance test
- B1. Does NIST Artificial Intelligence Risk Management Framework (AI RMF) 1.0 explicitly discuss autonomy, human oversight, and shut-down or monitoring mechanisms?
- B2. Do current NIST Center for AI Standards and Innovation (CAISI) publications explicitly discuss constraining and monitoring agent access?
- B3. Do current vendor documents explicitly warn that agent identities, triggers, or tool permissions can amplify blast radius?
C. First-principles test
- C1. Under identical permissions, why is agentic execution riskier than human execution?
- C2. What minimum controls follow if the amplification mechanism is explicit only in supplementary guidance and not in the four named frameworks?
D. Audience test
- D1. Which evidence is strongest for a board or regulator audience?
- D2. Which evidence is strongest for a technical-architecture audience?

§2 Investigation

Source access notes

Access note: raw EUR-Lex HTML and PDF fetch paths for Regulation (EU) 2022/2554 unreliable in this runtime; official ESMA and EBA pages used as the DORA summary layer
Access note: .github/skills/research/SKILL.md absent in this runtime; repository fallback process from research-prompt.md used

NIST SP 800-207, Zero Trust Architecture

[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 states that zero trust assumes no implicit trust for user accounts, that authentication and authorization are discrete functions before a session is established, and that zero trust focuses on protecting resources rather than network location.
[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 says enterprises should restrict resources to those with a need to access and grant only the minimum privileges needed to perform the mission.
[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 defines authorized subjects as the combination of user, application or service, and device, and says access to individual enterprise resources is granted on a per-session basis with the least privileges needed to complete the task.
[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 also says all resource authentication and authorization are dynamic and strictly enforced, and that enterprises should establish continuous diagnostics and mitigation to monitor device and application state.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final] These clauses explicitly support agent-specific scoping, because they treat service identities and per-session authorization as first-class control objects, but they do not explicitly say that an automated principal operating continuously at machine speed creates a different blast-radius profile than a human using the same permissions.

NIST SP 800-53 Rev. 5

[fact; source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] NIST SP 800-53 AC-2 requires organizations to define allowed and prohibited account types, create and remove accounts under policy, monitor account use, review accounts for compliance, and support account management with automated mechanisms.
[fact; source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] NIST SP 800-53 AC-5 requires separation of duties and says that system access authorizations should support that separation to reduce the potential abuse of authorized privileges.
[fact; source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] NIST SP 800-53 AC-6 says least privilege applies to users, or processes acting on behalf of users, and requires only the authorized accesses necessary to accomplish organizational tasks.
[fact; source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] NIST SP 800-53 further requires restrictions on privileged accounts, review of user privileges, and logging of privileged-function execution because misuse of privileged functions can have significant adverse impacts on organizations.
[inference; source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] SP 800-53 therefore explicitly covers the control objects needed for agent safety, including user-delegated processes, account lifecycle, privilege review, and privileged-action logging, but it still leaves the specific amplification narrative to inference rather than naming machine-speed inheritance as a distinct failure mode.

APRA CPS 230

[fact; source: https://handbook.apra.gov.au/standard/cps-230] CPS 230 requires APRA-regulated entities to identify, assess, and manage operational risks with effective internal controls, monitoring, and remediation, to maintain critical operations through severe disruptions, and to manage service-provider risk.
[inference; source: https://handbook.apra.gov.au/standard/cps-230] CPS 230 does not explicitly discuss non-human principals, autonomous agents, or permission inheritance under continuous operation.
[inference; source: https://handbook.apra.gov.au/standard/cps-230] The amplification mechanism is therefore prudentially relevant under CPS 230, because an automated system that can continuously exercise broad permissions changes the severity and speed of an operational-risk scenario, but the argument is constructed from general operational-risk and internal-control obligations rather than agent-specific wording.

DORA

[fact; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] Official ESMA and EBA DORA pages show that the regulation establishes a framework for Information and Communication Technology (ICT) risk management, ICT-related incident management and reporting, resilience testing, and ICT third-party risk management.
[inference; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] Those official pages confirm that DORA is aimed at digital operational resilience in financial entities, but they do not explicitly identify agentic permission amplification or non-human principals operating at machine speed as a separately named mechanism.
[inference; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] DORA therefore supports the control obligation, especially around ICT risk management, testing, incident handling, and third-party oversight, but not the specific causal language that an agent inherits the worst-case interpretation of a human permission set.

NIST AI RMF 1.0 and Playbook

[fact; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10] NIST AI RMF 1.0 says AI safety practices should include rigorous testing, real-time monitoring, and the ability to shut down, modify, or have human intervention into systems that deviate from intended or expected functionality.
[fact; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10] NIST AI RMF 1.0 also says policies and procedures should define roles and responsibilities for human-AI configurations and oversight of AI systems, and that processes for human oversight should be defined, assessed, and documented.
[fact; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10] Appendix C of AI RMF 1.0 says human roles and responsibilities in decision making and overseeing AI systems need to be clearly defined and differentiated, and that AI systems can span from fully autonomous to fully manual configurations.
[fact; source: https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook] The NIST AI RMF Playbook is an official companion that maps suggested actions to the Govern, Map, Measure, and Manage functions, but it is explicitly voluntary and not a checklist.
[inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook] AI RMF 1.0 explicitly recognises autonomy, human oversight, monitoring, and intervention needs, so it is closer than the four named core frameworks to the amplification mechanism, but it still does not explicitly say that agents should receive narrower credential scopes than their invoking users.

NIST CAISI guidance

[fact; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems] CAISI's 2026 Request for Information notice says AI agent systems pose distinct risks when AI model outputs are combined with software functionality and specifically calls out the need for methods to constrain and monitor the extent of agent access in the deployment environment.
[fact; source: https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] CAISI's 2025 technical blog describes evaluation scenarios for remote code execution, database exfiltration, and automated phishing in agent environments, and reports materially higher attack-success rates for tailored attacks than baseline attacks.
[inference; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] These NIST publications do not use the exact phrase "worst-case permission inheritance," but they explicitly frame agent access scope, autonomous action, and high-consequence task execution as distinct security problems.

AWS and Microsoft platform guidance

[fact; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] AWS states that agents operate at greater scale and speed than human actors, that excessive privileges therefore carry more potential for unintended consequences, and that least privilege is at least as important in agentic contexts as in traditional systems.
[fact; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] AWS also says deterministic external controls should govern which tools an agent can access, what operations it can perform, and what data it can reach, and that agents require their own identities with least-privilege authorization enforced at the infrastructure level.
[fact; source: https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/] AWS's agentic security scoping matrix distinguishes agency from autonomy, says agency is about capabilities and permissions, and warns that compromised agents can autonomously execute unauthorized transactions, modify critical infrastructure, or operate maliciously for extended periods without detection.
[fact; source: https://aws.amazon.com/ai/security/generative-ai-scoping-matrix/] AWS's generative-AI security scoping matrix says least-privilege access control to data should be implemented before context is added to inference requests.
[fact; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/security-and-governance; https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent#authentication-considerations-for-tools] Microsoft Copilot Studio documentation says tools can run with end-user or maker-provided credentials, can ask the end user before running, and can be controlled through data policies over tools, knowledge sources, triggers, skills, and HTTP requests.
[fact; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] Microsoft also says event triggers allow agents to act autonomously in response to external events, that published agents react automatically each time those triggers activate, and that triggers use the agent maker's credentials, which might allow users to access data and systems through that same authorization.
[fact; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] Microsoft data-loss-prevention guidance says administrators can require user authentication, block specific knowledge sources, block connectors used as tools, block HTTP requests, and block event triggers to prevent data exfiltration and unwanted autonomous behavior.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] The clearest explicit articulation of the amplification mechanism in the current source set comes from modern agent-security guidance and platform documentation rather than from the older control frameworks themselves.

First-principles and automation-risk support

[fact; source: https://www.brookings.edu/articles/keeping-workers-safe-in-the-automation-revolution/] Brookings' automation review says robots and automation can reduce some categories of human error and monotony but can also introduce new hazards, safety risks, and stressors, especially as work is reallocated to faster automated systems.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations; https://www.brookings.edu/articles/keeping-workers-safe-in-the-automation-revolution/] The first-principles argument is that automation removes fatigue, delay, and selective human restraint while preserving or expanding system privileges, so the same credential scope produces a larger and faster potential error surface when exercised by an agent than when exercised manually by a human.

§3 Reasoning

[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] The strongest evidence inside the named security frameworks is structural rather than narrative: they define the control objects needed to prevent amplification, such as per-session authorization, minimum privilege, account lifecycle, separation of duties, and privileged-function logging.
[inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] The prudential frameworks are even less explicit on the mechanism, because they regulate operational resilience and control effectiveness at a higher level of abstraction than the NIST security texts.
[inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] The explicit mechanism emerges when later AI-specific guidance is overlaid on those controls: autonomy, monitoring, intervention, constrained access, and distinct agent attack paths are all described directly.
[inference; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] Microsoft platform guidance makes the inheritance problem unusually concrete, because autonomous triggers can act with maker credentials unless administrators deliberately constrain authentication modes, connectors, and triggers.

§4 Consistency Check

[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] No primary or official-summary source in the four named frameworks explicitly used the phrases "machine speed," "agent credential scoping," or "worst-case permission inheritance" as a defined risk mechanism.
[fact; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] Supplementary guidance does explicitly discuss autonomy, monitoring, intervention, constrained access, and autonomous execution with delegated credentials.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] There is no contradiction between those two findings, because the later guidance extends and operationalises the older control principles rather than overturning them.

§5 Depth and Breadth Expansion

[inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] Regulatory lens: for APRA or DORA audiences, the most persuasive move is not to claim that regulators already named the mechanism, but to show that agentic amplification materially worsens the operational-risk scenarios those regulators already require firms to control.
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] Technical lens: for architecture audiences, the strongest line is that service identities, processes acting on behalf of users, per-session authorization, privileged-function logging, and external policy enforcement already imply agent-specific credential minimisation.
[inference; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] Platform-governance lens: in Microsoft 365 and Copilot Studio contexts, trigger governance, connector blocking, endpoint filtering, and explicit credential mode selection are direct mitigations against accidental amplification through business-led agent creation.
[inference; source: https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] Operational-security lens: the relevant risk is not only misuse by a well-behaved agent, but also compromise, hijacking, or mis-specification of an agent that already has broad delegated access.

§6 Synthesis

(This section seeds the Findings below.)

Executive summary:

[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] The four named frameworks do not explicitly describe the worst-case permission-inheritance mechanism of agentic operation, so for NIST SP 800-207, NIST SP 800-53, APRA CPS 230, and DORA the amplification argument still has to be assembled from minimum permissions, operational-risk, resilience, and monitoring principles.
[fact; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] Newer AI-specific guidance is more explicit: NIST AI RMF 1.0 addresses autonomy, human oversight, monitoring, and intervention; CAISI explicitly asks how to constrain and monitor agent access; AWS explicitly says agents operate at greater scale and speed than humans; and Microsoft explicitly warns that autonomous triggers can run with maker credentials.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention; https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] The practical conclusion is that the board-level obligation already exists under the core frameworks, but the clearest articulation of why agent deployment without agent-specific credential scoping is unsafe comes from later AI-security guidance and current platform controls.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] Minimum pre-deployment controls are separate agent identities, per-tool and per-action least privilege, external policy enforcement, logging and review of privileged actions, bounded autonomous triggers, and human approval for high-consequence actions. Key findings:

High confidence. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] None of the four named core frameworks explicitly states that an agent inherits the worst-case interpretation of a user's permissions by operating continuously at machine speed, even though all four require controls that become critical when that mechanism exists.
Medium confidence. [fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 comes closest inside the named frameworks because it explicitly defines subjects as combinations of user, service, and device, requires authorization to be checked for each session, and says access should be granted with only the least privileges needed to complete the task.
Medium confidence. [fact; source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] NIST SP 800-53 explicitly applies least privilege to users and processes acting on behalf of users, requires account lifecycle controls and privilege review, and requires logging when privileged functions run, but it still leaves the machine-speed amplification narrative implicit rather than explicit.
Medium confidence. [inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] APRA CPS 230 and DORA clearly impose operational-risk, resilience, monitoring, testing, and third-party-risk duties, but their currently accessible official texts and summaries do not identify autonomous permission inheritance as a separately named mechanism.
Medium confidence. [inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook] NIST AI RMF 1.0 explicitly recognises fully autonomous to fully manual human-AI configurations, requires defined human oversight processes, and recommends real-time monitoring plus the ability to shut down or intervene, which makes it a useful bridge between general control frameworks and agent-specific risk.
Medium confidence. [inference; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] Current NIST CAISI publications explicitly ask how to constrain and monitor agent access and describe agent hijacking, remote code execution, data exfiltration, and automated phishing against agents, which indicates that agent access scope is being treated as an active security problem.
Medium confidence. [fact; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/] AWS explicitly says agents operate at greater scale and speed than humans, that excessive privileges therefore carry greater unintended-consequence risk, and that agents need their own identities with deterministic external controls.
Medium confidence. [fact; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent#authentication-considerations-for-tools; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] Microsoft Copilot Studio documentation makes the risk concrete by documenting autonomous event triggers, maker-credential execution, configurable end-user versus maker credentials for tools, and administrative controls to block connectors, HTTP actions, knowledge sources, and triggers.
High confidence. [inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] For a board risk committee, the most defensible claim is not that regulators already named the mechanism, but that deploying agents before reducing delegated permissions would predictably intensify an already-known control weakness into a faster and larger operational-risk event.
High confidence. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] The minimum safe-control set before write-capable agent deployment is agent-specific identity separation, per-tool least privilege, privilege review and logging, bounded trigger and connector policies, and human approval for actions whose failure would materially affect data, funds, or regulated operations. Evidence map:

Claim	Source	Confidence	Notes
[inference] The four named frameworks require relevant controls but do not explicitly name worst-case permission inheritance under agentic operation.	https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora	high	Explicit-control language is present; explicit amplification language is not.
[fact] NIST SP 800-207 explicitly requires minimum privilege, authorization checked for each session, and subject combinations that include services.	https://csrc.nist.gov/pubs/sp/800/207/final	medium	Strongest core-framework support for agent-specific scoping, but this row rests on one primary source.
[fact] NIST SP 800-53 explicitly applies least privilege to processes acting on behalf of users and requires privilege review and logging when privileged functions run.	https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final	medium	Strong control-catalog support, but not explicit machine-speed wording and not independently corroborated here.
[inference] APRA CPS 230 and DORA support the argument through operational-risk and resilience duties, not through explicit agent language.	https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716	medium	DORA evidence is limited to official summaries and rulebook structure in this runtime.
[fact] NIST AI RMF 1.0 explicitly covers autonomous configurations, human oversight, monitoring, and intervention.	https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook	medium	Strong bridge from general AI governance to agent risk, but not independently sourced outside NIST here.
[fact] CAISI explicitly frames constrained and monitored agent access as a live security question and demonstrates high-consequence attack paths in agents.	https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations	medium	Strong NIST signal on agent security, but still same-institution evidence.
[fact] AWS explicitly says agents operate at greater scale and speed than humans and need their own least-privilege identities and external controls.	https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/	medium	Clear articulation of amplification, but both sources are AWS vendor materials.
[fact] Microsoft documents autonomous triggers, maker-credential execution, and administrator controls to restrict tools, triggers, and data movement.	https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent#authentication-considerations-for-tools; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention	medium	Concrete platform evidence, but all sources are Microsoft documentation.
[inference] Board and regulator audiences should treat agent deployment into an over-privileged estate as an amplifier of an existing control failure, not as a neutral productivity layer.	https://handbook.apra.gov.au/standard/cps-230; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations	high	Combines prudential duty with explicit agent mechanism.
[inference] Minimum pre-deployment controls are separate agent identities, bounded permissions, privileged-action logging, trigger restrictions, and human approval for high-consequence actions.	https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention	high	The control package follows directly from the combined evidence.
Assumptions:

[assumption; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] The official ESMA and EBA pages are sufficient to characterise DORA at the level needed for this item, even though the full EUR-Lex text could not be cleanly retrieved in this runtime. Justification: the research question turns on whether DORA explicitly names the amplification mechanism, and the official summary layer was enough to confirm that it does not do so overtly.
[assumption; source: https://www.brookings.edu/articles/keeping-workers-safe-in-the-automation-revolution/] The Brookings automation article is used only as supporting illustration for first-principles automation risk, not as a primary basis for claims about prudential or security frameworks. Justification: framework conclusions were anchored to primary or official-summary sources. Analysis:
[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] The decisive distinction is between frameworks that define control primitives and guidance that explicitly names the causal mechanism. SP 800-207 and SP 800-53 clearly define the primitives, including service identities, processes acting on behalf of users, minimum privilege, account management, and privileged-function logging, but neither one says in plain language that an agent turns latent over-privilege into a higher-speed failure mode.
[inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] APRA CPS 230 and DORA were weighed as board-level obligation setters rather than as technical-design documents, so they contribute legal and prudential force to the argument but not much specificity about how permission inheritance works in agent tooling.
[inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems] AI RMF 1.0 and CAISI narrow the gap by explicitly discussing autonomy, oversight, intervention, and constrained access, which makes them better evidence for arguing that agent deployment changes the control profile even when the delegated permissions are unchanged.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] AWS and Microsoft were given high weight on the explicit-mechanism question because they document real deployment patterns, including machine-speed action, autonomous triggers, external tool access, and delegated credentials, even though vendor guidance carries less normative force than regulation.
[inference; source: https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations; https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/] The blast-radius differential is strongest when the analysis shifts from routine intended use to mis-specification, compromise, or hijacking, because those are the cases where continuous execution and broad delegated access most clearly transform a human-speed problem into an automated high-consequence event. Risks, gaps, uncertainties:
[fact; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] DORA confidence is lower than NIST confidence because the full EUR-Lex text was not cleanly retrievable in this runtime.
[inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10] AI RMF 1.0 is voluntary guidance, so it strengthens the mechanism argument but does not by itself create a prudential obligation equivalent to APRA CPS 230 or DORA.
[inference; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/security-and-governance; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] Vendor documentation shows available mitigations, but actual enforceability in a specific bank tenant depends on how identities, connectors, logging, and approval workflows are implemented in that environment. Open questions:
[inference; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems] Will NIST convert current CAISI research on agent access constraint and monitoring into formal guidance that directly updates or profiles existing NIST control frameworks?
[inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] Will APRA, the Reserve Bank of New Zealand, or European supervisors issue agent-specific interpretations that explicitly connect over-privileged delegated identities to operational-resilience breaches?
[inference; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] In the target Microsoft 365 and AWS Bedrock estate, which tasks can be decomposed into separate agent identities and approval gates without destroying the business value that motivated agent adoption?

§7 Recursive Review

[fact; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] Review outcome: all conclusion-bearing statements in the synthesis are either source-bound facts, explicitly marked inferences, or explicitly marked assumptions, and the central distinction between named-framework silence and supplementary-guidance explicitness remains consistent across sections.
[inference; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] The main residual uncertainty is not the existence of agent amplification as a security problem, which current NIST publications and platform guidance treat as real, but the timing and form in which prudential and security frameworks will encode that mechanism more explicitly.

Findings

(Populated from §6 Synthesis above.)

Executive Summary

[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] The four named frameworks do not explicitly describe the worst-case permission-inheritance mechanism of agentic operation, so for NIST SP 800-207, NIST SP 800-53, APRA CPS 230, and DORA the amplification argument still has to be assembled from minimum permissions, operational-risk, resilience, and monitoring principles.
[fact; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] Newer AI-specific guidance is more explicit: NIST AI RMF 1.0 addresses autonomy, human oversight, monitoring, and intervention; CAISI explicitly asks how to constrain and monitor agent access; AWS explicitly says agents operate at greater scale and speed than humans; and Microsoft explicitly warns that autonomous triggers can run with maker credentials.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention; https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] The practical conclusion is that the board-level obligation already exists under the core frameworks, but the clearest articulation of why agent deployment without agent-specific credential scoping is unsafe comes from later AI-security guidance and current platform controls.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] Minimum pre-deployment controls are separate agent identities, per-tool and per-action least privilege, external policy enforcement, logging and review of privileged actions, bounded autonomous triggers, and human approval for high-consequence actions.

Key Findings

High confidence. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] None of the four named core frameworks explicitly states that an agent inherits the worst-case interpretation of a user's permissions by operating continuously at machine speed, even though all four require controls that become critical when that mechanism exists.
Medium confidence. [fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 comes closest inside the named frameworks because it explicitly defines subjects as combinations of user, service, and device, requires authorization to be checked for each session, and says access should be granted with only the least privileges needed to complete the task.
Medium confidence. [fact; source: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] NIST SP 800-53 explicitly applies least privilege to users and processes acting on behalf of users, requires account lifecycle controls and privilege review, and requires logging when privileged functions run, but it still leaves the machine-speed amplification narrative implicit rather than explicit.
Medium confidence. [inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] APRA CPS 230 and DORA clearly impose operational-risk, resilience, monitoring, testing, and third-party-risk duties, but their currently accessible official texts and summaries do not identify autonomous permission inheritance as a separately named mechanism.
Medium confidence. [inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook] NIST AI RMF 1.0 explicitly recognises fully autonomous to fully manual human-AI configurations, requires defined human oversight processes, and recommends real-time monitoring plus the ability to shut down or intervene, which makes it a useful bridge between general control frameworks and agent-specific risk.
Medium confidence. [inference; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations] Current NIST CAISI publications explicitly ask how to constrain and monitor agent access and describe agent hijacking, remote code execution, data exfiltration, and automated phishing against agents, which indicates that agent access scope is being treated as an active security problem.
Medium confidence. [fact; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/] AWS explicitly says agents operate at greater scale and speed than humans, that excessive privileges therefore carry greater unintended-consequence risk, and that agents need their own identities with deterministic external controls.
Medium confidence. [fact; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent#authentication-considerations-for-tools; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] Microsoft Copilot Studio documentation makes the risk concrete by documenting autonomous event triggers, maker-credential execution, configurable end-user versus maker credentials for tools, and administrative controls to block connectors, HTTP actions, knowledge sources, and triggers.
High confidence. [inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] For a board risk committee, the most defensible claim is not that regulators already named the mechanism, but that deploying agents before reducing delegated permissions would predictably intensify an already-known control weakness into a faster and larger operational-risk event.
High confidence. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention] The minimum safe-control set before write-capable agent deployment is agent-specific identity separation, per-tool least privilege, privilege review and logging, bounded trigger and connector policies, and human approval for actions whose failure would materially affect data, funds, or regulated operations.

Evidence Map

Claim	Source	Confidence	Notes
[inference] The four named frameworks require relevant controls but do not explicitly name worst-case permission inheritance under agentic operation.	https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora	high	Explicit-control language is present; explicit amplification language is not.
[fact] NIST SP 800-207 explicitly requires minimum privilege, authorization checked for each session, and subject combinations that include services.	https://csrc.nist.gov/pubs/sp/800/207/final	medium	Strongest core-framework support for agent-specific scoping, but this row rests on one primary source.
[fact] NIST SP 800-53 explicitly applies least privilege to processes acting on behalf of users and requires privilege review and logging when privileged functions run.	https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final	medium	Strong control-catalog support, but not explicit machine-speed wording and not independently corroborated here.
[inference] APRA CPS 230 and DORA support the argument through operational-risk and resilience duties, not through explicit agent language.	https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716	medium	DORA evidence is limited to official summaries and rulebook structure in this runtime.
[inference] NIST AI RMF 1.0 explicitly covers autonomous configurations, human oversight, monitoring, and intervention, which makes it a useful bridge from general AI governance to agent risk.	https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/itl/ai-risk-management-framework/ai-rmf-playbook	medium	The bridge conclusion is interpretive and rests on NIST materials only.
[inference] CAISI publications explicitly ask how to constrain and monitor agent access and document high-consequence attack paths against agents, indicating that agent access scope is being treated as an active security problem.	https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations	medium	The active-problem conclusion is interpretive and rests on same-institution evidence.
[fact] AWS explicitly says agents operate at greater scale and speed than humans and need their own least-privilege identities and external controls.	https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/	medium	Clear articulation of amplification, but both sources are AWS vendor materials.
[fact] Microsoft documents autonomous triggers, maker-credential execution, and administrator controls to restrict tools, triggers, and data movement.	https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-tools-custom-agent#authentication-considerations-for-tools; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention	medium	Concrete platform evidence, but all sources are Microsoft documentation.
[inference] Board and regulator audiences should treat agent deployment into an over-privileged estate as an amplifier of an existing control failure, not as a neutral productivity layer.	https://handbook.apra.gov.au/standard/cps-230; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations	high	Combines prudential duty with explicit agent mechanism.
[inference] Minimum pre-deployment controls are separate agent identities, bounded permissions, privileged-action logging, trigger restrictions, and human approval for high-consequence actions.	https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-data-loss-prevention	high	The control package follows directly from the combined evidence.

Assumptions

[assumption; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] Assumption: the official ESMA and EBA pages are sufficient to characterise DORA at the level needed for this item, even though the full EUR-Lex text could not be cleanly retrieved in this runtime. Justification: the research question turns on whether DORA explicitly names the amplification mechanism, and the official summary layer was enough to confirm that it does not do so overtly.
[assumption; source: https://www.brookings.edu/articles/keeping-workers-safe-in-the-automation-revolution/] Assumption: the Brookings automation article is used only as supporting illustration for first-principles automation risk, not as a primary basis for claims about prudential or security frameworks. Justification: framework conclusions were anchored to primary or official-summary sources.

Analysis

[inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final] The decisive distinction is between frameworks that define control primitives and guidance that explicitly names the causal mechanism. SP 800-207 and SP 800-53 clearly define the primitives, including service identities, processes acting on behalf of users, minimum privilege, account management, and privileged-function logging, but neither one says in plain language that an agent turns latent over-privilege into a higher-speed failure mode.
[inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] APRA CPS 230 and DORA were weighed as board-level obligation setters rather than as technical-design documents, so they contribute legal and prudential force to the argument but not much specificity about how permission inheritance works in agent tooling.
[inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems] AI RMF 1.0 and CAISI narrow the gap by explicitly discussing autonomy, oversight, intervention, and constrained access, which makes them better evidence for arguing that agent deployment changes the control profile even when the delegated permissions are unchanged.
[inference; source: https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/; https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about] AWS and Microsoft were given high weight on the explicit-mechanism question because they document real deployment patterns, including machine-speed action, autonomous triggers, external tool access, and delegated credentials, even though vendor guidance carries less normative force than regulation.
[inference; source: https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations; https://aws.amazon.com/blogs/security/the-agentic-ai-security-scoping-matrix-a-framework-for-securing-autonomous-ai-systems/] The blast-radius differential is strongest when the analysis shifts from routine intended use to mis-specification, compromise, or hijacking, because those are the cases where continuous execution and broad delegated access most clearly transform a human-speed problem into an automated high-consequence event.

Risks, Gaps, and Uncertainties

[fact; source: https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora; https://www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17716] DORA confidence is lower than NIST confidence because the full EUR-Lex text was not cleanly retrievable in this runtime.
[inference; source: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10] AI RMF 1.0 is voluntary guidance, so it strengthens the mechanism argument but does not by itself create a prudential obligation equivalent to APRA CPS 230 or DORA.
[inference; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/security-and-governance; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] Vendor documentation shows available mitigations, but actual enforceability in a specific bank tenant depends on how identities, connectors, logging, and approval workflows are implemented in that environment.

Open Questions

[inference; source: https://www.nist.gov/news-events/news/2026/01/caisi-issues-request-information-about-securing-ai-agent-systems] Will NIST convert current CAISI research on agent access constraint and monitoring into formal guidance that directly updates or profiles existing NIST control frameworks?
[inference; source: https://handbook.apra.gov.au/standard/cps-230; https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora] Will APRA, the Reserve Bank of New Zealand, or European supervisors issue agent-specific interpretations that explicitly connect over-privileged delegated identities to operational-resilience breaches?
[inference; source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-triggers-about; https://aws.amazon.com/blogs/security/four-security-principles-for-agentic-ai-systems/] In the target Microsoft 365 and AWS Bedrock estate, which tasks can be decomposed into separate agent identities and approval gates without destroying the business value that motivated agent adoption?