AI risk boards are asking the wrong question first

At a glance

What this is: This article argues that AI risk discussions fail when security teams answer board questions with purchases instead of evidence, controls, and a clear problem definition.

Why it matters: It matters because IAM and security leaders now have to govern AI use, AI-enabled threats, and AI systems themselves without confusing monitoring, policy, and access control.

👉 Read Expel's analysis of board questions on AI risk and solutioneering

Context

AI risk has become a governance problem as much as a security problem. Boards want to know where AI is being used, what attackers are doing with it, and whether internal AI systems have been granted permissions that no one fully reviewed. The first question is no longer whether AI belongs in the agenda, but whether the organisation can answer it with evidence rather than procurement.

The governance gap is often solutioneering, which is the habit of buying a tool before defining the exposure, the control objective, or the owner. That matters for identity programmes because AI tooling increasingly depends on human identities, non-human identities, SSO telemetry, and delegated permissions. When those controls are fragmented, the board gets a confident answer and the programme gets blind spots.

Key questions

Q: What should security teams do first when they cannot answer AI risk questions confidently?

A: Start by separating the problem into attacker use of AI, employee use of AI, and risk inside AI systems themselves. Then identify the live control already in place for each area, the owner of that control, and the telemetry that proves it is working. That prevents solutioneering and gives the board an honest baseline.

Q: Why do AI systems create identity risk as well as model risk?

A: Because AI systems rarely act alone. They depend on service accounts, API tokens, cloud permissions, and data access paths, which means a model can behave safely while its identity layer is over-privileged. Treating AI risk as only a model problem misses the access surface where misuse and lateral movement usually begin.

Q: How can security teams tell whether their controls are coping with AI-orchestrated intrusion?

A: Look for whether monitoring can detect repeated validation attempts, credential reuse, and fast pivoting between systems before data access occurs. If the first reliable signal appears only after lateral movement or exfiltration, the programme is already behind. Controls are coping only when they disrupt the attack during authentication, not after compromise is established.

Q: What does a good board-level AI security answer need to include?

A: A strong answer names the current exposure, the controls already running, the gap being closed, and who owns the next step. It should not sound like a purchase request. Boards respond better to evidence, accountability, and a named framework than to a roadmap with no operational proof.

Technical breakdown

AI risk is really three different control problems

Boards often compress AI risk into a single topic, but the operational reality is three distinct control surfaces. The first is adversaries using AI to scale familiar attack methods such as phishing, vishing, and reconnaissance. The second is employees using approved or unsanctioned AI tools in ways that move data outside policy. The third is AI systems themselves, especially agents that can invoke tools, access databases, or act through delegated identities. These are different threat paths and require different telemetry, ownership, and response models.

Practical implication: Map each AI risk question to a separate control owner so visibility, policy, and runtime governance do not get conflated.

Why AI agents create an identity problem, not just an AI problem

An AI agent becomes a security issue when it is granted permissions that let it act in production systems. At that point, the important question is not only what the model can generate, but what the surrounding identity can do on its behalf. If an agent has read access to data and write access to a ticketing or workflow system, its blast radius is defined by identity scope, not model size. Conventional IAM still applies, but only if teams treat the agent as a governed identity with explicit grants and boundaries.

Practical implication: Review agent permissions the same way you review privileged service accounts, with explicit scope, ownership, and revoke paths.

Telemetry for AI incidents must cover behaviour, not just endpoints

Traditional monitoring tools still matter because stolen credentials and suspicious endpoint activity remain part of AI-enabled attacks. But they do not fully capture AI-specific abuse such as manipulated prompts, agent tool-call anomalies, or sanctioned tools being used in unsanctioned ways. That means detection needs to combine EDR, SIEM, SSO telemetry, and activity logs from the AI system itself. Without that combination, teams can see the supporting compromise but miss the AI-specific decision path that made the incident possible.

Practical implication: Add AI system logs and identity telemetry to existing detection workflows so agent misuse is observable before it becomes an incident.

Threat narrative

Attacker objective: The objective is to use AI to expand access, accelerate abuse, and create risk faster than traditional governance can detect or explain it.

1. Entry begins when attackers use AI to improve phishing, vishing, reconnaissance, or exploit iteration, or when employees introduce unsanctioned AI tools into the environment.
2. Escalation occurs when trusted identities, delegated permissions, or manipulated prompts allow AI systems or users to access more data and tools than intended.
3. Impact follows when AI-enabled access produces data exposure, workflow abuse, or a blind spot in security monitoring that the board had assumed was covered.

NHI Mgmt Group analysis

Solutioneering is the real governance failure in AI risk conversations. Security teams lose credibility when they answer exposure questions with a product category instead of a control state. The board needs to hear what is known, what is unknown, and who owns the gap. That discipline matters in IAM and NHI programmes because AI questions almost always intersect with identity grants, telemetry, and delegated access. The practical conclusion is simple: define the problem before buying the answer.

AI agents should be treated as governed identities, not just applications. Once an agent can read data and invoke tools, its permissions become a security boundary. That makes the identity model central to AI governance, especially where service accounts, workflow credentials, or API tokens let an agent act beyond human review. This aligns with OWASP-NHI thinking and with broader identity lifecycle control. Practitioners should classify agent permissions, ownership, and revocation paths with the same seriousness as privileged human access.

Detection is failing when teams can see the compromise but not the AI-specific action. Endpoint and SIEM coverage may show the first compromise, but they often miss prompt manipulation, tool-call abuse, and unsanctioned AI usage. That is a visibility gap, not just a tooling gap. In framework terms, this points toward NIST CSF detection and response functions, plus MITRE ATLAS for adversarial AI behaviour. The conclusion for practitioners is to instrument the AI layer itself, not just the surrounding infrastructure.

AI governance debt will accumulate where ownership is vague. The article is strongest when it insists that a control only counts if someone can name it, explain it, and defend it in the boardroom. That is especially true for mixed environments where human identity, NHI, and AI tooling intersect. Organisations that wait for a perfect programme will keep answering with roadmap language instead of operational evidence. The real task is to assign owners now and close the highest-risk gaps first.

What this signals

AI governance will keep converging with identity governance as soon as teams operationalise agents with real permissions. The more an AI system can read, write, or invoke tools, the less useful it is to treat it as a standalone governance problem. Practitioners should expect agent identity, delegated access, and telemetry design to sit inside the same operating model as IAM and PAM.

Solutioneering will become a recurring board failure unless teams build evidence-first reporting. A board does not need another product category when it asks about AI risk, it needs a control map, ownership, and proof that the controls are live. That shifts the programme from reaction to governance discipline.

Machine identity and AI risk are now linked by the same access model. When a service account, token, or API key gives an AI workflow permission to act, compromise becomes a matter of scope and dwell time. Our research shows that 72% of organisations have already experienced or suspect an NHI breach, which is why Ultimate Guide to NHIs , Key Challenges and Risks remains relevant to AI governance.

For practitioners

• Separate AI risk into three control workstreams Create distinct workstreams for attacker use of AI, employee AI use, and AI system abuse. Give each a named owner, a telemetry source, and a response path so board reporting reflects actual control coverage rather than one blended risk story.
• Inventory sanctioned and unsanctioned AI tools through identity telemetry Use SSO logs, network telemetry, and application logs to identify which AI tools people are actually using, including AI features embedded in approved platforms. Tie the inventory to data movement policy so the list is linked to exposure, not just adoption.
• Classify AI agents as privileged identities Document every agent that can call tools, read data, or write to systems, then record the identity under which it operates, the permissions it holds, and how quickly those permissions can be revoked when behaviour changes.
• Instrument the AI layer for misuse signals Extend detection to prompt-level manipulation, unexpected tool calls, and changes in agent behaviour. Keep EDR and SIEM in the loop, but add AI-specific telemetry so the control stack can see what the model is doing, not only what the endpoint is doing.
• Name the live control before expanding the roadmap When presenting to leadership, lead with one control already running, such as an AI detection rule set or a mapping to MITRE ATLAS. Then state the next control to be added, which keeps the conversation anchored in evidence rather than aspiration.

Key takeaways

• The article frames AI risk as a governance test, not a procurement exercise, and calls solutioneering the main failure mode.
• The most defensible AI risk answers separate attacker use, employee use, and AI system abuse while grounding each in live telemetry.
• AI agents expand the identity perimeter, so access scope, ownership, and revocation are now core parts of AI governance.

Key terms

• Solutioneering: The habit of answering a security problem with a product or purchase before the problem has been defined. In practice, it creates weak governance because the organisation can point to a control it bought without proving that the control addresses the actual exposure or ownership gap.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Prompt-Level Manipulation: A technique where an attacker or malicious input changes what an AI system decides to do by influencing the text, context, or instructions it processes. It is security-relevant because the abuse may occur without changing the underlying infrastructure, making model and tool behaviour the key detection surface.

What's in the full article

Expel's full article covers the operational detail this post intentionally leaves for the source:

• How the team structures board answers around the three AI risk domains and the five recurring questions
• Examples of how to turn SSO and network telemetry into a defensible view of sanctioned and unsanctioned AI use
• The practical difference between monitoring traditional security events and monitoring AI-specific behaviours such as prompt manipulation
• How Expel frames live AI detections and framework mapping inside an existing MDR relationship

👉 Expel's full article shows how to answer AI risk questions with live controls, telemetry, and framework mapping.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps practitioners connect identity controls to the broader security programme they are already responsible for.