The 2026 breach numbers: AI on both sides

IBM's Cost of a Data Breach study for 2026 covers 602 organizations and breaches that happened between March 2025 and February 2026. The global average cost of a breach was $4.99 million. One in four malicious breaches was AI-enabled, a share IBM says is up 56%, and those breaches cost about $6 million on average.

The other direction gets less attention. More than 20% of organizations reported a breach that targeted their AI models or applications. When IBM looked at the causes of AI-related breaches, two tied at the top with 27% each: compromised APIs, applications or plug-ins, and cloud misconfigurations affecting AI workloads. Neither is an exotic model attack. They are integration and infrastructure failures, the kind every team adding AI features to an existing product is exposed to.

The number that worries us most is the plainest one. Only 37% of breached organizations encrypt sensitive data both at rest and in transit. Companies are wiring LLMs into CRMs, ticketing systems and document stores while the basics underneath are still missing.

Why prompt injection and excessive agency top the risk lists

The 2026 OWASP Top 10 for LLM applications keeps prompt injection at number one for the third year running. Sensitive information disclosure is second. The mover is "excessive agency", which has climbed from eighth to sixth to third. OWASP checked the rankings against a database of roughly 10,000 real AI incidents, so this list reflects what is actually going wrong in production.

Read the top three together and the threat model is short. An attacker gets text in front of your model: an email, a support ticket, a PDF, a web page an agent browses. The model follows it. If the model has tools, it can act. If its context holds personal data, it can leak it.

Nobody can fully solve prompt injection at the model layer today. What you can decide is what the model is able to see and do when it is fooled. In practice:

  • Give each agent the narrowest set of tools its task needs, and split read and write into separate tools so writes can be gated.
  • Require a human confirmation for anything that moves money, sends a message outside the company or changes permissions.
  • Treat every document and page an agent reads as untrusted input, exactly as you treat form fields.
  • Keep raw identifiers out of the context window entirely. More on that below.

The LLM gateway is now a supply-chain risk

In March 2026 a backdoored release of LiteLLM, an open-source LLM gateway used by CrewAI, DSPy and others, sat on PyPI for about three hours. It was downloaded roughly 47,000 times in that window, according to OWASP's State of Agentic AI Security report, as covered by Help Net Security.

We build LLM gateways, so this one landed close to home. A gateway sees every prompt and every response, holds keys for every model provider and usually sits in a privileged spot on the network. Whoever compromises it gets all of that at once. It belongs in the same tier as your identity provider and deserves the same treatment:

  • Pin dependencies by hash rather than version range, and pull them through an internal mirror that holds new releases for a quarantine period before they reach builds.
  • Run the gateway under its own service identity with an egress allow-list, so a compromised build cannot call home.
  • Store provider keys in a secrets manager and rotate them; use short-lived credentials where the provider supports them.
  • Log prompts and responses in a form useful for incident response that does not create a second copy of the personal data you were trying to protect.

Regulation compresses the timeline further. The same OWASP report tracks 42 regulatory instruments across 10 jurisdictions, with incident reporting windows as short as four hours under DORA. A three-hour exposure followed by a four-hour reporting clock leaves no time to work out which services pulled the bad package. You need that dependency inventory before the incident, not during it.

Tokenize before you prompt: privacy-vault architecture

The most effective control we know for personal data in LLM systems is making sure the model never receives it. That is the design behind Logikol, which we built for regulated teams in tax, finance, healthcare and legal who wanted to use AI but could not send client data to external models.

There are three parts. A privacy vault detects PII as it leaves the customer's system and replaces it with tokens. An LLM gateway proxies prompts to whichever provider the team uses (GPT-4o, Claude or a custom model) and scrubs identifiers on the way out. For incoming documents, a document intelligence engine extracts structured data from scanned and handwritten files in a single API call, and every extracted field is tokenized in the same response. Raw values never sit in an intermediate store waiting for a cleanup job.

Some design points matter more than they first appear.

Detection is the hard part. Regular expressions catch IBANs and phone numbers. They miss a name in the middle of a sentence, an address split across lines, or a patient number in an in-house format. Logikol uses transformer-based entity recognition (DeBERTa-v3 and GLiNER) for this reason. Even with good models, plan for per-customer tuning and a review path for low-confidence spans.

Tokens need to be stable within a context. If one client's name becomes one token in the first paragraph and a different token in the third, the model's reasoning about "who did what" falls apart. Consistency inside a request is what keeps answers useful.

The mapping is the crown jewel. The vault holds the link between tokens and real values, so it gets the strongest protection in the system. In Logikol that means AES-256-GCM encryption with keys held in an HSM, and access limited to the service that re-inserts real values for authorized users.

The payoff shows up on the worst day. A breach at the model provider, a leak from gateway logs or a successful prompt-injection exfiltration returns tokens. That is a very different incident to report.

Shadow AI: make the safe path the easy path

Controls on your sanctioned stack mean little if people route around them. In Thomson Reuters' Future of Professionals 2026 survey of 1,816 professionals, 34% said they use AI tools their organization has not approved.

Blocking domains slows this down a little. What works better is an approved route that is at least as convenient as the unapproved one: a gateway-backed assistant with the models people actually want, single sign-on, and PII protection that does not get in their way. Then measure adoption. If the approved tool sees little traffic while shadow use carries on, the tool is the problem, not the staff.

Policy still has to exist somewhere auditable. SecureLabs, the GRC platform we built, generates policies and evaluates uploaded evidence against specific controls across ISO 27001, SOC 2, NIST and GDPR. An AI acceptable-use policy, and the evidence that it is followed, fits naturally into that kind of workspace.

Deployment options: managed, VPC, air-gapped

Where the privacy layer runs matters as much as what it does. Logikol deploys three ways (managed cloud, single-tenant VPC or fully air-gapped) and each answers a different question from a security team.

Managed cloud is the fastest to adopt, and for many teams it is acceptable once PII is tokenized before anything leaves their network. A single-tenant VPC suits organizations whose security team wants the vault and gateway inside their own cloud account, under their own logging and key management. Air-gapped is for cases where no data may leave the premises, tokenized or not, which in practice also means running open-weight models locally.

Start by choosing the deployment model your CISO and DPO can sign off on, then design the rest around it. Doing it the other way round is how AI projects spend a quarter stuck in security review.

For the next few weeks, four concrete tasks:

  1. Inventory every service that calls an LLM and every package that sits between your code and the provider.
  2. Trace where personal data enters prompts, and challenge whether it needs to.
  3. Confirm encryption at rest and in transit for the data stores feeding your AI features. Given IBM's 37% figure, expect to find gaps.
  4. Map your incident-reporting obligations per jurisdiction, with the shortest deadline highlighted.

If you need a privacy layer in front of your models, this is work our AI development team does for regulated clients.

Sources