When the model is the attack surface: enterprise AI risk in 2026
Prompt-injection attacks on Microsoft 365 Copilot reveal that the AI itself is now an attack surface. Boards need governance frameworks built for models they cannot patch.
The threat is no longer a person tricking a person
When a Microsoft 365 Copilot user opened an email last year, they did nothing wrong. They received an ordinary message, and the AI assistant did exactly what it was designed to do. It read the message, parsed the instructions inside, and acted on them. The corporate data that walked out the door was not exfiltrated by malware or a stolen credential. The user's AI assistant handed it over, politely, in plain text.
That is the security problem 2026 has handed to enterprise risk committees. The threat is no longer a person tricking a person. The threat is an agent that has been socially engineered by an instruction it does not recognize as an attack.
From phishing humans to engineering agents
Most security programs spent the last decade hardening humans against phishing. Training, simulated attacks, awareness scores, all aimed at one question: can we make the user harder to fool? The assumption underneath all of it was that humans were the agents taking action on the company's behalf.
That assumption no longer holds. Every enterprise SaaS deployment now ships with at least one AI assistant that reads, summarizes, and acts on internal documents. Microsoft 365 Copilot, Google Workspace agents, Salesforce Einstein, custom GPTs embedded in knowledge bases. The assistant is the new privileged user. It has access to email, files, calendars, and chat. It can compose, send, and modify. Unlike a human employee, it does not read instructions critically. It treats any text inside its context window as something to comply with.
This is why prompt injection works. It does not exploit a bug. It exploits the design.
Why patching the model is not the answer
The instinct inside IT is to treat this like a software vulnerability and request a patch. That instinct is wrong, and understanding why is the difference between an enterprise that survives this shift and one that does not.
You can patch a buffer overflow. You cannot patch a model that interprets instructions. The whole point of a large language model is that it accepts natural language and acts on it. Adding a filter that strips hostile instructions does not solve the problem; it shifts it. Attackers iterate. Models evolve. The set of safe instructions and unsafe instructions is not a static list; it is a moving boundary defined by the model's training, the prompts it receives, and the tools it has access to.
The honest framing is this: a model you can fully patch is not a model anymore. It is a lookup table. The day you get guaranteed safety from a large language model is the day you also lose the capability that justified buying it.
What governance looks like instead
Boards that take this seriously are moving past the question of how to secure the AI and toward the question of how to constrain what the AI is allowed to do. Three frames are emerging.
Least privilege for agents. A customer-support assistant does not need read access to finance. An email-drafting agent does not need to invoke external APIs. Restrict the tools and data each agent can touch. Treat every agent as if it were a contractor with the worst security hygiene on staff.
Out-of-band confirmation for sensitive actions. If an agent is going to send a wire, send an email to an external domain, or modify a document that contains regulated data, require a human to confirm. The cost of a confirmation step is trivial compared to the cost of a confirmed compromise.
Audit logging that actually answers questions. When an incident happens, you need to know what the agent saw, what it was instructed to do, and which tool calls it issued. If your logs cannot reconstruct an agent's reasoning trail in five minutes, you do not have logs. You have noise.
The framing decision-makers need to make
This is not a tooling decision. It is a governance decision. The companies that get through 2026 intact are the ones whose leadership asked, in early 2025, what their AI assistants could do without a human in the loop, and tightened the answer before the first incident. The companies that get caught are the ones still waiting for a vendor patch.
If your enterprise is rolling out AI assistants faster than your risk committee can review them, the gap between deployment velocity and governance maturity is the attack surface. We work with leadership teams to close that gap before an incident defines the conversation.
What regulators are starting to ask
In the United States, the SEC's 2024 cybersecurity disclosure rules require public companies to describe their board oversight of cyber risk and to disclose material incidents within four business days. The question every audit committee is now wrestling with is whether a successful prompt-injection attack that exfiltrates customer data through an AI assistant counts as a cybersecurity incident under those rules. The same question applies in the EU under DORA for financial services, and in the United Kingdom under the FCA's operational resilience regime. In each case the answer is increasingly yes.
Boards that have not yet asked their general counsel to map their AI assistant inventory against their incident disclosure obligations are running an unrecorded exposure. The first time the answer comes up should not be the day a regulator is already in the inbox.
Book a strategy consultation to review your AI deployment inventory against a current governance framework.