Accountability sits with the bank’s security, IAM, and risk leadership, because the mandate requires a documented plan and concrete mitigations, not a vague policy statement. Teams should align that plan with existing resilience obligations such as DORA, since the overlap makes identity controls part of both compliance and operational readiness.
Why This Matters for Security Teams
ECB AI-threat readiness is not a paper exercise. The accountability question lands with the bank’s security, IAM, and risk leaders because they own the controls that turn a mandate into evidence: identity governance, privileged access, monitoring, and recovery. That matters even more when AI agents can chain tools and act faster than human review cycles, which is why current guidance increasingly treats agent identity and runtime authorisation as a resilience issue, not just an IT issue. NHI Management Group’s research on the 52 NHI breaches Report shows how identity failures repeatedly become breach pathways, while the ECB’s expectation for a documented plan mirrors the operational discipline seen in CISA cyber threat advisories. In practice, many security teams encounter AI-readiness gaps only after an incident review forces them to prove who was accountable for controls that were never clearly assigned.
How It Works in Practice
Accountability should be mapped to named control owners, not a generic steering committee. Security leadership typically owns the detection, containment, and hardening measures; IAM owns machine and agent identity, least privilege, and credential lifecycle; risk leadership owns the documented risk acceptance, testing cadence, and board-level reporting. That split matters because AI-threat readiness is usually a control system made up of workload identity, conditional access, secrets hygiene, logging, and response playbooks, not a single policy statement.
For agentic and AI-enabled workloads, the plan should show how runtime access is constrained, how elevated rights are issued only when needed, and how compromise is contained if an agent misbehaves. Best practice is evolving toward intent-based authorisation, short-lived credentials, and workload identity rather than static, long-lived entitlements. That direction aligns with the OWASP NHI Top 10 and the MITRE ATLAS adversarial AI threat matrix, which both emphasise how AI systems can be repurposed or coerced into unsafe actions.
- Define one accountable owner for each control domain: IAM, security operations, model governance, and enterprise risk.
- Document how AI identities are issued, monitored, rotated, and revoked, including service accounts and API credentials.
- Use policy-as-code and runtime checks so approvals reflect current context, not pre-approved access assumptions.
- Test recovery paths for tool abuse, prompt injection, credential theft, and lateral movement by autonomous workflows.
The ECB mandate is easier to satisfy when evidence is operational, such as access reviews, alerting thresholds, and incident drills tied to specific owners, rather than committee minutes alone. These controls tend to break down when AI workloads share broad platform credentials across multiple environments because attribution and revocation become too diffuse to prove quickly.
Common Variations and Edge Cases
Tighter AI-threat controls often increase operational overhead, requiring organisations to balance rapid experimentation against evidence, segregation of duties, and auditability. That tradeoff becomes sharper in banks running both conventional software and agentic AI, because some teams assume existing IAM reviews are enough while others push for separate AI control owners.
Current guidance suggests the accountability model should change with the use case. For internal copilots, risk may sit mainly with the application owner and IAM team. For autonomous agents that can move funds, touch customer data, or trigger workflow actions, accountability usually expands to include the business owner, cyber risk, and change management. There is no universal standard for this yet, which is why the strongest programmes document decision rights explicitly and link them to resilience obligations such as DORA. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now is useful here because it frames identity failure as an enterprise control problem, not a tooling problem. Where AI systems span outsourced models, shared cloud accounts, and multiple business units, accountability often becomes fragmented unless one executive sponsor is assigned to own the control evidence end to end.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Addresses agent misuse and unsafe autonomous actions needing named ownership. |
| CSA MAESTRO | GOV-01 | Governance requirements map directly to ECB accountability and evidence. |
| NIST AI RMF | GOVERN | Govern function requires accountable roles and traceable AI risk management. |
| NIST CSF 2.0 | GV.RM-01 | Risk management governance supports documented readiness and control ownership. |
| NIST Zero Trust (SP 800-207) | PL-2 | Zero trust planning supports limiting AI identities and runtime privilege. |
Assign control owners for agent permissions, runtime checks, and abuse response.
