IBM’s Breach Report Makes the Case for Object-Level Data Security

IBM’s latest Cost of a Data Breach report puts the average breach cost at a record $4.99 million. According to the report, AI-driven attacks increased 56% year over year, while breaches involving AI systems and models rose 61%.

These figures reinforce what we at Virtru have been saying for a while now: The perimeter is dead.

If AI didn’t kill the perimeter (nail, see coffin) it did expose just how thoroughly the castle walls were already crumbled.

Sensitive data now moves continuously across clouds, SaaS applications, models, agents, partners, and devices. It is copied into prompts, retrieved by AI systems, shared through APIs, transformed into outputs, and distributed across environments no single organization fully controls.

Security architectures built around controlling locations cannot protect data that no longer stays in one place. In an AI-centric world, persistent security policy must be embedded directly into each data object.

AI Is Accelerating a Borderless Data Problem

Much of the AI security conversation focuses on how attackers use AI to discover vulnerabilities, automate reconnaissance, create convincing phishing campaigns, and generate malicious code.

These are all important elements worthy of our concern. However, AI is not just changing the nature of attacks. It is fundamentally changing how enterprise data moves.

Employees introduce sensitive information into AI assistants. Retrieval-augmented generation systems pull data from multiple repositories. Autonomous agents move information between applications and organizations. Models ingest, transform, and reproduce data at machine speed.

There is no coherent perimeter around this ecosystem. And there is no firewall capable of following every sensitive email, document, record, prompt, and dataset wherever it travels.

IBM’s findings around shadow AI illustrate the problem. Organizations cannot govern AI systems they cannot see. But the deeper risk is shadow data: sensitive information moving into environments where its owner can no longer control who accesses it or how it is used.

Discovering an unauthorized application may help close one visibility gap. It does not restore control over data that has already left.

Protection Must Move Beyond Locations and Connections

IBM also found that many breached organizations had failed to encrypt sensitive information at rest and in transit. That is a serious security gap, but simply checking the encryption box is not enough.

Encryption at rest protects a storage location. Encryption in transit, like TLS, protects a connection. Neither inherently protects the data—wherever it travels—after it has been downloaded, copied, shared, or moved into another system.

In a perimeter-centric architecture, gaining access to an application, repository, or account often means gaining access to the data inside it. Infrastructure compromise becomes data compromise.

Data-centric security changes that equation by separating access to a system from authorization to use the sensitive data within it.

Give Every Data Object Its Own Security Policy

The Trusted Data Format, or TDF, makes this model possible by binding persistent encryption and granular access policy directly to the data object.

Instead of depending on a network, cloud, or application to enforce protection, TDF enables security policy to remain with the data wherever it moves. Identity and attributes can be evaluated when access is requested, helping ensure that only authorized users and systems can decrypt the information.

This gives organizations persistent, object-level control:

• Security policy remains with the data wherever it moves.
• Access can be governed by granular identity and policy attributes.
• Authorization can be changed after the data is shared.
• Infrastructure access does not automatically grant data access.
• Policies can be consistently enforced across cloud, AI, and organizational boundaries.

TDF is more than just another form of encryption. It makes security policy intrinsic to the data instead of dependent on the environment containing it.

The Perimeter Can’t Be Resurrected. The Data Must Protect Itself

Organizations cannot reverse data mobility or rebuild a defensible boundary around today’s interconnected ecosystems. Adding more walls around an expanding universe of clouds, applications, AI systems, and devices only perpetuates a security model that no longer reflects how data moves.

Security strategies must assume that data will travel, infrastructure will be shared, and some systems will eventually be compromised. The objective should be to prevent those compromises from automatically exposing every sensitive object within reach.

IBM’s report quantifies the cost of today’s security failures. The architectural lesson is clear: When data moves everywhere, security policy must move with it.

The perimeter is dead. It is time to make persistent security policy a property of the data itself.