AI can be useful without being given the authority to act on every conclusion it reaches.
That distinction is a good place to start when reviewing AI-enabled cybersecurity.
The conversation should go beyond whether a system can identify suspicious activity. It should establish how a finding becomes a decision, how that decision becomes an action and what protects the business throughout that process.
The following five questions can help turn a broad discussion about AI into a practical review of your security environment.
1.What is AI actually doing here?
Ask your security team or provider to follow one example from the original signal to the final action.
Where does AI interpret information? Where does a predefined rule determine what happens? Where does an analyst investigate or approve the response?
Do not settle for a description of the whole system as "AI-powered". You need to understand the responsibilities of its different components.
For example, a generated incident summary might help an analyst work through evidence. A separate response workflow might then disable an account under conditions agreed with the business.
Knowing that distinction helps you ask the right questions about verification, authority and accountability.
A useful question to ask: Can you show us exactly how one finding could result in a change to our environment?
2. What is the system not allowed to do?
Security reviews often focus on capability. Spend equal time on limits.
Consider an AI assistant initially authorised to read internal information. It is later connected to customer records and given permission to make updates. The original approval no longer describes its full responsibility.
For AI agents, least-privilege access means restricting permissions to the task they need to perform and reviewing those grants as their role changes.
Ask who owns those permissions and who can expand them. Establish which actions require independent approval and how access would be withdrawn.
Restrictions should be enforceable through the relevant identity and application controls. A written instruction to "be careful" is not a substitute for an access decision.
A useful question to ask: What stops this system from taking an action outside its approved role?
3. How is the evidence checked?
An assessment is only useful when the people or systems relying on it understand what supports it.
For generative-AI workflows that read external content, this includes recognising that the content itself may be hostile. A document or message can contain instructions intended to influence the model rather than simply provide information. This is one reason the NCSC recommends designing around the possibility of compromised outputs.
That risk is specific to how a system is built and used; it should not be generalised to every form of AI-based detection.
Ask whether an analyst can inspect the underlying events, distinguish observations from generated interpretations and identify missing information before approving a consequential action.
Microsoft's guidance on validating AI output also emphasises checking source material, factual accuracy and context before relying on an output.
A useful question to ask: Can the person responsible for the decision examine the evidence without relying on the AI's summary alone?
4. What happens when the first assessment is wrong?
Work through both directions.
First, imagine legitimate activity being classified as suspicious. What could be restricted? Which business services depend on it? Who would confirm that access can safely be restored?
Then imagine a real threat not being recognised immediately. What limits the account's access? What independent checks protect sensitive actions? What other evidence could bring the activity to the security team's attention?
These questions are not an argument against prevention. They examine what happens when prevention or detection is incomplete.
Cyber-resilience engineering considers how systems withstand and recover from adverse events, rather than assuming those events will always be avoided.
Be realistic about recovery, too. Some operational changes can be reversed. Information already disclosed cannot simply be made undisclosed.
A useful question to ask: Which consequences can we contain, which can we reverse and which must we prevent through stronger restrictions?
5. Who can act when the usual contact is unavailable?
"Someone will approve it" is not a complete response arrangement.
Name the people who can make decisions. Define the situations in which the security team is already authorised to act. Agree how critical systems should be handled and what happens when contacts cannot be reached.
Managed response services make this distinction explicitly. Sophos MDR, for example, offers different arrangements for notifying clients, collaborating on a response and taking authorised action.
The important point is to understand your own arrangement before an incident.
Human involvement should contribute evidence, judgement and accountability. It should not become a ritual approval step or an avoidable delay when action has already been agreed.
A useful question to ask: Would our response team know what it is authorised to do tonight, without having to negotiate the decision from the beginning?
Bring the discussion back to one business process
You do not need to review the entire organisation at once.
Choose one important process: supplier payments, access to customer information or a system needed to fulfil orders.
Bring the relevant business owner and security team together. Follow a suspected compromise through detection, investigation, action and recovery. Record every point at which someone says, "We would need to check that."
Those uncertainties become the starting point for improvement.
At Cyber Insight, we believe confidence in AI-enabled defence should come from understanding both its capabilities and its boundaries.
To discuss how these questions apply to your existing environment, email info@cyberinsight.co.za with the subject "AI defence discussion".
