Why AI identity and access management is becoming a board-level issue for UK firms

AI Trust & Governance

17 April 2026 | By Ashley Marshall

AI access is no longer just an IT permissions problem. Once copilots and agents can search, decide and act, weak identity controls become a board risk in plain sight.

Boards are waking up to a new kind of access risk

For years, identity and access management sat in the background as an infrastructure concern. It mattered, of course, but it was usually discussed in terms of single sign-on, password policy, joiners and leavers, and whether privileged accounts were under control. AI changes the frame. Once a large language model is connected to internal knowledge, CRM data, finance tools, development environments, or customer workflows, identity stops being a back-office topic and becomes a question of who, or what, is allowed to know, decide and act.

That shift is why boards are starting to care. An employee using a generic chatbot is one thing. An AI assistant with access to contract repositories, pricing rules, personal data, source code, procurement workflows or customer accounts is something else entirely. The real risk is not only that a human user has too much access. It is that the AI system may inherit too much access, combine data across contexts, or take actions with a speed and scale that magnify a simple mistake into an enterprise incident.

The UK policy environment has started to reflect this. In March 2026, the UK government’s paper on agentic AI and consumers said that as agents begin to transact, contract and make changes on behalf of users, reliable mechanisms for verifying identity and authority to act become essential. That is a remarkably clear signal. The issue is no longer theoretical. If AI can act on behalf of a user or team, boards need confidence that authority is explicit, bounded and provable.

What this means in practice is simple. Boards can no longer accept vague answers such as, ‘the model is behind our firewall’ or ‘only our staff can use it’. They need to ask which identities exist in the AI estate, how permissions are mapped, what the system can do without approval, and how actions can be traced afterwards. In other words, AI strategy now has an access control agenda attached to it.

The cyber case is getting stronger, and faster

The security argument for tighter AI IAM is now backed by concrete UK evidence. In its May 2025 assessment of the impact of AI on cyber threat to 2027, the NCSC warned that poor identity management and storage increase the risk of credential theft, especially where privileged access is involved or credentials are reused across multiple systems. That matters because AI systems often sit exactly where those conditions are most dangerous, between data, applications and automation layers.

More recently, the picture has sharpened. In April 2026, the NCSC and the AI Security Institute reported that in a 32-step simulated enterprise network attack, the best-performing frontier model completed 22 of 32 steps in its single best run. The estimated cost of a full attempt was around £65. The most important point is not whether today’s public models can finish the whole chain without help. It is that capability is improving quickly while cost is dropping. Attackers do not need perfect autonomy for AI to change the economics of compromise.

That lands directly on identity. If threat actors can automate reconnaissance, accelerate phishing, test configurations, or exploit weakly governed service accounts, then every over-permissioned AI connector and every badly scoped API token becomes more valuable to them. This is one reason the NCSC’s April 2026 guidance stressed familiar defensive basics such as accurate asset inventories, robust access controls, secure configuration and comprehensive logging. AI, in their words, amplifies both strengths and weaknesses.

For boards, this is not just a CISO talking point. It is a resilience question. The organisations that will struggle most are not necessarily those with the boldest AI ambitions. They are the ones deploying copilots, agents and automation on top of messy identity estates they never fully cleaned up. What this means in practice is that AI roll-out should trigger a review of privileged access management, machine identities, API credentials, approval workflows and break-glass procedures. If that review does not happen, the business is effectively scaling access risk under the banner of innovation.

UK governance is moving towards identity, accountability and assurance

Another reason this topic has reached board level is that UK guidance is converging around accountability. The Ministry of Justice’s AI Action Plan for Justice said all agentic AI will operate under strict identity, permission and accountability controls to ensure safe, auditable use. That phrasing is notable because it joins three disciplines that companies often treat separately: IAM, governance and audit. In an AI context, they are inseparable.

The wider government direction points the same way. In January 2026, the government’s AI Opportunities Action Plan update said 38 of the 50 actions had already been met, with AI being scaled across public services and the UK targeting faster AI adoption. Greater adoption means greater pressure for control. As more systems move from experimentation to production, governance cannot rely on informal team norms or vendor promises. It has to be designed into the operating model.

Then there is the regulatory angle. The ICO’s guidance on data protection by design and by default, updated in February 2026, is not AI-specific, but it is highly relevant. It says organisations must protect personal information and ensure only those who need to can access it. It also ties data protection by default to the degree of accessibility. That is exactly the conversation boards should be having about AI systems with retrieval, memory, workflow integration and autonomous actions. If an AI layer broadens access to personal or sensitive data beyond what is necessary, the organisation may have a data governance problem before it has an AI performance problem.

There is a common misconception here that regulation is still too soft or too fragmented to matter. That misses the point. Boards are not waiting for a single AI law that spells out every access rule. They are responding to a cluster of existing duties around data protection, resilience, accountability, assurance and record-keeping. AI IAM has become the control surface where those duties meet. If you cannot show who had authority, what permissions were granted, what data was accessible and what actions were taken, you will struggle to defend your governance under scrutiny.

The rise of agentic AI makes machine identity a board problem

One reason boards sometimes underestimate the issue is that they still picture identity as a human user logging into a system. AI breaks that mental model. Modern deployments create a growing population of non-human identities, service principals, API keys, tokens, agent runtimes, orchestration layers, embedded plugins and automated workflows acting across systems. In practice, a single user-facing assistant may rely on several machine identities behind the scenes, each with different privileges and failure modes.

That matters because machine identity sprawl is hard to see until something breaks. If a sales copilot can read the CRM, pull contract clauses from SharePoint, query a pricing engine, draft a proposal in Microsoft 365 and trigger approval in a workflow platform, where does authority actually live? Is the system acting with the user’s rights, a shared service account, a vendor-managed identity or a privileged backend token? Many firms cannot answer that cleanly. Boards should worry when the architecture diagram looks neat but the permission model is opaque.

This is where named tooling and vendor choices start to matter. Platforms such as Microsoft Entra ID, Okta, CyberArk, SailPoint and Ping Identity already play central roles in enterprise IAM, but AI introduces extra design questions around delegated authority, just-in-time access, approval thresholds, session boundaries and action-level logging. It is no longer enough to say that the user authenticated successfully. Firms need to know whether the agent was allowed to complete a specific action in a specific context, with the right level of human approval.

What this means in practice is that boards should ask for an inventory of AI-related identities, not just AI applications. They should expect to see which agents exist, which tools they can call, which datasets they can reach, which actions require confirmation, how secrets are stored, and how entitlements are reviewed. This sounds technical, but it is the governance core of the problem. If leaders can understand segregation of duties in finance, they can understand segregation of authority in AI workflows.

The counterargument sounds sensible, but it is too narrow

The most common pushback is that this is old wine in new bottles. According to this view, identity and access management has always mattered, so there is no reason to elevate AI IAM to the board. Just apply existing cyber controls and move on. There is some truth in that. Good IAM principles, least privilege, separation of duties, strong authentication, logging and periodic access review, still matter. Boards do not need to invent an entirely new discipline from scratch.

But that argument is too narrow for three reasons. First, AI changes scale. A poorly configured account used by one employee causes one class of risk. An AI system connected to hundreds of users and multiple systems can repeat the same error at machine speed across a much wider surface. Second, AI changes behaviour. Conventional software follows a narrower set of predefined rules, while agentic systems can plan, retrieve, summarise and act across tools in more fluid ways. Third, AI changes visibility. Many business leaders can understand a user role matrix. Far fewer can see how permissions, prompts, memory, connectors and vendor APIs interact inside an AI workflow.

The result is that ordinary IAM debt becomes strategically significant when AI is layered on top. Dormant service accounts, weak approval logic, excessive data access and undocumented exceptions all become harder to tolerate. That is why boards are right to ask harder questions now rather than after a breach, privacy complaint or failed internal audit.

A more useful framing is this: AI IAM is not separate from existing security and governance. It is the point at which those disciplines are stress-tested by a more autonomous technology model. The board’s role is not to micromanage permissions. It is to make sure the company has a control architecture proportionate to the autonomy it is introducing. If management wants faster AI adoption, the board should want clearer accountability, tighter access design and stronger evidence that the business can explain and defend what its AI systems are allowed to do.

What strong board oversight looks like from here

Boards do not need to become identity architects, but they do need a sharper oversight model. A good start is to require management to classify AI systems by autonomy and access. Which systems only generate content? Which can retrieve internal data? Which can trigger workflows, approve actions, change records or contact customers? A board can then ask whether the permission model, monitoring and assurance are proportionate to the level of power each system has been given.

There should also be clear reporting on a handful of practical issues. These include the number of AI systems in production, the number of machine identities supporting them, the use of privileged or shared credentials, the presence of just-in-time access controls, the coverage of approval gates for sensitive actions, and the quality of logging for AI-initiated events. If an organisation cannot report on those basics, it probably does not yet have real control over AI access risk.

Another priority is assurance. The government’s January 2026 call for information on secure AI infrastructure highlighted trusted computing foundations for AI, including secure boot, integrity, identity and attestation across hardware, software, model weights and agent components. Most firms will not build that stack themselves, but the underlying lesson is important. Boards should ask vendors and internal teams alike how they verify approved configurations, protect secrets, manage connectors and detect misuse. Evidence matters more than policy prose.

Finally, boards should connect AI IAM to business priorities rather than treating it as a blocker. Strong identity design supports safer deployment, cleaner audits, better customer trust and more confident scaling. It helps firms say yes to AI use cases they would otherwise avoid. In the UK market, where governance, cyber resilience and trust increasingly shape buying decisions, that is a commercial advantage as much as a control benefit. The firms that treat AI identity and access management as a board issue now will be better placed to innovate without losing grip on accountability later.

Frequently Asked Questions

Is AI identity and access management just another name for normal IAM?

Not quite. It builds on normal IAM, but AI introduces machine identities, delegated authority, multi-system actions and new auditability demands that make access decisions more complex.

Why should the board care if the CISO already owns access controls?

Because AI access failures can create enterprise-wide consequences across cyber risk, privacy, customer trust, operations and regulation. That crosses well beyond a pure security function.

What is the biggest new risk created by AI agents?

It is the combination of autonomy and scope. An agent can potentially read from one system, reason over data from another, and take action in a third, which makes over-permissioning far more dangerous.

Do UK firms need a new law before treating this seriously?

No. Existing duties around UK GDPR, accountability, privacy by design, resilience and auditable governance already create strong reasons to tighten AI access controls now.

Which teams should co-own AI IAM inside a business?

Usually security, IT, data governance, legal, risk and the business owner of the AI use case. AI access design is too cross-functional to sit in one silo.

What should be in an AI access review?

You should review human and machine identities, connector permissions, secrets storage, approval workflows, logging coverage, data scope, privileged roles and exception handling.

Are shared service accounts acceptable for AI tools?

Only in tightly controlled edge cases. In most situations they reduce traceability and increase the chance that an AI action cannot be attributed cleanly to a user, service or approval path.

How often should the board revisit AI IAM?

At least as part of regular cyber and risk reporting, and more frequently when the firm is moving from pilots to production or expanding AI into regulated or sensitive workflows.