A concentric faceted lens with thin data lines radiating out to a ring of squares

2026 AI Security Briefing

AI security stopped being a research topic and became an operations problem. In 2026 the reports stopped describing hypothetical model attacks and started counting the breaches: AI-assisted intrusions, agents with real permissions, and employees quietly sending work product to whatever chatbot was fastest that morning. This briefing collects what changed, with sources, and separates the risks that matter from the ones that make good conference slides.

What Changed in 2026

Four shifts, each supported by data published this year.

AI-driven attacks became a measurable share of breaches. IBM’s 2026 Cost of a Data Breach report found that one in four malicious breaches involved AI, a 56% increase over the prior year, and that those breaches cost an average of $6 million, roughly $1 million above the global average of $4.99 million (IBM, July 2026). Most of that is deepfake impersonation and AI-assisted malware, not novel model exploits.

Vulnerability exploitation overtook credentials as the way in. The 2026 Verizon DBIR reports exploitation of vulnerabilities as the most common initial access vector at 31% of breaches, with credential abuse down to 13%. Ransomware rose to 48% of breaches, the highest in the report’s history.

Defenders are behind on the basics. Only 26% of CISA Known Exploited Vulnerabilities were fully remediated in 2025, down from 38% the year before, and median time to full resolution rose to 43 days from 32.

Shadow AI became ordinary. 67% of users access AI services through non-corporate accounts on corporate devices, 45% of employees are regular AI users (up from 15%), and shadow AI is now the third most common non-malicious insider action in the DBIR’s DLP dataset, a fourfold increase year over year.

The Attack Surface Around AI

An AI deployment adds surface in five places, and only one of them is the model itself.

  • The application around it. IBM’s data shows that more than 20% of organizations reported a breach targeting AI models or applications, and the most common causes were weaknesses in the surrounding systems: compromised APIs, applications, or plug-ins at 27%, and cloud misconfigurations affecting AI workloads at 27%. The failure was rarely in the model weights.
  • The data path. Everything the model reads. Retrieval systems, document stores, email, and shared drives become inputs to a system that answers questions about them, which makes an old permission mistake newly exploitable.
  • The tools and permissions. Agents that can send mail, move files, or call APIs turn a language error into an action error.
  • The people. Employees using unapproved tools, pasting source code and client data into consumer accounts.
  • The vendors. Third-party involvement reached 48% of breaches, up 60% year over year, and AI features arrive through vendors far more often than they are built in-house.

Shadow AI Is Now Mainstream

The DBIR’s DLP data is the clearest picture available of what employees actually do. The most common data type submitted to external GenAI models was source code, followed by images and structured data. In 3.2% of DLP policy violations, research and technical documentation were being uploaded to unauthorized AI systems.

Two conclusions follow. First, blocking tools without providing a sanctioned alternative does not reduce the exposure; it reduces visibility. Second, the highest-risk data is not the data people worry about most. Source code and technical documents are pasted because explaining a problem to a model requires pasting the problem.

The controls that work are unglamorous: an approved-tool list with an enterprise tenant that contractually excludes training on your data, a one-page policy naming prohibited data, a request process that answers in days rather than months, and role-specific training that uses real examples from your own workflow. The detail is in shadow AI.

Agents and Tool Access

An agent is a model with credentials and a goal. The security question is not what the model knows but what it can do. When an assistant can read email, write files, and call internal APIs, a prompt injection in a document it reads becomes a permission problem in your environment.

Practical controls, in order of value: least privilege on every tool, allowlists rather than blocklists, human approval for anything that sends, pays, deletes, or changes access, scoped credentials that expire, and logging of every tool call so a chain of actions can be reconstructed. If an agent needs standing write access to a system, that is a design decision to make explicitly and not by default.

Indirect prompt injection is the mechanism to understand; it is covered in prompt injection. The OWASP Top 10 for LLM Applications (2025) lists prompt injection as LLM01, the top of that list, and it has stayed there across revisions for a reason: the model cannot distinguish instructions from data.

Model and Data Risk

Two risks that are usually discussed badly.

Model inversion and training-data leakage. An attacker probes a deployed model to reconstruct sensitive data it was trained on. IBM reports an average cost of about $6 million per model inversion breach, roughly 18% above the global average. This matters when a model is trained or fine-tuned on client data. It does not matter much when you are calling a vendor’s general model through an API with no fine-tuning, which describes most business deployments.

Poisoning and drift. If your retrieval corpus or fine-tuning set is writable by people who should not shape model behavior, the model’s answers become an attack surface. Controls: restrict write access to the corpus, review documents that enter it, and keep an evaluation set that catches a change in behavior after a model update.

NIST’s AI Risk Management Framework organizes this work into four functions: govern, map, measure, and manage. It is the most useful structure available for a program that has to be explained to a board: assign ownership, map the context and the risks, measure them with tests, and manage them with controls and monitoring.

What Controls Actually Work

Ranked by what we see reduce exposure fastest in real environments:

  1. Inventory and approve tools. You cannot govern traffic you cannot see. Start with SSO logs, egress logs, and expense reports.
  2. Classify data before it reaches a model. Name what may never be pasted, and make the sanctioned tool good enough that people use it.
  3. Least privilege for agents. Narrow permissions, scoped credentials, no ambient admin access.
  4. Human approval for consequential actions. A click is cheaper than an incident.
  5. Log prompts, retrieved documents, and tool calls for sensitive workflows, with a retention period you can defend.
  6. Test guardrails with a fixed evaluation set before each release, and again after any model change.
  7. Vendor terms in writing: training, retention, deletion, subprocessors, and breach notification.
  8. Train staff on the specific scenarios that leak data in their role. Our cybersecurity training is delivered per role, remotely or on site.
  9. Include AI systems in the incident response plan. Who disables the agent, who rotates its credentials, who reads its logs.

The compensating finding in IBM’s data is worth stating: organizations using AI and automation extensively in their security operations cut breach costs by an average of almost $2 million. The same technology that widens the attack surface, used defensively, pays for itself.

A 90-Day Plan

WindowWorkEvidence it happened
Days 1–14Inventory AI usage through SSO, egress, and expenses. Publish a one-page acceptable-use policy with a named owner.Usage inventory, signed policy, owner named
Days 15–45Classify data. Approve tools with contract terms reviewed. Train staff on role-specific scenarios. Provide an enterprise tenant or a local option.Data classification, approved-tool list, training records, vendor terms on file
Days 46–90Test one high-risk AI workflow: injection attempts, data leakage, permission boundaries. Add logging and human approval. Run an independent assessment for anything customer-facing.Evaluation results, tool-call logs, approval workflow, assessment report

If you have not started, the AI readiness check takes four minutes and tells you which of these three windows you are in. The practical guide is AI for business; the assessment service is AI security assessments.

Sources

  • Verizon, 2026 Data Breach Investigations Report, Executive Summary — verizon.com (PDF). Accessed 1 November 2026.
  • IBM, Cost of a Data Breach Report 2026 and the accompanying release — IBM Newsroom, 29 July 2026. Accessed 1 November 2026.
  • OWASP, Top 10 for LLM Applications 2025 — genai.owasp.org. Accessed 1 November 2026.
  • NIST, AI Risk Management Framework — nist.gov. Accessed 1 November 2026.
  • FBI Internet Crime Complaint Center, 2025 Internet Crime Report — ic3.gov (PDF). Accessed 1 November 2026.

Schedule an AI security assessment or call 703-486-0200.

Frequently Asked Questions

Are AI-driven attacks a new kind of attack?+

Mostly no. They reuse credential abuse, social engineering, and data exposure at greater speed and scale. Deepfake impersonation and AI-assisted malware are the visible new part.

Do we need to test our AI application?+

If it reads untrusted content or can act on your systems, yes. Test prompt injection, data leakage, and permission boundaries before it faces customers.

Is a local model more secure?+

It removes the vendor data path, not the application risk. Prompt injection and permission problems remain, which is why the controls sit around the model.

Posted in AI, cybersecurity.