AI is being built into products, workflows and decisions faster than most organisations are securing it, and the board remains accountable for what those systems do with the organisation's data and authority. AI brings new ways to be attacked, new ways to leak data and new suppliers to trust, on top of the cyber risks boards already oversee. This briefing is for directors, executive teams and CISOs. It covers the main AI security risks in plain terms, why they now belong on the board agenda, the questions to ask, what good oversight looks like, where to invest first, the metrics to request and a 90-day plan. Identity risk from autonomous AI agents is covered separately in our Board and CISO Briefing on agentic AI.
The risk in one paragraph
AI systems, from staff chat assistants to customer-facing chatbots and AI features inside supplier products, take in large amounts of content and act on it. That creates risks traditional controls were not built for. Instructions hidden in an email or web page can redirect an AI system (prompt injection). Confidential data can leave through prompts and answers. Training data and models can be poisoned. A model, plug-in or AI provider can be compromised upstream. And an AI system connected to business tools can take actions nobody intended. None of these can be fixed by asking the model to behave: the protection has to come from what the system is allowed to see and do, how it is tested and how it is watched. Meanwhile attackers are using AI themselves, to work faster and to impersonate executives convincingly.
| Risk | What it means for the business | OWASP LLM Top 10 (2026) | Main control |
|---|---|---|---|
| Prompt injection | Content the AI reads can override its instructions and make it leak data or take actions | LLM01:2026 Prompt Injection | Limit what the AI can access and do; treat all external content as untrusted |
| Data leakage | Confidential, personal or regulated data exposed through prompts, answers or logs | LLM02:2026 Sensitive Information Disclosure | Data classification, access-aware retrieval, approved tools only |
| Excessive agency | AI connected to systems can send, change or delete things beyond its purpose | LLM03:2026 Excessive Agency | Least privilege and human approval for high-impact actions |
| Supply chain | A compromised model, library, plug-in or AI provider becomes a route in | LLM04:2026 Supply Chain | Supplier assessment, approved model and component sources |
| Data and model poisoning | Manipulated training or reference data skews decisions or plants hidden behaviour | LLM05:2026 Data and Model Poisoning | Data provenance, integrity checks, testing before release |
| Runaway use and cost | Abuse or stolen API keys drive large bills or deny service | LLM06:2026 Unbounded Consumption | Rate and spend limits, key protection |
| Shadow AI and AI-enabled attacks | Staff use unapproved tools; attackers use AI for phishing and deepfake fraud | Outside the list | Acceptable use policy, discovery, payment verification |
The IDs above are those of the 2026 edition of the OWASP Top 10 for LLM Applications, as cited by the OWASP GenAI Security Project; the 2025 edition numbered several of them differently. See the OWASP Top 10 for LLM Applications Guide.
Why this is a board-level issue now
- Adoption is mainstream. 20.0% of EU enterprises with 10 or more employees used AI technologies in 2025, up from 13.5% in 2024 (Eurostat, December 2025). Much more AI arrives inside software the organisation already buys.
- The threat is rising. The UK National Cyber Security Centre judges that AI will "almost certainly" make intrusion operations more effective and efficient, "leading to an increase in frequency and intensity of cyber threats", and that AI adoption "almost certainly presents an increased attack surface for adversaries to exploit" (NCSC, May 2025).
- Incidents are already real.
- A zero-click prompt injection could make Microsoft 365 Copilot leak company data (EchoLeak).
- Staff pasting source code into a public AI tool led Samsung to ban such tools (Samsung shadow AI leak).
- A deepfake of a CFO on a video call triggered HK$200 million in transfers at Arup (Arup deepfake fraud).
- Regulation and standards are setting expectations. The table below summarises the main ones. Most organisations are already subject to at least one, directly or through customers.
- Accountability must be named. Joint guidance from the NSA, CISA, FBI and the UK, Australian, Canadian and New Zealand cyber agencies recommends assigning one person accountable for AI system security, aligned with the organisation's cyber security leadership (Deploying AI Systems Securely, April 2024).
| Framework | Status | What it means for the board |
|---|---|---|
| EU AI Act | In force since 1 August 2024; prohibitions and AI literacy from 2 February 2025; transparency rules from 2 August 2026; high-risk rules from 2 December 2027 (Annex III) and 2 August 2028 (Annex I), as amended by the Digital Omnibus on AI (AI Act Service Desk) | Article 15 requires high-risk AI systems to be resilient against data poisoning, model poisoning, adversarial examples and confidentiality attacks (Article 15). The board should know which systems are high-risk. See the EU AI Act Compliance Guide. |
| UK Code of Practice for the Cyber Security of AI | Published 31 January 2025; 13 principles; intended to form the basis of an ETSI standard (GOV.UK) | Principle 4, "Enable human responsibility for AI systems", and Principle 5, "Identify, track and protect your assets", are direct governance asks |
| NIST AI Risk Management Framework | AI RMF 1.0 released 26 January 2023, voluntary, now being revised; Generative AI Profile (NIST AI 600-1) July 2024 (NIST) | Govern, Map, Measure, Manage gives a common structure for AI risk reporting. See the NIST AI RMF Guide. |
| ISO/IEC 42001:2023 | Published 18 December 2023; certifiable AI management system standard (ISO) | A route to demonstrable AI governance for customers and regulators |
| NCSC and partners: Guidelines for secure AI system development | Published 27 November 2023; covers secure design, development, deployment, and operation and maintenance (NCSC) | A baseline to ask internal teams and suppliers to evidence |
Five questions for the board to ask
- Where are we using AI, and who owns each use? The answer should include tools staff use, AI built into our products and AI features inside supplier software, each with a named owner. An inventory is the basis of every other control.
- What data can our AI systems see, and what can they do with it? The size of any AI incident is set by the data and actions the system can reach, not by how clever the model is. Ask which systems can act, not just answer.
- How do we test AI systems before and after they go live? Look for adversarial testing (red teaming) for prompt injection and data leakage, repeated when models, data or connections change.
- Which AI rules apply to us, and who is accountable for meeting them? The answer should name the obligations (for example the EU AI Act's risk categories), the systems in scope and the accountable executive.
- If an AI system were manipulated or leaked data tomorrow, how would we know and how fast could we switch it off? AI systems need logging, monitoring and a tested way to disable them or their connections, inside the existing incident response plan.
What good looks like
| Area | Good practice | Evidence to request |
|---|---|---|
| Governance | An AI policy, an accountable executive and an approval route for new AI uses, aligned to an existing framework such as the NIST AI RMF or ISO/IEC 42001 | Policy, RACI and the approval log |
| Visibility | A maintained inventory of AI systems, models, AI providers and AI features in supplier products, with owners and risk ratings | Inventory coverage; unapproved AI tools found by discovery |
| Data protection | Classified data rules for AI; AI retrieval respects existing permissions; approved enterprise tools that do not train on our data | Data leakage incidents and blocked uploads |
| Secure design | Least privilege for AI connections; human approval for irreversible or financial actions; untrusted content treated as untrusted | Design reviews completed before go-live |
| Testing | Threat modelling and red teaming before release and after significant change | Test reports and fixes closed |
| Supply chain | AI providers, models and plug-ins assessed like other critical suppliers, with contractual security terms | Assessed suppliers as a share of AI suppliers |
| Monitoring and response | Logs of prompts, outputs and actions; alerts for misuse; AI scenarios in incident plans and exercises | Date of last AI incident exercise; time to disable an AI system |
| People | AI literacy and acceptable use training for staff and directors; payment verification that cannot be bypassed by a convincing voice or video | Training completion; exceptions to payment verification |
Risk appetite. State it in testable terms, for example: no AI system processes [restricted] data unless approved by the data owner; no AI system can make payments or delete records without human approval; and every customer-facing AI system is red teamed before launch and at least [annually]. Small organisations can start with an acceptable use policy and a short list of approved tools; larger ones need a formal AI governance process with risk tiers.
Where to invest first
- Inventory and policy: find the AI already in use, including unapproved tools, and publish an acceptable use policy with approved alternatives. See the Shadow AI Discovery Guide and the AI Acceptable Use Policy Template.
- Data protection for AI: stop sensitive data reaching unapproved tools, and make AI search respect existing permissions. See the Generative AI Data Loss Prevention Guide.
- Risk assessment and testing: rate each AI use, then threat model and red team the high-risk ones. See the AI Risk Assessment Guide and the AI Red Teaming Guide.
- Supplier assurance: add AI questions to supplier due diligence and contracts. See the Third-Party AI Risk Guide.
- Governance structure: name the accountable executive, choose a framework and report on it. See the AI Governance Guide.
Metrics to track
- Number of AI systems and AI-enabled supplier services in the inventory, and the percentage with an owner and risk rating.
- Unapproved AI tools detected per month, and the trend after approved alternatives are offered.
- Percentage of high-risk AI systems red teamed in the last 12 months, and open critical findings.
- Number of AI systems able to take actions (not just answer), and the percentage with enforced human approval for high-impact actions.
- AI-related security incidents and near misses, including data leakage events.
- Percentage of AI suppliers assessed, and staff and director AI training completion.
A 90-day plan for the CISO
- Days 1 to 30: build a first AI inventory from procurement, network and identity provider data and business unit surveys; issue interim acceptable use guidance; brief the executive team on findings and the obligations that apply.
- Days 31 to 60: assign owners and risk ratings; agree the AI policy, approval route and accountable executive; put data protection controls on the highest-risk uses; add AI questions to supplier assessments.
- Days 61 to 90: threat model and red team the top three AI systems; add AI scenarios to the incident response plan and run a tabletop; baseline against the AI Security Maturity Model and present the first AI security metrics to the board with a 12-month target.
How NHI Mgmt Group can help
We provide independent AI and identity security maturity assessments, business case development, programme initiation and board briefings. Our NHI Foundation Level Training Course includes an Agentic AI module for security and IAM teams. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Board and CISO Briefing · LLM Security Guide · Prompt Injection Guide · AI Security Posture Management (AI-SPM) Guide · Board Cyber Risk Reporting Guide