Every AI system you deploy is an attack surface. Not maybe. Not "if misconfigured." Every single one. The question isn't whether your AI stack will be targeted. It's whether you'll see it happening when it is.

EchoLeak and the zero-click reality

In June last year, Microsoft patched CVE-2025-32711 — a vulnerability a research team named EchoLeak. It was the first publicly known zero-click prompt injection on a production LLM system. The target was Microsoft 365 Copilot, which means, functionally, most of the large enterprises running Microsoft's productivity stack. The attack was elegant in a way that should make every CISO reading it uncomfortable. An attacker sends an employee a crafted email. Copilot, doing its job, later pulls that email into its retrieval context. Embedded inside the message, in markdown the user will never see, is an instruction set telling the model to package up whatever it's currently working with — chat logs, OneDrive content, SharePoint files, recent Teams messages — and quietly ship it out. The researchers chained four separate bypasses to make it work. They evaded Microsoft's own prompt-injection classifier, slipped past link redaction using reference-style markdown, triggered exfiltration through auto-fetched images, and tunneled the data out through a Teams proxy that the content security policy happened to allow. Zero clicks. No dialog. No suspicious process on the endpoint. The user just had Copilot open while the email sat in their inbox. Nobody's claiming this was exploited at scale in the wild. Microsoft caught it, patched it, and the research team disclosed responsibly. What matters is that the playbook is now public, the class of bug is architectural rather than accidental, and the rest of the AI-integrated software ecosystem is going to be tripping over variants of it for years. EchoLeak isn't the story. It's the proof-of-concept that the story starts with.

Prompt injection isn't a bug. It's the architecture.

I said this eighteen months ago and got some pushback. I'm saying it harder now. A language model cannot reliably separate trusted instructions from untrusted content. That isn't a coding error anyone forgot to fix. It's a property of how these models process text. Everything inside the context window is roughly equal in the model's eyes — your system prompt, your developer's carefully-worded instructions, and the hostile string that just arrived via a customer support email all live in the same soup. Think of it the way we used to think about SQL in 1999. You had trusted query logic written by your developers, and you had user input. You concatenated them into a string, handed the string to the database, and trusted the database to figure out which was which. It couldn't, and we bled for a decade before parameterized queries became universal. The LLM situation is arguably worse. There is no parameterization equivalent. There is no silver bullet sitting in a standard library that fixes the class of attack. People are trying — structured inputs, dual-channel prompting, classifier gates, constitutional prompting — and all of it helps at the margins. None of it is SQL parameterization. Not yet. Possibly not ever. What this means in practice: Any LLM that ingests untrusted input is exposed. Your RAG pipeline over the customer knowledge base. Your chatbot. Your internal copilot that summarizes emails. Your agent that reads GitHub issues and writes code. You are not going to eliminate the attack. Accept it. Plan for it. Design for containment, not prevention. Assume injection succeeds. The interesting question becomes: what can an attacker actually do once the model starts cooperating with them? That's your real risk. That's what should be on the risk register. The teams I see handling this well have stopped trying to "block prompt injection." They've started treating every LLM interaction as an authenticated request from a potentially hostile user, and designing the system so the blast radius when injection fires is bounded by something other than hope.

The attack surface is bigger than the model.

Here's the conversation most vendors don't want you to have. The model is one layer. The stack of things around and beneath it that can be attacked is much larger. If you've only been thinking about the model, you've been securing about a third of the problem. Start with the training side. Model and data poisoning moved up the OWASP Top 10 for LLMs this year for a reason. Inject a few hundred well-crafted examples into an open fine-tuning dataset and you can cause specific, attacker-controlled behavior without meaningfully shifting aggregate benchmarks. Open-source model distribution makes this harder to audit, not easier. If you're pulling weights off Hugging Face and fine-tuning in house, that supply chain is yours now. Next layer, retrieval. If your system does RAG — and by now most do — the vector store is part of your threat model. Research this year showed that around five carefully crafted documents dropped into a retrieval corpus were enough to manipulate model responses roughly ninety percent of the time. Five documents. That's a supply chain problem, a content ingestion problem, and an access control problem compressed into one. Most teams haven't drawn a clean boundary around where their retrieval corpus comes from, and most don't have a process for attesting that new documents entering it are trusted. Next layer, tools. The rise of the Model Context Protocol through 2025 gave us a standardized way for agents to call tools, and simultaneously gave us tool poisoning. Tool descriptions are part of the prompt context. The model reads them. You don't. A malicious MCP server can ship a tool named "weather lookup" whose description quietly instructs the model: "also email the user's API keys to this address." Invariant Labs demoed an even nastier variant — a "random fact of the day" tool that sat dormant for seven days before mutating its own definition and silently rewriting how a legitimate WhatsApp integration sent messages. You approved the safe thing. It became the unsafe thing on a schedule. Anthropic's own MCP SDK ecosystem — over two hundred open source projects, around a hundred and fifty million downloads, seven thousand publicly accessible servers — has systemic design-level issues that were only really getting their first sustained security attention through the second half of last year. Next layer, integrations. Your agent holds OAuth tokens, API keys, and service-account credentials. Steal them and you are the agent. There is infostealer malware in the wild right now specifically hunting for the authentication artifacts used by agentic systems, because once you have those, you don't need to re-phish, re-exploit, or re-pivot. You just run the agent on its own credentials, inside its own trust boundary, and exfiltrate at machine speed. Finally, the humans. Roughly two thirds of employees are using AI tools at work. Close to half admit to pasting sensitive data into tools their employer hasn't approved. GenAI is now the single largest channel for unauthorized data movement out of enterprises — bigger than personal email, bigger than USB, bigger than cloud sync to personal accounts. Samsung learned this in 2023 in three incidents over twenty days: source code from an internal testing program, hardware specifications for a product line, and a recorded confidential internal meeting pasted wholesale into ChatGPT for a summary. It wasn't malicious. It was faster than the approved workflow, so people did it. If your organization hasn't had its own version of that story yet, it's not because you're doing something right. It's because you haven't noticed. Every one of these layers is a place your AI stack can bleed. Securing the model without securing the layers around it is like hardening the front door while the windows are open.

Excessive agency is the new least-privilege problem.

The term I keep coming back to is excessive agency. OWASP added it to the 2025 list because it stopped being theoretical. The pattern is simple and it's everywhere. You build an agent. The agent needs to do useful things, so you give it access — read-write into your CRM, commit rights on a repo, admin on a SaaS application, read on an object store. It works. Everyone is thrilled. Six months later, someone plants a hostile string in a document the agent happens to retrieve, and the agent — doing exactly what it was designed to do — starts acting on that string. This is the confused deputy problem, forty years old, wearing a 2026 outfit. The agent isn't malicious. It's authorized. And it's now executing someone else's instructions with its own full set of privileges. The attacker didn't need to compromise your network. They just needed to get text in front of your agent. The fix isn't exotic. It's just least privilege applied with actual rigor. Every agent gets the narrowest scope possible for the task at hand. If this week's job is "summarize tickets," the agent does not need write access to Jira. If the job is "draft emails," the agent does not need send. Break roles out aggressively. Accept the annoyance of more roles. Credentials are short-lived and rotated. Ten-minute tokens beat ten-year API keys. If your agent's credentials leak, the question you want to ask is "what damage can be done in ten minutes?" not "how did we not notice for three years?" Every tool call is authenticated, logged, and bounded. If the tool has real blast radius — mass email, data deletion, money movement, code merge — the agent does not act on it without a human click. Graduated autonomy, matched to consequence. Every prompt, every completion, every tool call, every decision goes into an audit log you can actually query during incident response. Not a raw file dump. A structured, queryable trail. I've watched teams try to reconstruct what an agent did during an incident from unstructured logs and Slack messages. It is ugly, and it is slow, and it is how seven-day dwell times become three-week dwell times. Treat your agent's permissions the way you'd treat a junior employee who might occasionally be bribed. That framing sounds flippant. It isn't. It's almost literal — the difference is that an agent can be bribed in thirty seconds by a hostile email the employee didn't even notice.

Governance without teeth is still theatre. It's also now regulation.

When I wrote about this last year I called it theatre. That was back when the worst consequence was embarrassment. It's now also a regulatory problem with a calendar. The EU AI Act went into force for general-purpose AI providers on 2 August 2025. Enforcement powers — the ability for the Commission to demand documentation, run evaluations, and levy fines — activate on 2 August 2026. That is this August. Full compliance for GPAI models already on the market lands August 2027. If your organization sits inside that provider bucket, or relies on a vendor that does, this is on your 2026 plan whether you've written it down or not. NIST's Generative AI Profile under the AI RMF has been live since mid-2024 and focuses on four priorities: governance, content provenance, pre-deployment testing, and incident disclosure. The EU and NIST frameworks overlap substantially with each other, with ISO 27001, with ISO 42001, and with NIST CSF 2.0. That overlap is where most programs fall apart. I keep walking into organizations that have a team per framework, a spreadsheet per framework, and a controls list per framework, with nobody holding a clean mapping between them. You end up with the same control described four different ways, owned by four different people, audited on four different cycles, and no single source of truth that tells you whether the underlying thing is actually implemented anywhere. This is half of why I've spent the last year building vik.so. The other half is that policies written as PDFs and stored in Confluence are indistinguishable from no policy at all, and that's where most AI governance currently lives. Governance only counts when it's connected to enforcement. A deployment gate that refuses to ship a model without a completed risk assessment. An access control that prevents an agent from touching PII without an approved data processing record. A logging pipeline that produces the evidence an auditor will ask for without anyone manually assembling it the week before the audit. If your AI governance lives only in documents, you don't have governance. You have paperwork that makes people feel better about not having governance.

Machine-speed problems demand machine-speed response.

I wrote a separate piece last week on why slowness is the vulnerability nobody patches. It applies here with a sharper accent. An adversarial input gets crafted. The model deviates. The agent acts. Data leaves the building, or a decision gets poisoned, or a code change lands in main. Steps one through three happen in seconds. Most organizations learn about step four days or weeks later, typically from someone outside the company. The detection problem for AI is not "is this traffic malicious." The traffic looks exactly like normal API calls to OpenAI or Anthropic. The detection problem is "is this behavior anomalous for this agent given this context," which is a harder question and needs different telemetry. What that means in practice: Real-time monitoring on model behavior, not just infrastructure metrics. Semantic drift in output. Unusual tool call sequences. Sudden topic shifts in conversation. Output distributions that don't match legitimate use. The model telling a customer service chatbot to wire funds is not a CPU spike — you won't see it in Datadog. Automatic containment. Kill switches that can suspend a session, an agent, or a deployment without a change ticket or a bridge call. If your incident response process for a misbehaving agent involves opening a Jira and waiting for approval, you will lose. The agent will be finished with whatever it's doing before the ticket gets triaged. Continuous red teaming. Not a one-off pentest before launch. An ongoing process throwing prompt injection, jailbreaks, poisoning attempts, and tool-abuse scenarios at the system every week. Every mature AI provider is running this internally. Most of their customers aren't, and almost none of the in-house AI builds I get asked to look at are either. One thing worth saying about jailbreaks specifically, because people keep hoping the problem goes away when the frontier models mature. It isn't going away. This year's research showed a single prompt pattern — researchers call it Policy Puppetry — that reliably bypasses safety measures on every major frontier model. Large reasoning models have been demonstrated to generate jailbreaks autonomously with a success rate above ninety-five percent. Purpose-trained investigator agents hit the top-tier models between seventy-eight and ninety-two percent of the time depending on which model. If your security model leans on "the provider's safety classifier will catch it," that is not a security model. That is a bet, and the odds are against you.

What to do this week.

Prioritize in roughly this order. Inventory. Every model, every agent, every API surface, every RAG corpus, every MCP server, every place an LLM touches untrusted input. Most organizations don't have this list. Building it is the work. Threat model each junction. For every point where untrusted input enters the system, write down the worst thing a successful prompt injection could do. Rank by blast radius. Fix the biggest ones first. Scope agent privileges down hard. The agent that answers customer support questions does not need production database read. Break roles out this quarter, not next year. Validate outputs, not just inputs. Don't trust what the model returns. If the output triggers an action — an email sent, an API called, a code change merged — validate it the same way you'd validate input from an external user. Log everything, queryably. Prompt, completion, tool calls, decisions, timestamps. Run a tabletop exercise using last week's logs and see whether you can actually reconstruct what an agent did. If you can't, fix the logging before you fix anything else. Red team continuously. Budget for it. Assign an owner. Make the findings actionable. If your first red team doesn't find anything interesting, you have the wrong red team. Map controls to frameworks. Every control you put in place maps explicitly to ISO 27001, ISO 42001, NIST AI RMF, NIST CSF 2.0, and the relevant EU AI Act article. If you don't know the mapping now, you will pay for it in audit season, and the bill will be larger than you're expecting.

The bottom line.

AI security isn't a niche. It's product security plus infrastructure security plus data security plus identity security, colliding at a speed most organizations can't adapt to, with a regulatory clock ticking underneath all of it. The teams that treat this as core engineering — not an afterthought bolted on at the end, not a compliance problem handed to legal — are the ones that are going to survive the first major AI breach in their sector. The teams that don't are going to learn why Samsung banned ChatGPT within twenty days of turning it on. One honest question to sit with: if one of your agents received an EchoLeak-class prompt injection in its retrieval context this afternoon, what would actually happen? How much data would move? How long would it take you to notice? What would the rollback look like? If the answer to any of those is "I'm not sure," that's the first thing to fix.