IBM’s 2026 Cost of a Data Breach Report (wich was published in July'26) contains a number that caught the Passwork team’s attention: AI-enabled attacks now account for more than one in four malicious breaches, up 56% year over year.
The average cost of those incidents reached $6.04 million, about $1 million above the global average.
At Passwork, we build a self-hosted password and secrets management platform, so we looked at IBM’s findings from a specific engineering perspective: what they mean for software delivery, AI identities, secrets, and access management.
A $6 million average breach does not mean a vulnerable dependency, exposed API, or leaked token in your repository is a "$6 million bug." IBM studied 602 organizations that had already experienced breaches, so its numbers are better treated as directional benchmarks than as a risk calculator for an individual application.
The more useful question for developers is what happens to the time between vulnerability discovery and exploitation as AI capabilities improve.
Research into frontier models suggests that AI can accelerate vulnerability discovery and validation. If attackers can move through that part of the process faster, security teams cannot leave triage and remediation on the same schedule they used a few years ago.
For us, that changes the engineering question from:
How much could a breach cost?
to:
What controls need to become continuous parts of software delivery?
Here are five areas we think are worth reviewing.
1. AI changes the remediation clock
Vulnerability management has always involved a race between discovery and remediation. AI potentially changes the speed of one side of that race.
That makes a quarterly vulnerability review increasingly difficult to justify for internet-facing systems.
The answer is not necessarily to put an AI agent into every CI/CD pipeline. Automation can help with classification, enrichment, or even suggesting a patch, but it does not solve the harder engineering questions: Who owns the vulnerable component? How urgent is the finding? What happens if the fix cannot be deployed immediately? And how do we know the fix actually reached production?
A practical workflow needs to answer those questions before the vulnerability appears.
For internet-facing services, we think that means at least:
- maintaining an inventory with a clear owner for every exposed service;
- creating a separate path for known-exploited and actively exploited vulnerabilities;
- defining remediation SLAs based on exploitability and exposure, not severity alone;
- having compensating controls when an immediate patch is impossible;
- verifying that the fix reached production rather than treating a merged PR as remediation.
The compensating control matters. Sometimes upgrading a dependency immediately is not realistic. But reducing exposure may be: disable the vulnerable feature, add a WAF rule, restrict a network path, introduce a feature flag, or temporarily remove the service from the public surface.
The objective is not "patch everything immediately." It is to make sure a critical finding never enters a backlog with no owner and no next action.
2. The 18% gap: detection is not secure delivery
One of the most interesting findings in IBM’s report is where organizations are actually deploying AI agents.
Among breached organizations, about half reported using AI agents in their SOCs. Their most common uses were threat hunting (56%) and response and containment (54%).
Only 18% used them for vulnerability scanning and management.
That gap matters more to us than the question of whether a team uses AI security tooling at all.
Detection and response happen after something suspicious has occurred. Vulnerability management sits closer to the software delivery process, where engineering teams can remove or reduce exposure before exploitation.
The practical lesson from the 18% figure is not "put an AI agent everywhere." It is to make vulnerability work part of delivery.
For example, we would review four places.
PR and CI. Which security findings actually block a merge, and which simply disappear into the backlog? Define clear CI gate rules that combine severity with exploitability instead of treating every finding the same way.
Dependencies. Which critical direct and transitive dependencies have no clear owner? Assign ownership and maintain an up-to-date SBOM so that a vulnerability can be mapped to the team responsible for fixing it.
External surface. Who owns staging environments, demo instances, and services that were deployed and then forgotten? Connect the asset inventory to owners and use expiry or tagging policies for temporary services.
Remediation. What happens when a patch cannot ship today? Define compensating controls in advance: restrict network exposure, disable the affected feature, introduce a WAF rule or feature flag, or temporarily remove the vulnerable service from the public surface.
AI may make parts of this workflow faster. It can enrich an alert, correlate it with asset exposure, summarize a CVE, or propose a patch.
But ownership, review and safe rollout remain engineering responsibilities.
3. AI security is mostly systems security
IBM also found that more than 20% of organizations reported an incident targeting an AI model or application. Among organizations experiencing AI-related breaches, 92% lacked proper AI access controls.
The obvious reaction is to focus on the model.
We think the more useful place to look is everything around it.
A production AI feature rarely consists of a model call in isolation. It may connect to APIs, vector stores, queues, databases, internal tools, SaaS applications, cloud infrastructure and CI/CD systems.
An agent may also be allowed to perform actions rather than simply generate text.
That turns familiar software architecture decisions into AI security decisions.
When reviewing an AI workflow, we would ask:
- Which tools can the agent call by default?
- Which data sources can it query?
- What data is used for retrieval, generation, evaluation and telemetry?
- Can its account read data unrelated to its current task?
- Can it modify production state?
- Where are credentials for model providers, databases, queues and cloud services stored?
- Are development, staging and production using separate identities?
- Can an action be traced back to a specific user, service or agent?
Prompt injection and model inversion introduce new attack patterns, but many of the controls around them are not new.
API boundaries still matter. Least privilege still matters. Secret handling still matters. Logging still matters. Safe defaults still matter.
In other words:
AI security is largely systems security applied to a new type of application.
4. Treat an AI agent as a production identity
IBM reports that fewer than half of organizations actively secure non-human identities such as API keys, service accounts and machine credentials in their AI workflows.
As agentic systems expand, that becomes difficult to treat as an IAM detail.
An AI agent is not only a model call. In production, it is an identity with tools, data paths, permissions and secrets.
We think it should be managed accordingly.
A basic review can start with five questions:
- Does every agent or service account have an owner and defined purpose? "AI-agent-prod" is not enough documentation if nobody knows which application owns it or why it has access.
- Where do its secrets live? They should not be embedded in source code, prompt templates, configuration copied into chat, or shared documents.
- Are permissions scoped to the task? A workflow that needs read access to one data source should not inherit a credential that can administer the entire environment.
- Can access expire or be revoked? Long-lived credentials with no rotation or lifecycle owner increase blast radius when something goes wrong.
- Are environments separated? An experimental agent running in development should not quietly inherit production credentials because using the same service account was easier.
As AI creates more machine identities, existing weaknesses in secret management and access governance become easier to multiply.
5. Shadow AI is an enablement problem before it becomes an enforcement problem
IBM reports that Shadow AI was associated with 43% of AI-related incidents in its 2026 study, while only about a third of organizations enforced strict approval processes for internal AI tools.
The simplest response is to ban unapproved LLMs. But a clear policy alone doesn’t solve the engineering problem.
If the approved workflow is too slow or too restrictive for actual development work, people will find alternatives. A better starting point is to give teams a secure path that is easy enough to use.
That might include:
- approved models and providers;
- corporate accounts and SSO;
- clear rules for code, logs and customer data;
- secret redaction before prompts are sent;
- a lightweight approval path for new AI tools;
- a test environment for agent experiments.
The data policy should also be concrete.
"Do not send sensitive data to AI" leaves developers to decide what "sensitive" means in the middle of a task.
A more useful policy explicitly covers things such as production database dumps, API tokens, private keys, customer or personal data, credentials and unredacted production logs.
And it should provide alternatives: masked logs, synthetic datasets, least-privilege test environments, approved enterprise workspaces or local/offline workflows where appropriate.
For us, Shadow AI is an enablement problem before it becomes an enforcement problem.
Automation matters when it closes a queue
There is one more IBM result worth putting into engineering context.
Organizations reporting extensive use of security AI and automation had average breach costs $1.93 million lower and breach lifecycles 65 days shorter than organizations using no AI or automation.
That is an association in IBM’s sample, not proof that adding AI automatically produces those savings.
But the mechanism behind useful automation is familiar to engineering teams: reduce the time between a signal and a safe action.
That can be much less glamorous than deploying an autonomous security agent.
It could mean:
- dependency update PRs that automatically run the relevant test suite;
- vulnerability alerts enriched with service ownership and exposure data;
- secret scanning before credentials reach the repository;
- infrastructure-as-code checks in CI;
- deterministic rollback for risky deployments;
- security alerts automatically routed to the team that owns the affected service.
Each removes queue time or manual context switching.
That logic applies even to small engineering teams with no dedicated SOC and no budget for security AI agents.
Three controls to inspect this sprint
IBM’s 2026 report is framed around breach economics. For engineering teams, we think its more useful message is about asymmetric speed.
AI can accelerate vulnerability discovery and attack workflows. At the same time, AI adoption is creating more applications, integrations, service accounts, tokens and machine identities that need to be governed.
Adding another detection tool does not close that gap by itself.
If we had to turn the report into three tickets for the next sprint, they would be:
1. Create a fast path for actively exploited vulnerabilities.
Identify internet-facing assets, assign owners, define escalation rules and document what to do when immediate patching is impossible.
2. Inventory AI-agent identities and secrets.
For each agent or AI-enabled service, record its owner, purpose, permissions, credentials, environment, rotation policy and revocation path.
3. Give developers an approved way to use AI.
Define allowed providers, accounts and data types, plus a practical process for testing or requesting new tools.
None of these controls depends on predicting exactly how capable the next frontier model will be.
They address a simpler problem: when discovery and exploitation get faster, the gap between finding, prioritizing and fixing a weakness becomes more important.
Security controls have to move closer to where software is built and shipped.
Read the full IBM’s 2026 Cost of a Data Breach Report analysis on our blog.
