Who is accountable for AI agent actions under regulated environments like DORA?

Why This Matters for Security Teams

Under DORA, accountability does not move to the model, the vendor, or the toolchain. It stays with the organisation that deploys the AI agent and decides what it may access, when it may act, and how its actions are reviewed. That is why regulated environments care less about whether an agent authenticated and more about whether each action can be justified, replayed, and assigned to a control owner.

Current guidance from NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework points toward governance that is auditable at runtime, not just documented at design time. That aligns with NHIMG research on agent behaviour: the AI Agents: The New Attack Surface report shows 80% of organisations reporting agent actions beyond intended scope, which is exactly the kind of drift regulators expect firms to control. In practice, many security teams encounter accountability gaps only after an agent has already accessed data or triggered a downstream workflow, rather than through intentional control testing.

How It Works in Practice

For AI agents in regulated environments, accountability is built by tracing every meaningful action back to a human-owned policy decision. The organisation needs to show who approved the use case, what the agent was allowed to do, which data it could reach, and which runtime guardrails were active when the action occurred. That usually requires policy-as-code, immutable logs, and versioned prompts, tools, and policies.

In practice, this means separating identity from authority. A workload identity proves what the agent is, while authorisation determines what it may do right now. Standards such as OWASP Agentic AI Top 10 and the NHIMG OWASP NHI Top 10 both reinforce the need to control tool use, data exposure, and privilege escalation paths. For DORA-style evidence, teams should retain:

• the policy version that approved the action
• the runtime context, including inputs, data scope, and tool invocation
• the human or system owner responsible for the workflow
• the audit record showing whether the action was blocked, allowed, or escalated

This becomes especially important when agents operate with chained tools or autonomous retries. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives and EU Digital Operational Resilience Act (DORA) both support the same operational principle: if the organisation cannot reconstruct decision-making after the fact, accountability is incomplete. These controls tend to break down when an agent is allowed to chain multiple tools across systems because the effective decision path becomes opaque and difficult to replay precisely.

Common Variations and Edge Cases

Tighter agent governance often increases operational overhead, requiring organisations to balance automation speed against evidentiary rigor. That tradeoff is real in production environments, especially where teams want autonomous action but also need defensible accountability under DORA, incident review, or internal audit.

One common edge case is delegated execution. If an agent acts on behalf of a human, the human does not automatically become the control owner for every downstream effect. Best practice is evolving, but current guidance suggests distinguishing between requestor, approver, operator, and system owner so responsibility does not collapse into a single vague label. Another edge case is vendor-hosted agents: outsourcing the model does not outsource accountability for the regulated process.

Another practical issue is evidence retention. Long-lived logs without policy versioning may show that an action occurred, but not why it was permitted. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because lifecycle ownership must extend to agent configuration, credential scope, and revocation. For threat modelling, MITRE ATLAS adversarial AI threat matrix and NIST Cybersecurity Framework 2.0 help map how misuse, drift, or compromise should be detected and contained. The answer becomes especially fragile when organisations rely on static role assignments for agents that change behaviour at runtime.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who should be accountable for AI agent actions in enterprise systems?
• Who is accountable when an AI agent accesses regulated data improperly?
• What is the best way to score AI agent workflows in production-like environments?