Regulators and auditors rarely ask about "agent identity" by name, but most of what they ask for depends on it. Logs that show who did what, human oversight of automated decisions, access limited to what is necessary, security of AI systems and the ability to report incidents all assume you can identify each agent, control its access and trace its actions. This guide maps the EU AI Act (including the dates changed by the 2026 AI Omnibus), the NIST AI Risk Management Framework, ISO/IEC 42001 and existing security and data protection law to the identity and access controls that produce the evidence. It is for security, IAM and GRC teams who want one control set, not parallel programmes. It is not legal advice: confirm your obligations with your legal and compliance teams.
Key takeaways
- Identity is the evidence layer: inventory, ownership, least privilege, attributable logging, human approval and revocation for agents produce most of what AI and security frameworks ask auditors to check.
- The AI Act dates moved: according to the European Commission, the AI Omnibus entered into force on 27 July 2026 and pushed high-risk obligations to 2 December 2027 (Annex III uses) and 2 August 2028 (AI in Annex I regulated products). Transparency rules have applied since August 2026.
- Most enterprise agents are not high-risk, but none are out of scope: GDPR, DORA, NIS2, PCI DSS and SOX already require access control, logging and incident reporting for any identity that touches regulated data or systems, human or not.
- Deployers carry real duties: under Article 26, organisations using high-risk AI must assign competent human oversight, monitor operation and keep logs under their control for at least six months, and changing an AI system's purpose can make you its provider.
- Build once, map many times: one agent identity control set, mapped to the AI Act, NIST AI RMF, ISO/IEC 42001, NIST CSF 2.0, ISO/IEC 27001 and sector rules, is cheaper to run and easier to evidence than separate programmes.
The EU AI Act
Regulation (EU) 2024/1689, the AI Act, entered into force on 1 August 2024 and, according to the European Commission, became generally applicable on 2 August 2026 with staged exceptions. It regulates AI by use, so an agent is assessed on what it does. Article numbers below refer to the 2024 text; the Omnibus amended parts of it, so check the consolidated version. For a full walkthrough see the EU AI Act Compliance Guide.
Timeline after the AI Omnibus
The Commission proposed the "AI Omnibus" on 19 November 2025; political agreement followed on 7 May 2026 and it entered into force on 27 July 2026. Key dates, from the Commission's AI Act page and the Future of Life Institute's implementation timeline:
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibited AI practices and AI literacy obligations |
| 2 August 2025 | Governance rules and obligations for general-purpose AI (GPAI) models |
| 2 August 2026 | The remainder of the Act, including Article 50 transparency; the AI Office and national authorities enforce |
| 2 December 2026 | Article 50(2) marking for generative systems already on the market before 2 August 2026; new Omnibus prohibitions on non-consensual intimate imagery and child sexual abuse material |
| 2 December 2027 | High-risk obligations for Annex III systems (for example employment, credit, education, critical infrastructure) |
| 2 August 2028 | High-risk obligations for AI in products regulated under Annex I (for example lifts or toys) |
The Commission reports that guidelines on transparency obligations were issued on 20 July 2026 and the first harmonised standard supporting the Act was published in the Official Journal on 19 October 2026.
When is an agent high-risk?
Annex III lists the high-risk areas, including biometrics, critical infrastructure, education, employment and worker management, access to essential services (such as credit scoring and life and health insurance pricing), law enforcement, migration and justice. A recruitment agent that filters applications falls under Annex III point 4(a); a coding or IT operations agent generally does not. Record the classification and reasoning for every agent.
Provider or deployer?
Most organisations deploy agents built on third-party models. Article 25(1) makes a deployer the provider, with the Article 16 obligations, if it puts its name on a high-risk system, substantially modifies it, or changes the intended purpose of an AI system, "including a general-purpose AI system", so that it becomes high-risk. Wiring a general-purpose agent into a hiring workflow can change your role, so repeat classification whenever an agent gains a new use or tool.
High-risk requirements that depend on identity
- Risk management (Article 9): a continuous process covering intended use and "reasonably foreseeable misuse". Agent threat models and approval gates belong here. See the AI Agent Threat Modelling Guide.
- Record-keeping (Articles 12 and 19): high-risk systems must "technically allow for the automatic recording of events (logs) over the lifetime of the system", and providers keep logs under their control for at least six months. That needs per-agent, attributable logs. See the AI Agent Observability and Incident Response Guide.
- Human oversight (Article 14): overseers must be able to override or reverse outputs and interrupt the system through "a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state". For agents: enforced approval gates and a working kill switch.
- Accuracy, robustness and cybersecurity (Article 15): Article 15(5) requires resilience "against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities". Prompt injection and credential abuse controls apply.
- Deployer obligations (Article 26): follow the instructions for use, assign oversight to people with "the necessary competence, training and authority", monitor operation and suspend use where there is a risk, keep logs under your control for at least six months, and inform workers before workplace use.
- Serious incident reporting (Article 73): providers report within the deadlines in the incident table below; deployers that identify a serious incident must inform the provider immediately (Article 26(5)).
Transparency (Article 50)
People must be told they are interacting with an AI system unless that is obvious, generated content must be marked in a machine-readable format, and deployers must disclose deep fakes. Meeting this depends on knowing where your agents are deployed, which is why inventory comes first.
Penalties
Under Article 99, breaching the prohibitions can bring fines of up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher. Breaches of provider, deployer (Article 26) and transparency (Article 50) obligations can bring up to EUR 15 million or 3%. Member States set the detailed rules.
NIST AI Risk Management Framework
The NIST AI RMF 1.0 (NIST AI 100-1, January 2023) is voluntary and use-case agnostic. It organises AI risk management into four functions, Govern, Map, Measure and Manage, broken into categories and subcategories. It is not regulation, but it gives a shared vocabulary for AI risk, and several subcategories read almost as agent identity requirements:
| AI RMF subcategory | What it says (summarised) | Agent identity control |
|---|---|---|
| GOVERN 1.6 | Mechanisms are in place to inventory AI systems | Agent registry with owner, purpose, tools and credentials |
| GOVERN 1.7 | Processes for decommissioning AI systems safely | Credential revocation and token clean-up when an agent is retired |
| GOVERN 2.1 | Roles, responsibilities and lines of communication are documented | Named business owner and technical owner per agent |
| GOVERN 6.1 and MAP 4.1 | Policies and mapping for third-party risks | Vetting of model providers, MCP servers and agent tools |
| MEASURE 2.7 | AI system security and resilience are evaluated and documented | Red teaming agents for privilege escalation and injection |
| MANAGE 2.4 | Mechanisms to disengage or deactivate AI systems | Kill switch and tested revocation runbook |
| MANAGE 4.1 and 4.3 | Post-deployment monitoring and incident response | Behavioural monitoring and agent-specific incident playbooks |
NIST AI 600-1, the Generative AI Profile (July 2024), defines risks unique to or made worse by generative AI, including information security and value chain and component integration. NIST IR 8596, the Cyber AI Profile, was released as an initial preliminary draft in December 2025; it is organised by CSF 2.0 outcomes, its comment period closed on 30 January 2026, and it remains a draft. The NCCoE has also published a concept paper on software and AI agent identity and authorisation (5 February 2026). See the NIST AI RMF Guide.
ISO/IEC 42001
ISO/IEC 42001 is the international standard for an AI management system (AIMS), used to establish, implement, maintain and continually improve how an organisation develops and uses AI. It is certifiable. BSI, an accredited certification body, describes an AIMS as covering governance, risk management, compliance and training, with clear lines of responsibility and continuous monitoring, and presents the standard as complementing ISO/IEC 27001. If you hold ISO/IEC 27001, extend its scope, risk process and internal audit to AI systems.
Auditors will ask which agents are in scope, who is accountable, how risks were treated and how operation is monitored. Registries, named owners, onboarding and retirement records, access reviews and incident records answer most of it. This guide does not reproduce the standard's clause numbers. See the ISO/IEC 42001 Guide.
Existing security and data protection rules
Agents are already in scope of rules that never mention AI. Treat each agent as an identity with access to data and systems, and these obligations follow:
- GDPR: Article 32 requires security appropriate to the risk and regular testing; Article 22 limits decisions "based solely on automated processing" with legal or similarly significant effects; Article 33 sets breach notification. In September 2026 Spain's regulator described the first breach notified to it as carried out through an attacker's AI agent; see Spain's First AI Agent Data Breach 2026 and the GDPR Compliance Guide for Security Teams.
- DORA (EU financial services, applying from 17 January 2025): Article 9(4)(c) limits access "to what is required for legitimate and approved functions and activities only", 9(4)(d) requires strong authentication, Article 10 detection of anomalous activity, and Article 28 keeps financial entities "fully responsible" when they use ICT third parties, AI providers included. See the DORA Guide.
- NIS2: Article 21(2) requires supply chain security, "access control policies and asset management" and multi-factor or continuous authentication, with national measures applying from 18 October 2024. See the NIS2 Directive Guide.
- PCI DSS v4.0.1: requirement 7.2.5 limits application and system accounts to the least privileges necessary, and 7.2.5.1 requires periodic review of their access, which covers agents that reach cardholder data. See the PCI DSS 4.0 Guide.
- SOX: Section 404 requires management to assess internal control over financial reporting, with auditor attestation for accelerated and large accelerated filers. Agents that can change financial data come within it. See the SOX ITGC Guide.
Incident clocks differ, and an agent incident can start several at once:
| Rule | Trigger | Deadline |
|---|---|---|
| AI Act Article 73 (providers of high-risk AI) | Serious incident | No later than 15 days; 2 days for a widespread infringement or an Article 3(49)(b) serious incident; 10 days where a person has died |
| GDPR Article 33 | Personal data breach | Without undue delay and, where feasible, within 72 hours; processors notify controllers without undue delay |
| NIS2 Article 23(4) | Significant incident | Early warning within 24 hours, incident notification within 72 hours, final report within one month of the notification |
| DORA Article 19 | Major ICT-related incident | Initial notification and reports to the competent authority, using the templates referred to in Article 20 |
Mapping identity controls to frameworks
AI Act references are to the high-risk regime unless stated. For mapping technique see the Control Mapping Guide.
| Control | EU AI Act | NIST AI RMF | ISO/IEC 42001 (AIMS area) | Security regulation |
|---|---|---|---|---|
| Agent inventory and registry | Supports Art. 9, 26; needed for Art. 50 scoping | GOVERN 1.6 | Scope of the AIMS | NIS2 Art. 21(2)(i) asset management |
| Named owner per agent | Art. 26(2) oversight assignment | GOVERN 2.1 | Lines of responsibility | DORA Art. 28(1)(a) accountability stays with the entity |
| Unique identity per agent | Art. 12 traceability | MEASURE 2.8 | Lines of responsibility | PCI DSS 7.2.5 application and system accounts |
| Least privilege, task-scoped access | Art. 15(5) resilience | MEASURE 2.7 | Risk management | DORA Art. 9(4)(c); NIS2 Art. 21(2)(i) |
| Human approval for high-impact actions | Art. 14(4)(d) override | MANAGE 2.4 | Risk management; training | GDPR Art. 22 safeguards; SOX segregation of duties |
| Attributable action logging | Art. 12, 19, 26(6) | MANAGE 4.1 | Continuous monitoring | GDPR Art. 32; DORA Art. 10 |
| Kill switch and revocation | Art. 14(4)(e) stop procedure | MANAGE 2.4; GOVERN 1.7 | Risk management | NIS2 Art. 21(2)(b) incident handling |
| Third-party AI and MCP vetting | Art. 25 value chain | GOVERN 6.1; MAP 4.1 | Risk management | DORA Art. 28; NIS2 Art. 21(2)(d) |
| Periodic access review | Art. 9 ongoing risk management | GOVERN 1.5 | Monitoring and improvement | PCI DSS 7.2.5.1 |
| Incident detection and reporting | Art. 26(5), 73 | MANAGE 4.3 | Continual improvement | GDPR Art. 33; NIS2 Art. 23; DORA Art. 19 |
Framework mapping
The same agent controls mapped to NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022 Annex A, CIS Controls v8.1 and the OWASP Top 10 for Agentic Applications for 2026.
| Control area | NIST CSF 2.0 | SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS v8.1 | OWASP Agentic |
|---|---|---|---|---|---|
| Agent inventory | ID.AM-02 | CM-8, PM-5 | 5.9 | Control 2 | Supports detection of ASI10 Rogue Agents |
| Ownership and roles | GV.RR-02 | AC-2 | 5.2 | Control 5 | ASI03 Identity and Privilege Abuse |
| Agent identity and authentication | PR.AA-01 | IA-9, AC-2 | 5.16 | Control 5 | ASI03 |
| Least privilege and separation of duties | PR.AA-05 | AC-6, AC-5 | 5.15, 5.18, 8.2, 5.3 | Control 6 | ASI02 Tool Misuse and Exploitation; ASI03 |
| Logging and monitoring | PR.PS-04, DE.CM-03 | AU-2, AU-3, AU-6, AU-11, SI-4 | 8.15, 8.16 | Control 8 | ASI10 Rogue Agents |
| Third-party models, tools and MCP servers | GV.SC-07 | SA-9, SR-6 | 5.19 | Control 15 | ASI04 Agentic Supply Chain Vulnerabilities |
| Incident response and reporting | RS.MA-01 | IR-4, IR-6 | 5.24, 5.26 | Control 17 | ASI10 Rogue Agents |
OWASP's guidance for ASI03 recommends human approval "for high-privilege or irreversible actions", and for ASI10 recommends "immutable and signed audit logs of all agent actions" and "kill-switches and credential revocation". These match AI Act Articles 12 and 14, so one control set serves both. See the Identity Security Regulatory Map.
Evidence auditors will ask for
Auditors test operation, not policy, so collect evidence from the systems that enforce controls; see the Audit Evidence and Continuous Controls Monitoring Guide.
- Inventory: agents with owner, purpose, AI Act classification, provider or deployer role, and the tools and data each can reach.
- Identity and access: each agent's identity, credentials and permissions, and access review records.
- Human oversight: which actions need approval, who approves, their training, and logs proving approval came first.
- Logs: actions attributed to the agent and the person it acted for, retained at least six months where Articles 19 or 26(6) apply. See the Log Management and Retention Guide.
- Kill switch tests: dated stop-and-revoke tests with timings.
- Incidents: agent playbooks, exercise records and a reporting-clock decision tree.
- Suppliers: assessments of model providers, platforms and MCP servers. See the Third-Party AI Risk Guide.
Common failure patterns
- Instructions mistaken for controls: telling an agent not to touch production is not oversight. In the Replit AI Agent Database Deletion 2025, an agent deleted a live database during a code freeze and against explicit instructions.
- Over-scoped machine credentials: in the PocketOS Database Deletion 2026, an agent in staging found an account-scoped token created for managing domains and used it to delete production data and backups.
- Classification done once: an agent assessed as minimal risk later gains a hiring or credit tool, and nobody repeats the Annex III or Article 25 analysis.
- Shared identities: several agents share one service account, so logs cannot show which acted. See the Shadow AI Discovery Guide for finding them.
- Logs the deployer does not control: logs sit in a vendor platform with short retention, so the six-month deployer duty fails.
- Assuming the vendor is accountable: a tribunal held Air Canada liable for its chatbot's wrong answer, rejecting its argument that it was not responsible for its agents; see Air Canada Chatbot Ruling 2024.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Agents in the registry with owner and AI Act classification recorded | Coverage of inventory and classification | Up, towards 100% |
| Agents running on shared or human credentials | Traceability gaps | Down, towards zero |
| Agents with access reviewed in the last review cycle | Least privilege is maintained, not just designed | Up |
| High-impact actions executed without a logged approval | Whether human oversight is enforced | Down, towards zero |
| Agents whose logs meet the retention requirement | Readiness for Articles 12, 19 and 26(6) and for investigations | Up |
| Median time to stop an agent and revoke its credentials in tests | Kill switch effectiveness | Down |
| AI suppliers and MCP servers assessed before use | Third-party risk coverage | Up |
See the Identity Security Metrics Guide.
Implementation roadmap
| Phase | Actions | Evidence produced |
|---|---|---|
| First 30 days | Register agents with owners; classify under the AI Act; confirm Article 50 disclosures | Registry, classifications, notices |
| Days 31-90 | Unique identity per agent; remove shared credentials; scope access; enforce approvals; centralise logs | Permission records, approval logs, retention settings |
| Days 91-180 | Test the kill switch; add agents to access reviews and playbooks; assess suppliers; map controls to each framework | Test records, review sign-offs, control map |
| Before 2 December 2027 | For Annex III agents: risk management, trained overseers, monitoring and incident procedures | High-risk compliance file |
The Agentic AI Security Policy Template gives the policy wording, and the Agentic AI Identity Maturity Model sets targets. See also the Identity Governance for AI Agents Guide.
Practitioner checklist
- Register every agent with a named owner, purpose, tools and credentials.
- Classify each agent under the AI Act, record your provider or deployer role, and repeat when its use changes.
- Give each agent a unique identity and remove shared and human credentials.
- Scope access to the task and review agent permissions on a fixed cycle.
- Enforce human approval for high-impact and irreversible actions, and name and train the people who approve.
- Keep attributable logs under your control for at least six months where the AI Act applies.
- Test the kill switch and credential revocation, and record the results.
- Map incident playbooks to the AI Act, GDPR, NIS2 and DORA reporting clocks.
- Assess model providers and MCP servers before use.
- Track the consolidated AI Act text, harmonised standards and Commission guidelines.
Standards and references
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- European Commission: AI Act
- Future of Life Institute: EU AI Act Implementation Timeline
- NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1
- NIST: AI 600-1 Generative Artificial Intelligence Profile
- NIST: IR 8596 Cyber AI Profile (Initial Preliminary Draft)
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- BSI: ISO/IEC 42001 AI Management System
- OWASP: Top 10 for Agentic Applications for 2026
- EUR-Lex: Regulation (EU) 2016/679 (General Data Protection Regulation)
- EUR-Lex: Regulation (EU) 2022/2554 (Digital Operational Resilience Act)
- EUR-Lex: Directive (EU) 2022/2555 (NIS2 Directive)
Related NHI Mgmt Group resources: EU AI Act Compliance Guide · Agentic AI Security Policy Template · Agentic AI Identity Maturity Model · Identity Governance for AI Agents Guide · Global AI Regulation Map. This guide summarises the EU AI Act, the NIST AI RMF, ISO/IEC 42001 and related security and data protection rules as they apply to AI agents as of October 2026 and is not legal advice.