A board asks its CISO for an AI security update, and the answer that comes back is a list of AI-powered detection tools the SOC bought this year. That answer is not wrong. It is just an answer to a different question than the one the board thinks it asked. Using AI to defend the organization and defending the AI the organization now runs are two separate problems, with different attack surfaces, different vendors, and different failure modes, and most enterprises are budgeting, staffing, and reporting on them as if they were one.
This article is grounded in current advisory work, not retrospective analysis. Mark Lynd is a 5x CEO/CIO/CISO with Thinkers360 Top 10 global rankings across Cybersecurity and Artificial Intelligence and was ranked #1 globally in Cybersecurity in 2023. He is currently Head of Executive Advisory and Strategy at Netsync, advising enterprise C-Suites and boards on the AI and cybersecurity questions moving fastest in 2026. The frameworks and patterns referenced here are from active engagements this quarter.
Two Different Sentences That Sound Like One
"We use AI for security" and "we secure our AI" differ by exactly which noun is doing the work and which noun is under attack. In the first sentence, AI is the tool, sitting inside a SOC, triaging alerts, drafting incident summaries, and it can fail the way any tool fails, by being wrong, slow, or misconfigured. In the second sentence, AI is the target, a model with training data that can be poisoned, a system prompt that can be leaked, an agent with tool access that can be manipulated into acting against its own operator. Confuse the two and the budget conversation collapses into a single line item that under-serves both problems.
Where Each Problem Shows Up In Real Systems
Using AI for security looks like Microsoft Security Copilot summarizing an incident timeline, or CrowdStrike's Charlotte AI triaging detections inside a SOC workflow, both shipped and marketed products as of 2026. The AI here behaves like an employee with no judgment beyond its training, doing narrow, repetitive analyst work faster than a human would, and its failure mode is a wrong or hallucinated conclusion feeding into a human decision.
Securing AI looks like EchoLeak, the vulnerability Aim Security disclosed in Microsoft 365 Copilot, tracked as CVE-2025-32711, patched by Microsoft server-side in May 2025 with public disclosure following in June. An attacker needed to send one email. Copilot processed it automatically, followed instructions hidden in the email body, and could be directed to pull internal files and send their contents to an attacker's server, all without the victim clicking anything. No human decision was in the loop to catch it, because the attack targeted the AI system directly, not a person using it.
It also looks like the espionage campaign Anthropic disrupted in November 2025, where a state-sponsored group manipulated Claude Code into running an estimated 80 to 90 percent of an attack against roughly thirty organizations by breaking the operation into tasks that looked defensive. That incident sits in both categories at once. The attackers used AI to attack, and their eventual target was other organizations' infrastructure, but the surface that first had to be tricked was the AI system itself.
The Money Says Which One Gets Attention
Gartner's AI spending forecast for the fourth quarter of 2025 put worldwide spend on AI-amplified security tools, the using-AI-for-security category, at 49 billion dollars for that year. Spend on securing AI systems themselves came to 2.8 billion dollars, about 5.5 percent of the total AI cybersecurity market. That is not a rounding gap. It is a seventeen-to-one preference for the tool over the target, at the exact moment Gartner also projects that 40 percent of enterprise applications will carry task-specific AI agents by the end of 2026. The organizations most exposed on the securing-AI side are the same ones expanding fastest on the using-AI-for-security side, funded at a fraction of the rate.
Gartner's own incident forecast makes the mismatch concrete. The firm expects 25 percent of enterprise generative AI applications to experience at least five minor security incidents a year by 2028, up from 9 percent in 2025, driven largely by immature security practices around Model Context Protocol adoption in agentic systems. Every one of those incidents falls in the securing-AI category, the one receiving roughly 5.5 percent of the spend.
The confusion is not just financial, it is organizational. HiddenLayer's 2026 AI Threat report found that 73 percent of organizations report internal conflict over who owns AI security controls, and separately, that 76 percent now cite shadow AI, meaning AI tools employees adopt without security review, as a definite or probable problem, up from 61 percent the year before. Both numbers describe the same underlying failure. Nobody has clearly assigned ownership of securing AI, because the org chart still routes AI security questions to whichever team already owns AI-powered tooling, and that team's mandate was never to defend the AI itself.
A Worked Scenario
A hospital system's security team reports to its board that AI maturity is strong, pointing to a new AI-assisted phishing detection tool that cut analyst triage time by a documented margin in its first quarter. Three months later, a clinician pastes patient notes into a third-party AI scribe tool that was never reviewed by security, because no one owns AI application review, only AI-in-the-SOC tooling. The scribe tool's vendor suffers a prompt injection incident of its own. The hospital's security dashboard never flags it, because the dashboard was built to show what the security team's AI is catching, not what is happening to AI systems elsewhere in the organization. The board believed it had an accurate picture of AI risk. It had an accurate picture of one AI risk, and no visibility into the other.
The Strongest Objection
The fair objection to drawing this line so sharply is that in practice the two problems increasingly run through the same infrastructure and the same team, so separating them organizationally can create the exact silos this article warns against. A unified AI platform team that owns both the SOC copilot and the guardrails on internally built AI applications may coordinate better than two teams with separate budgets and separate reporting lines, each convinced its half is the whole picture. There is real merit here. Splitting the problem into two owners without a shared risk register just relocates the confusion instead of fixing it.
The distinction this article draws is conceptual, not organizational. Whether one team or two owns the work, the two questions still need separate answers. How well is AI helping us detect threats, and how exposed is our AI to being the threat, cannot be answered by the same metric, the same budget line, or the same board slide, even when the same team is accountable for both.
Questions For Monday
Put these to leadership and the board at the next security review, worded exactly this way if current reporting has been blending the two.
When we report on AI security to the board, how much of that update covers AI as a defensive tool versus AI as something that has to be defended?
Do we know what percentage of our AI security budget goes to each category, and does that ratio look anything like the roughly seventeen-to-one split Gartner found across the industry?
Who reviews a new AI tool or agent for its own attack surface before it goes into production, separate from whoever evaluates whether it is useful?
If a vendor-supplied AI tool we use for security itself gets compromised, does our incident response plan even cover that scenario, or does it assume the AI is always on our side of the fight?
Both problems are real, both are underfunded relative to their risk, and only one of them currently gets a budget line most boards would recognize by name.
