Agentic AI Compliance: EU AI Act, NIST & ISO 42001

Regulators and auditors rarely ask about "agent identity" by name, but most of what they ask for depends on it. Logging that shows who did what, human oversight of automated decisions, access limited to what is necessary, security of AI systems and the ability to respond to incidents all assume you can identify each agent, control its access and trace its actions. This guide maps the main AI and security frameworks, including the EU AI Act, the NIST AI Risk Management Framework, ISO/IEC 42001 and existing security regulation, to the identity and access controls that provide the evidence. It is written for security, IAM and GRC teams and is not legal advice; confirm your obligations with your legal and compliance teams.

Key takeaways

Identity controls for agents (inventory, ownership, least privilege, logging, human oversight and revocation) produce the evidence that most AI and security frameworks ask for.
Under the EU AI Act, high-risk obligations have been deferred by the 2026 Digital Omnibus to 2 December 2027 (stand-alone Annex III systems) and 2 August 2028 (AI in regulated products under Annex I). Transparency obligations under Article 50 have applied since 2 August 2026.
Most enterprise agents will not be "high-risk" under the AI Act, but they remain subject to data protection, sector and cyber security rules, which already require access control, logging and incident response.
Build one control set for agent identity and map it to each framework, rather than running parallel programmes.

The EU AI Act

Timeline

The AI Act (Regulation (EU) 2024/1689) applies in stages. The Digital Omnibus on AI (Regulation (EU) 2026/1744), published in the Official Journal on 24 July 2026 and in force from 27 July 2026, changed several dates. As reported by the Council of the EU and law firm analyses at the time of writing:

Date	What applies
2 February 2025	Prohibited AI practices
2 August 2025	Obligations for general-purpose AI models
2 August 2026	Article 50 transparency obligations (for example, telling people they are interacting with an AI system, and marking synthetic content)
2 December 2026	Article 50(2) marking obligations for systems already on the market before 2 August 2026; new prohibitions added by the Omnibus
2 December 2027	High-risk obligations for stand-alone (Annex III) systems
2 August 2028	High-risk obligations for AI embedded in products regulated under Annex I

Check the Official Journal and your advisers for the current position; implementation guidance and harmonised standards are still being developed.

When is an agent high-risk?

Risk classification depends on the use, not the technology. An agent is likely to fall into the high-risk category if it is used in an Annex III area, such as recruitment and worker management, creditworthiness assessment, access to essential services, or certain uses in critical infrastructure, education, law enforcement and migration. A coding agent or an IT operations agent generally is not. A recruitment screening agent generally is.

High-risk requirements that depend on identity

Risk management (Article 9): identify and mitigate foreseeable risks, including misuse. Agent threat models, least privilege and approval gates are part of this. See the Threat Modelling AI Agents guide.
Record-keeping (Article 12): automatic logging of events over the system's lifetime for traceability. This requires attributable, per-agent logging. See the AI Agent Observability and Incident Response Guide.
Human oversight (Article 14): people able to understand, monitor, override and stop the system. That requires enforced approval gates and a working kill switch.
Accuracy, robustness and cybersecurity (Article 15): resilience against attempts to alter use or behaviour, including by exploiting vulnerabilities. Prompt injection, tool misuse and credential abuse controls apply directly.
Deployer obligations (Article 26): organisations using high-risk systems must use them according to instructions, assign human oversight to competent people, and keep logs under their control.
Serious incident reporting (Article 73): providers must report serious incidents, which depends on detection and investigation capability.

Transparency (Article 50)

Agents that interact directly with people, such as customer service agents, generally must make clear that the person is dealing with an AI system unless that is obvious. Agents that generate synthetic content face marking requirements. These are not identity controls as such, but they depend on knowing where your agents are deployed, which is why inventory comes first.

NIST AI Risk Management Framework

The NIST AI RMF 1.0 is voluntary and organises AI risk management into four functions. Agent identity controls map as follows:

Govern: policies, roles and accountability, including a named owner for every agent and an agentic AI security policy. See the Agentic AI Security Policy Template.
Map: inventory of AI systems, their context, purpose and dependencies, including agents, tools and credentials. See the Shadow AI and AI Agent Discovery Guide.
Measure: testing and monitoring, including red teaming agents for privilege escalation and monitoring agent behaviour.
Manage: prioritising and treating risks, including least privilege, approval gates and incident response.

NIST has also published a Generative AI Profile (NIST AI 600-1) and, in December 2025, a preliminary draft of NIST IR 8596, the Cybersecurity Framework Profile for AI (Cyber AI Profile), which maps AI-specific considerations onto CSF 2.0. The NIST National Cybersecurity Center of Excellence has proposed a project on software and AI agent identity and authorisation. These are guidance, not regulation, but they are increasingly referenced by auditors and customers.

ISO/IEC 42001

ISO/IEC 42001:2023 specifies requirements for an AI management system. It is certifiable, and organisations already certified to ISO/IEC 27001 can integrate the two. Relevant elements include AI risk assessment and treatment, defined roles and responsibilities, controls over the AI system lifecycle, third-party and supplier management, and monitoring and internal audit. Agent registries, owners, lifecycle processes and access reviews supply much of the evidence.

Existing security and data protection rules

Agents are also in scope of rules that do not mention AI:

GDPR: agents processing personal data need a lawful basis, data minimisation and appropriate security (Article 32). Agents making solely automated decisions with legal or similarly significant effects raise Article 22 rights. Personal data breaches caused by agents must be notified within the usual deadlines.
DORA (EU financial services, applying since 17 January 2025): ICT risk management, access control, logging, incident reporting and third-party ICT risk, all of which cover AI agents and AI service providers.
NIS2: cyber risk management measures, including access control and supply chain security, for essential and important entities.
SOX and financial controls: segregation of duties and access reviews apply when agents can change financial data or systems.
PCI DSS v4.0: unique identities, least privilege and logging for any identity, human or not, with access to cardholder data.

Mapping identity controls to frameworks

Control	EU AI Act (high-risk)	NIST AI RMF	ISO/IEC 42001	Security regulation
Agent inventory and registry	Supports Art. 9, 12, 26	Map	AI system inventory and scope	Asset management (DORA, NIS2)
Named owner per agent	Art. 26 oversight assignment	Govern	Roles and responsibilities	Accountability
Unique identity per agent	Art. 12 traceability	Govern, Manage	Lifecycle controls	PCI DSS unique IDs; audit trails
Least privilege, task-scoped access	Art. 15 robustness	Manage	Risk treatment	Access control (DORA, NIS2, SOX)
Human approval for high-impact actions	Art. 14 human oversight	Manage	Human oversight controls	Segregation of duties
Attributable action logging	Art. 12 record-keeping	Measure	Monitoring and measurement	Logging (DORA, PCI DSS, GDPR Art. 32)
Behavioural monitoring and detection	Art. 15; Art. 72 post-market monitoring	Measure	Monitoring	Detection (NIS2, DORA)
Kill switch and revocation	Art. 14 ability to stop	Manage	Operational control	Incident response
Third-party AI and MCP vetting	Value chain obligations	Govern, Map	Supplier relationships	Third-party risk (DORA, NIS2)
Periodic access review	Art. 9 ongoing risk management	Govern	Internal audit	Access reviews (SOX)

Evidence auditors will ask for

A current inventory of AI systems and agents, with owners, purposes and risk classification.
For each agent: its identity, credentials, permissions and the tools and data it can reach.
Access review records showing agent permissions were checked and reduced where needed.
Policies requiring human approval for defined actions, and logs showing approvals happened.
Logs that attribute actions to agents and to the people they acted for.
Incident response procedures covering AI agents, and records of tests.
Third-party assessments for AI vendors, model providers and MCP servers.

Practitioner checklist

Classify each agent under the EU AI Act (prohibited, high-risk, transparency-only or minimal) and record the reasoning.
Build one agent identity control set and map it to the AI Act, NIST AI RMF, ISO/IEC 42001 and your sector rules.
Ensure logging is attributable, retained and protected well enough to support record-keeping and incident reporting.
Implement human oversight as enforced controls, and name the people who exercise it.
Extend access reviews, segregation of duties and third-party risk processes to agents and AI suppliers.
Track regulatory changes; AI Act guidance and standards are still being issued.

Standards and references

This guide summarises regulatory requirements for security practitioners and is not legal advice. Related NHI Mgmt Group resources: Agentic AI Security Policy Template · Agentic AI Identity Maturity Model · Governing the Invisible · IAM and IGA Basics

Agentic AI Compliance Guide: EU AI Act, NIST AI RMF and ISO/IEC 42001