AI risk boards are asking the wrong question first

At a glance

What this is: This is Expel’s analysis of why board AI risk questions fail when teams jump to solutions before defining the problem, and why the topic spans three threat domains.

Why it matters: For IAM, NHI, and AI governance teams, the article matters because it ties board-level AI risk to telemetry, control ownership, and the visibility gaps created by human use of AI and AI agents.

Context

AI risk governance is now a board-level topic, but many organisations still answer it as if it were a tooling discussion. The governance gap is not the existence of AI risk questions, it is the tendency to treat them as procurement prompts before establishing what is actually happening in the environment. That matters because the same question can point to employee behaviour, attacker tradecraft, or the permissions granted to AI systems.

In practical terms, the article separates AI risk into three domains: attackers using AI, employees using AI without review, and attacks against AI systems themselves. That split is useful because it shows why generic security posture reporting is not enough. Where AI agents or other non-human systems can act, the identity and access question becomes part of the risk model, not an afterthought.

Key questions

Q: What should boards ask first when assessing AI risk?

A: Boards should ask which AI risk domain they are dealing with before discussing fixes. Separate employee use of AI, attacker use of AI, and attacks on AI systems, then gather evidence for the specific behaviour, owner, and control gap in that domain.

Q: Why do AI risk conversations often go wrong in the boardroom?

A: They go wrong when teams answer with a solution before defining the problem. That creates solutioneering, where the organisation talks about buying a control instead of proving what exposure exists, who owns it, and what telemetry supports the claim.

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: How do teams prove AI-related detection is actually in place?

A: They should show the telemetry, the behaviours being watched, and the framework mapping behind the claim. A credible answer names the specific AI activity covered today and the gap that still remains, rather than implying that existing EDR or SIEM visibility is enough.

Technical breakdown

Why solutioneering is a control failure in AI risk governance

Solutioneering happens when teams answer a risk question with a product or project before they have defined the failure mode. In AI governance, that creates a false sense of coverage because the board hears an answer, but not evidence. The real control problem is often not missing tooling, but missing clarity about which domain is actually in play: attacker use, employee use, or AI system abuse. A board-ready answer has to distinguish those paths, because each one produces different telemetry, different owners, and different response options. Without that split, the organisation can spend money and still leave the underlying exposure untouched.

Practical implication: classify the AI risk question before discussing controls, owners, or budget.

How telemetry changes when employees use sanctioned and unsanctioned AI tools

Employee AI use creates governance risk when data flows into tools that were never reviewed for the purpose they are now serving. That includes sanctioned platforms with hidden AI features and unsanctioned tools discovered through network and SSO telemetry. The technical issue is not just inventory, but usage context, because a clean list of approved tools does not reveal what users actually sent to them. This is where identity and data governance intersect: who used the tool, what account they used, and what data travelled with that session all matter. If the organisation cannot see the usage path, it cannot make a credible claim about control.

Practical implication: correlate SSO, network, and data governance signals to see how AI tools are actually being used.

What makes AI agents a distinct identity and privilege problem

AI agents change the risk model because they can hold permissions, make tool calls, and act within workflows without a human present for each action. That makes them closer to non-human identities than to ordinary software features. The key technical question is not only what the agent can do, but who granted the access, what guardrails limit its scope, and whether its behaviour is observable once it starts operating. A ticketing write path plus database read access may look ordinary on paper, but in combination it creates a much larger blast radius if the agent is manipulated or overpermissioned. Traditional monitoring often misses the identity context of those actions.

Practical implication: treat AI agents as governed non-human identities and review their privilege boundaries explicitly.

NHI Mgmt Group analysis

AI risk governance fails first at the question level, not the control level. Expel’s argument is that boards often receive a tool-shaped answer to a problem-shaped question, and that mismatch obscures the real exposure. The right governance sequence is problem definition, evidence, then control choice. Practitioner conclusion: if the question is not separated into threat, usage, and system risk, the answer will not be auditable.

AI use by employees is an identity and data-flow issue, not just an acceptable-use issue. Once sanctioned platforms and shadow tools both carry sensitive data, the practical control surface becomes user identity, session visibility, and data movement. That makes this a governance problem for IAM and data teams as much as for security operations. Practitioner conclusion: control effectiveness depends on seeing who used what, with which account, and for which data.

AI agents create a distinct non-human identity governance burden. When a software actor can take actions, hold permissions, and use tools independently, the organisation needs a named owner for its authority and limits. That is an NHI problem in the same sense as service accounts and API credentials are NHI problems. Practitioner conclusion: agent permissions should be governed as standing machine access, not as a generic feature flag.

Attackers using AI mostly amplify familiar tradecraft, which means control assumptions age faster than threat narratives. The article is right to resist hype while still treating the trend seriously. Better phishing, faster reconnaissance, and more convincing impersonation all increase pressure on existing detection and response models. Practitioner conclusion: boards should expect incremental adversary gains that still change operating risk.

Named-concept: solutioneering debt. This article exposes the organisational habit of purchasing or proposing controls before defining the precise AI risk condition being addressed. That habit creates governance debt because later evidence, ownership, and accountability all become harder to align. Practitioner conclusion: convert every AI risk question into a documented control gap before asking for remediation.

What this signals

Solutioneering debt: organisations that answer AI risk questions with a purchase instead of a control definition accumulate a governance gap that is hard to unwind later. The practical signal is simple: if the board cannot trace the question to a live telemetry source, the answer is not yet real.

AI agents are pushing security teams toward an access model that looks more like NHI governance than traditional application oversight. That means privilege scope, session observability, and task-specific authority become the decisive controls, especially when agents can write to systems and read sensitive data.

For practitioners

• Define the AI risk domain before selecting a control Separate board questions into attacker use of AI, employee use of AI, and attacks on AI systems so each question maps to evidence, owner, and response path.
• Correlate SSO and network telemetry for AI tool usage Use identity and network signals together to identify sanctioned and unsanctioned AI tools, then document where sensitive data is flowing in those sessions.
• Inventory AI agent permissions as non-human access List what AI agents can read, write, or invoke, and review the access grants that give them those permissions, including ticketing and data systems.
• Map live AI detection coverage to a named framework Show which AI behaviours are currently monitored and align that coverage to a framework such as MITRE ATLAS so the board can verify the claim.

Key takeaways

• The article’s core warning is that AI risk governance fails when organisations jump from board questions to product choices without first defining the problem.
• Its three risk domains are attackers using AI, employees using AI without review, and attacks against AI systems, and each requires different evidence.
• The most useful immediate response is to show live telemetry, named control ownership, and a framework mapping that boards can verify.

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.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• 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.
• Telemetry correlation: The process of joining separate security and application signals into one timeline so analysts can interpret them together. For identity work, this means linking sign-in risk with downstream SaaS activity to decide whether an event is suspicious, confirmed, or benign.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and AI agent identity as part of the industry's only accredited NHI security programme. It helps identity and security practitioners translate access risk into controls they can govern and explain.