Five questions your board will ask about AI risk

TL;DR

• A board asking hard questions about AI risk is a board doing its job. The risk is in how you answer.
• Five questions come up again and again, and all five map to three domains: attackers using AI against you, your own people using AI without review, and attacks against your AI systems.
• The failure mode is what our CEO calls solutioneering (jumping straight to an answer before understanding the problem): answering with a purchase before you’ve defined the problem.

Expel almost had a different name. While the paperwork was still moving, the company was called The Concern, largely because people at security conferences would read the badge and stop to ask what it meant. Those conversations turned into the company, and our co-founder and CEO Dave Merkel wrote recently about why questions are the work itself rather than the thing you do before the work starts.

The notion of asking better questions is worth holding onto when your board starts asking about AI, because if you don’t have the answers ready you may find yourself in an uncomfortable conversation.

Evaluating AI risk in your organization isn’t a nice to have anymore, it’s a must. So  a board asking hard questions about AI risk is a board doing its job. What matters is how you answer, and the most common failure is what we call solutioneering: jumping to a fix before you’ve understood the problem or who has it. In a board setting that usually looks like answering a question about exposure by naming a purchase. But before you go to the board with a new budget ask, you need to show your work and have a plan.

Five questions come up again and again. Each one below has what the board is actually asking underneath the question, what a defensible answer looks like, and how not to answer.

Question 1: “How are you monitoring what AI tools employees are using?”

What they’re really asking: Do we know where our data is going?

A defensible answer names your current visibility honestly and describes how you’re closing the gap. “We have identified X sanctioned tools and Y unsanctioned ones through network and single sign-on (SSO) telemetry, and here’s what we’re doing about the second number.” It should also cover any data governance policies you have in place—knowing where your data is going is part of the tool usage flow. 

How not to answer: Treating this as a tool-inventory question, then buying a discovery tool to answer it. That’s solutioneering in miniature. The exposure comes from what people do with the tools, including AI features switched on inside platforms you already approved two years ago, and a clean tool list with no usage policy behind it doesn’t tell the board where the data is going.

Question 2: “How worried should we be about attackers using AI, and how often are we seeing it?”

What they’re really asking: Has the threat changed enough that our controls are behind?

The honest answer is yes, but it’s less dramatic than the headlines suggest. Cybercriminals are using AI mostly to do familiar things faster and at higher volume: better-written phishing, voice cloning for vishing, faster reconnaissance, quicker exploit iteration. A great example of this is the frequency of Microsoft Teams phishing our SOC sees. While this phishing attack isn’t new, attackers are able to scale their output—AKA target more victims, faster, with better personal information—causing this threat to appear more often with less effort from the attacker. 

How not to answer: Only answering one part of the question. Saying “AI has changed everything” is too broad, and saying “nothing has changed” isn’t accurate either. Be able to give specifics and examples of what you’re actually seeing and how you’re remediating. 

Question 3: “Are the AI systems we’re using today vulnerable?”

What they’re really asking: We bought agents that can take actions. What’s the worst case?

This is the question most security teams are least ready for, because the answer depends on permissions nobody in the room granted deliberately. An AI agent with write access to a ticketing system and read access to a customer database has a large blast radius. And this attack vector gets less attention and investment than AI powered threat actors and internal users use of AI systems. 

The useful version of this question adds a second half: how is this attack surface different from what came before? Some of it isn’t. An overpermissioned identity is an old problem wearing new clothes. Some of it is genuinely new, because no traditional control watches for instructions arriving inside a document the model was asked to read.

A defensible answer covers three things: what your agents can actually do, who granted those permissions, and how you’d know if an agent was manipulated into using them (we’re looking at you, prompt poaching and injection). 

Put another way: you should address both monitoring and governance, not just one or the other. To maintain the strongest defense possible against AI threats, you must have guardrails for both in place, because just one leaves at least one part of a defensible response unanswered. 

How not to answer: Don’t conflate monitoring and governance. In order to protect AI tools, you need both guardrails in place, and leaving one unattended leaves a gap for attackers to take advantage of (and they will). 

Question 4: “What do we have in place today to detect AI-related security incidents?”

What they’re really asking: Is this covered by what we already pay for?

Sometimes, partly. Endpoint detection and response (EDR) and security information and event management (SIEM) coverage will catch the traditional half of an AI-enabled attack, because a stolen credential is a stolen credential no matter how convincing the phishing email was. Most stacks weren’t built to see the AI-specific half: agent tool-call behavior, non-human identities acting outside their pattern, or prompt-level manipulation.

A defensible answer says which half you cover today and names the gap plainly. (Spoiler alert: If you’re an Expel customer, we’ve got you covered.)

How not to answer: A confident yes. If you can’t describe the telemetry, you can’t claim the detection, and a board that catches you overstating coverage once will discount everything after it.

Question 5: “What’s our AI security plan, and is it already underway?”

What they’re really asking: Are you ahead of this or reacting to it?

Name a control that’s already running. One live control does more work in this conversation than a full roadmap. This is a new attack surface so they won’t expect you to have ALL of the answers. But what you do need is expertise and a plan that shows where you are headed.

Two things are worth having in your back pocket here. First, whatever detection coverage for AI-related behavior is live in your environment today, described in terms of what it watches. Second, a named framework you’re mapping to, because “we follow a standard” is a weaker sentence than “our AIdetections are mapped against MITRE ATLAS,” and the second one is checkable. 

For Expel customers, MDR for AI runs inside the existing MDR relationship rather than as a separate program to stand up. Our MDR for AI page covers what’s included and what it watches.

How not to answer: Presenting a plan with no owner and no clear roadmap or plan for what’s next. That reads as a deferral, and boards are good at spotting deferrals.

One last thing about how you answer

Merk’s article closes on a line worth borrowing: Expel has “never answered a hard question with ‘just trust us.’

Your board deserves the same. If you can’t describe the telemetry, don’t claim the detection. If the plan doesn’t have an owner, say so. A CISO who names one real gap alongside three real controls gets more credit than one who presents full coverage and gets found out in the follow-up.