Patchwork AI Security vs. Purpose-Built Protection: Thoughts on Cyera’s Ryft Acquisition

Walk into any advanced manufacturing, aerospace, defense, or industrial design shop and you’re just as likely to see Solidworks as you are AutoCAD. The models, assemblies, and drawings built in Solidworks are the digital blueprints for everything from turbine blades and medical devices to satellites and weapons systems.

‍

Earlier this year we announced native support for AutoCAD DWG files, making an entire class of previously opaque CAD data visible to security and compliance teams for the first time. Now we’re extending that same deep visibility to Solidworks 3D CAD files, so you can protect the IP and regulated technical data hiding inside your .sldprt, .sldasm, and related content—without slowing engineering down.

‍

And as AI accelerates design cycles, that visibility is no longer optional.

‍

AI is Supercharging Design – and Expanding the Blast Radius

Design teams are pushing faster than ever:

‍

• Generative design tools propose entire families of parts and assemblies.
• Copilots summarize requirements, suggest changes, and draft documentation off CAD models.
• PLM-integrated agents automatically create downstream artifacts—quotes, NC programs, service manuals—based on 3D designs.
• RAG-style internal assistants answer questions using a mix of project docs, CAD files, and simulation outputs.

‍

All of this is powerful. It also multiplies the ways sensitive CAD data can leak:

‍

• Entire assemblies uploaded to unmanaged AI tools “just to explore options.”
• Export-controlled models referenced in prompts and ending up in long‑lived AI data lakes.
• Supplier and customer CAD shared into external copilots with little visibility into who—or what agent—can access it.
• Rich metadata from CAD (usernames, project codes, server paths, partner names) silently turned into reconnaissance material.

‍

If you don’t understand what’s inside your CAD, where it lives, and which identities and AI agents can reach it, AI doesn’t just speed up design—it speeds up IP disclosure, compliance failures, and supply‑chain exposure.

‍

CAD Has Been a Blind Spot for Security

Most traditional DSPM and DLP tools still treat specialized engineering formats as a big binary blob: “probably sensitive, treat with caution.” That may have been acceptable when CAD lived on a handful of on‑prem engineering servers.

‍

It’s not acceptable when:

‍

• Decades of CAD history have been lifted and shifted into S3, Azure Blob, or SharePoint.
• ITAR/EAR “technical data” now lives side‑by‑side with everyday project files in cloud object stores.
• Those same repositories feed downstream systems—PLM, MES, AI assistants—where traditional security tools have little or no visibility.

‍

We built native DWG parsing into Sentra to break that stalemate, making CAD content as transparent to security teams as a Word document. Solidworks 3D CAD support is the next logical step.

‍

What’s Really Inside a Solidworks 3D CAD File?

Like DWG, a Solidworks file is far more than geometry. It’s a container for rich metadata, text, and structural context that describes both what you’re building and how it fits into regulated programs and commercial IP. Our Solidworks support is designed to surface that security‑relevant context—without requiring CAD tools, manual exports, or data movement.

‍

Similar to what we do for DWG, Sentra can extract and analyze key elements, including:

‍

• Document properties
  Authors, “last saved by,” creation and modification timestamps, total editing time, and revision counters—signals that help you understand who is touching sensitive designs and when.

‍

• Custom properties and configuration metadata
  Project IDs, part and assembly numbers, revision codes, program names, business units, and export‑control or classification markings encoded as custom properties or notes.

‍

• Text content and annotations
  Notes, callouts, PMI, and embedded text that often contain material specifications, tolerances, customer names, contract IDs, and phrases like “COMPANY CONFIDENTIAL,” “EXPORT CONTROLLED,” or ITAR statements.

‍

• Assembly structure and component names
  Which parts roll up into which assemblies, and how those components are named—critical when you need to understand which physical systems a given sensitive model belongs to.

‍

• File dependencies and paths
  References to drawings, configurations, libraries, and external resources that routinely expose server names, share paths, usernames, and department structures—goldmine context for attackers, but also for incident response and insider‑risk investigations.

‍

For organizations operating under ITAR and EAR, this is where truly export‑controlled technical data actually lives—not in the folder name, but in the title blocks, annotations, and metadata attached to models and drawings.

‍

Turning Solidworks Models into Actionable Security Signals

By parsing Solidworks 3D CAD files in place, inside your own cloud accounts or VPCs, Sentra can now treat them as first‑class citizens in your data security program—just like we do for DWG and other specialized formats.

‍

That unlocks concrete use cases, such as:

‍

• Finding export‑controlled or highly sensitive designs in cloud storage
  Automatically surface Solidworks files whose metadata, annotations, or custom properties contain ITAR statements, ECCN codes, proprietary markings, or customer‑confidential labels—so you can focus remediation on the drawings and models that are actually regulated.

‍

• Mapping who (and what) can access critical designs
  Combine CAD‑aware classification with Sentra’s DSPM and DAG capabilities to answer:
  Where are our most sensitive Solidworks assemblies stored, and which identities, service principals, and AI agents can currently reach them?

‍

• Monitoring AI and collaboration workflows for IP exposure
  Track when Solidworks files that contain regulated or high‑value IP are moved into AI data lakes, shared via collaboration platforms, or accessed by non‑human identities—so DDR policies can flag, quarantine, or route for review before they turn into public incidents.

‍

• Building a defensible audit trail for CAD‑resident technical data
  Maintain an inventory of Solidworks files that contain export‑control markings or IP‑critical content, tie each file to its exact storage location and access controls, and surface any out‑of‑policy placements—so when auditors ask “Where is your technical data?”, you can answer with data, not slideware.

‍

Closing the Gap Between “Stored” and “Understood” for 3D CAD

As workloads like EDA, PLM, simulation, and AI‑assisted design move deeper into the cloud, the number of specialized formats in your environment explodes. Most tools still only truly understand emails, office documents, and a narrow slice of structured data.

‍

The reality is simple: you cannot secure data you don’t understand. Understanding means being able to answer, at scale, not just “Where is this file?” but “What is inside this file, how sensitive is it, and how is AI amplifying its risk?”

‍

For organizations whose crown‑jewel IP and export‑controlled technical data live in Solidworks 3D CAD, that’s the gap Sentra is now closing.

‍

If you want to see what’s actually hiding inside your own Solidworks models and assemblies, the easiest next step is to run a focused assessment: pick a few representative buckets or repositories, let Sentra scan those CAD files in place, and review the inventory of regulated and high‑value designs that surfaces.

‍

Chances are, once you’ve seen that map—and how it connects to your AI initiatives—you’ll never look at “just another CAD file” the same way again.

‍

Fiverr’s recent data breach/data exposure left tax forms, IDs, contracts, and even credentials publicly accessible and indexed by Google via misconfigured Cloudinary URLs.

‍

This post explains what happened, why data sprawl across third-party services made it inevitable, and how to prevent the next Fiverr-style leak.

The Fiverr data breach is a textbook case of sensitive data sprawl and misconfigured third‑party infrastructure: highly sensitive documents (including tax returns, IDs, health records, and even admin credentials) were stored on Cloudinary behind unauthenticated, non‑expiring URLs, then surfaced via public HTML so Google could index them—remaining accessible for weeks after initial disclosure and hours after public reporting. This isn’t a zero‑day exploit; it’s a failure to understand where regulated data lives, how it rapidly proliferates and is shared across services, and whether controls like signed URLs, authentication, and proper indexing rules are actually in place.

In practical terms, what happened in the Fiverr data breach?

‍

– Sensitive documents (tax returns, IDs, contracts, even credentials) were stored on Cloudinary behind unauthenticated, non-expiring URLs.

– Some of those URLs were linked from public HTML, allowing Google and other search engines to index them.

– As a result, private Fiverr user data became publicly searchable, long before regulators or affected users were notified.

‍

What the Fiverr Data Breach Reveals About Third-Party Data Sprawl‍

What makes this kind of data exposure - like the Fiverr data leak - so damaging is that it collapses the boundary between “internal work product” and “public web content.” The same files that power everyday workflows—tax filings, medical notes, penetration test reports, admin credentials—suddenly become discoverable to anyone with a search engine, long before regulators or affected users even know there’s a problem. As enterprises lean on third‑party processors, media platforms, and SaaS for collaboration, the real risk isn’t a single misconfigured bucket; it’s the absence of continuous visibility into where sensitive data actually resides and who—human or machine—can reach it.

‍

Sentra is built to restore that visibility and hygiene baseline across the entire data estate, including cloud storage, SaaS platforms, AI data lakes, and media services like the one at the center of this incident. By running discovery and classification in‑environment—without copying customer data out—Sentra builds a live inventory of sensitive assets, from tax forms and IDs to health and financial records, even in unstructured PDFs and images brought into scope via OCR and transcription. On top of that, Sentra continuously identifies redundant, obsolete, and toxic (ROT) data, so organizations can eliminate unnecessary copies that amplify the blast radius when something does go wrong, and set enforceable policies like “no GLBA‑covered data on unauthenticated public endpoints” before the next Cloudinary‑style exposure ever materializes.

If you’re asking “How do we avoid a Fiverr-style data breach on our own SaaS and media stack?”, the starting point is continuous visibility into where sensitive data lives, how it moves into services like Cloudinary, and who or what (including AI agents) can access it.

‍

How to Prevent a Fiverr-Style Data Leak Across SaaS, Storage, and Media Services

Where traditional controls stop at the perimeter, Sentra ties data to identities and access paths, including AI agents, copilots, and service principals. Lineage‑driven maps show how data moves—from a storage bucket into a search index, from a document library into a media processor—so entitlements can follow data automatically and public or over‑privileged links can be revoked in a targeted way, rather than taking an entire service offline. On that foundation, Sentra orchestrates automated actions and remediation: quarantining exposed files, tombstoning toxic copies, removing public links, and routing rich, contextual tickets to owners when human judgment is required—all through existing tools like DLP, IAM, ServiceNow, Jira, Slack, and SOAR instead of standing up a parallel enforcement stack.

‍

Doing this at “Fiverr scale” requires more than point tools; it demands a platform that is accurate, scalable, and cost‑efficient enough to run continuously and scale across multi-hundred petabyte environments. Sentra’s in‑environment architecture and small‑model approach have already scanned 8–9 petabytes in under 4–5 days at 95–98% accuracy—an order‑of‑magnitude faster and cheaper than extraction‑based alternatives—while keeping customer data inside their own accounts. That efficiency means enterprises can maintain continuous scanning, labeling, and remediation across hundreds of petabytes and multiple clouds without turning governance into a budget‑breaking project, and can generate audit‑grade evidence that sensitive data was governed properly over time—not just at the last assessment.

‍

Incidents like the Fiverr data breach are a warning shot for the AI era, where copilots, internal agents, and search experiences will happily surface whatever the underlying permissions and data quality allow. As AI adoption accelerates, the only sustainable defense is a baseline of automated, continuous data protection: accurate classification, durable hygiene, identity‑aware access, automated remediation, and economically viable, always‑on governance that keeps pace with rapidly expanding and evolving data estates. You can’t secure AI—or avoid the next “public and searchable” headline—without first understanding and continuously governing the data that AI and its surrounding services can see. As AI pushes boundaries (and challenges security teams!), there is no time like now to ensure data remains protected.

‍
Fiverr data breach FAQ

• Was my Fiverr data exposed in the breach?
  Fiverr and independent researchers have confirmed that some user documents—including tax forms, IDs, invoices, and credentials—were publicly accessible and indexed by Google via misconfigured Cloudinary URLs. Whether your specific files were exposed depends on what you shared and how Fiverr stored it, but the safest assumption is that any sensitive document shared on the platform may have been at risk.
  
  
• What made the Fiverr data breach possible?
  The root cause wasn’t a zero-day exploit; it was data sprawl across third-party infrastructure plus weak controls: public, non-expiring Cloudinary URLs, public HTML linking to those URLs, and no continuous visibility into where regulated data lived or who could reach it.
  
  
• How can enterprises prevent similar leaks?
  By continuously discovering and classifying sensitive data across cloud storage, SaaS, and media services; cleaning up ROT; enforcing policies like “no GLBA-covered data on unauthenticated public endpoints”; and tying access to identities so public links and over-privileged routes can be revoked automatically. 

‍

Read more about the Fiverr Data Breach

Detailed news coverage of the Fiverr data breach and Cloudinary misconfiguration (Cybernews)

Independent analysis of the Fiverr data exposure via public Cloudinary URLs (CyberInsider)

‍

One of the most interesting blind spots I see in mature security programs isn’t a database or a SaaS app. It’s web archives.

If you’re in financial services, you may be required to archive every version of your public website for years. Legal teams preserve web content under hold. Marketing and product teams crawl competitors for competitive intel. Security teams capture phishing pages and breach sites for analysis. All of that activity produces WARC and ARC files - standard formats for storing captured web content.

‍

Now ask yourself: what’s in those archives?

Where Web Archives Come From and Why They Get Ignored

In most enterprises, web archives are created in predictable ways, but rarely treated as data stores that need to be actively managed. Compliance teams crawl and preserve marketing pages, disclosures, and rate sheets to meet record-keeping requirements. Legal teams snapshot websites for e-discovery and retain those captures for years. Product and growth teams scrape competitor sites, pricing pages, and documentation, while security teams collect phishing kits, fake login pages, and breach sites for analysis.

‍

All of this content ends up stored as WARC or ARC files in object storage or file shares. Once the initial crawl is complete and the compliance requirement is satisfied, these archives are typically dumped into an S3 bucket or on-prem share, referenced in a ticket or spreadsheet, and then quietly forgotten.

‍

That’s where the risk begins. What started as a compliance or research activity turns into a growing, unmonitored data store - one that may contain sensitive and regulated information, but sits outside the scope of most security and privacy programs.

What’s Really Inside a WARC or ARC File?

A single WARC from a routine compliance crawl of your own site can contain thousands of pages. Many of those pages will have:

‍

• Customer names and emails
• Account IDs and usernames
• Phone numbers and mailing addresses
• Perhaps even partial transaction details in page content, forms, or query strings

If you’re scraping external sites, those files can hold third‑party PII: profiles, contact details, and public record data. Threat intel archives may include:

‍

• Captured credentials from phishing kits
• Breach data and exposed account information
• Screenshots or HTML copies of login pages and portals

Meanwhile, the archives themselves grow quietly in S3 buckets and on‑prem file shares, rarely revisited and almost never scanned with the same rigor you apply to “primary” systems.

‍

From a privacy perspective, this is a real problem. Under GDPR and similar laws, individuals have the right to request access to and deletion of their personal data. If that data lives inside a 3‑year‑old WARC file you can’t even parse, you have no practical way or scalable way to honor that request. Multiply that across years of compliance archiving, legal holds, scraping campaigns, and threat intel crawls, and you’re sitting on terabytes of unmanaged web content containing PII and regulated data.

Why Traditional DLP and Discovery Can’t Handle WARC and ARC

Most traditional DLP (Data Loss Prevention) and data discovery tools were designed for a simpler data landscape, focused on emails, attachments, PDFs, Office documents, and flat text logs or CSV files. When these tools encounter formats like WARC or ARC files, they typically treat them as opaque blobs of data, relying on basic text extraction and regex-based pattern matching to identify sensitive information.

‍

This approach breaks down with web archives. WARC and ARC files are complex container formats that store full HTTP interactions, including requests, responses, headers, and payloads. A single web archive can contain thousands of captured pages and resources: HTML, JavaScript, CSS, JSON APIs, images, and PDFs, often compressed or encoded in ways that require reconstructing the original HTTP responses to interpret correctly.

‍

As a result, legacy DLP tools cannot reliably parse or analyze WARC and ARC files. Instead, they surface only fragmented data such as headers, binary content, or partial HTML, without reconstructing the full user-visible context. This means they miss critical elements like complete web pages, DOM structures, form inputs, query strings, request bodies, and embedded assets where sensitive data such as PII, credentials, or financial information may exist.

‍

The result is a significant compliance and security gap. Web archives stored in WARC and ARC formats often contain regulated data but remain unscanned and unmanaged, creating a persistent blind spot for traditional DLP and DSPM programs.

How Sentra Scans Web Archives at Scale

We built web archive scanning into Sentra to make this tractable.

Sentra’s WarcReader understands both WARC and ARC formats. It:

‍

• Processes captured HTTP responses, not just headers
• Extracts the actual HTML page content and associated resources from each record
• Normalizes those payloads so they can be scanned just like any other web‑delivered content

Once we’ve pulled out the page content and resources, we run them through the same classification engine we apply to your other data stores, looking for:

‍

• PII (names, emails, addresses, national IDs, phone numbers, etc.)
• Financial data (account numbers, card numbers, bank details)
• Healthcare information and PHI indicators
• Credentials and other secrets
• Business‑sensitive data (internal IDs, case numbers, etc.)

Because WARC files can be huge, we do all of this in memory, without unpacking archives to disk. That matters for two reasons:

‍

1. Performance and scale: We can stream through large archives without creating temporary, unmanaged copies.
2. Security: We avoid writing decrypted or reconstructed content to local disks, which would create new artifacts you now have to protect.

We also handle embedded resources - images, documents, and other files captured as part of the original pages — so you’re not only seeing what was in the HTML but also what was linked or rendered alongside it. Sentra’s existing file parsers and OCR engine can inspect those nested assets for sensitive content just as they would in any other data store.

Bringing Web Archives into Your DSPM Program

Once you can actually see inside web archives, you can bring them into your data security program instead of pretending they’re “just logs.”

With Sentra, teams can:

‍

• Discover where web archives live across cloud and on‑prem (S3, Azure Blob, GCS, NFS/SMB shares, and more).
• Classify the captured content for PII, PCI, PHI, credentials, and business‑sensitive information.
• Assess regulatory exposure from long‑running archiving programs and legal holds that have accumulated unmanaged PII over time.
• Support DSAR and deletion workflows that touch archived content, so you can respond to GDPR/CCPA requests with an honest inventory that includes historical web captures.
• Evaluate scraping and threat‑intel collections to identify sensitive data they were never supposed to capture in the first place (for example, credentials, breach records, or third‑party PII).

In practice, this often leads to concrete actions like:

‍

• Tightening retention policies on specific archive sets
• Segmenting or encrypting archives that contain regulated data
• Updating crawler configurations to avoid collecting sensitive content going forward
• Aligning privacy teams, legal, and security around a shared understanding of what’s actually in years’ worth of WARC/ARC content

Web Archives Are Data Stores - Treat Them That Way

Web archives aren’t just compliance artifacts, they’re data stores, often holding sensitive and regulated information. Yet in most organizations, WARC and ARC files sit outside the scope of DSPM and data discovery, creating a blind spot between what’s stored and what’s actually secured.

‍

Sentra removes that tradeoff. You can keep the archives you’re required to maintain and gain full visibility into the data inside them. By bringing WARC and ARC files into your DSPM program, you extend coverage to web archives and other hard-to-reach data—without changing how you store or manage them.

‍

Want to see what’s hiding in your web archives? Explore how Sentra scans WARC and ARC files and uncovers sensitive data at scale.

‍

<blogcta-big>

‍