R&D Team at a Mid-Size Printing Technology CompanyCatching Firmware Source Code Exfiltration That USB Controls Miss
When a firmware developer was caught uploading proprietary source code to a personal GitHub account from his workstation — three weeks of commits before the build server log review caught it — the IT security team realized their USB blocklist couldn't see what was leaving through the browser. PrivateDLP's AI screen auditing gave them the screenshot evidence and the rule set to catch the next one.
Executive Summary
A mid-size printing technology company with global R&D operations — engineers across firmware development, mechanical design, color science, and print engine calibration, distributed across multiple sites — had long relied on USB write controls to keep proprietary technology from leaving its network. The controls were strict: no USB storage on R&D workstations, encrypted engineering drives only, and a fleet-wide blocklist enforced by group policy. Then a routine build server log review turned up something troubling: a firmware developer had been committing proprietary source code to a personal GitHub account from his workstation — every day for three weeks before anyone noticed. The USB blocklist showed nothing, of course — the code was leaving through the browser, not through a USB port.
The R&D IT security lead self-funded a PrivateDLP deployment covering ~200 R&D workstations across the engineering division. The capability the team was buying: AI screen auditing that could see what was on the screen — and detect when proprietary code was being exposed through any channel a USB blocklist couldn't reach. Screenshots are analyzed by an AI model the customer's IT team selects themselves, with screenshots deleted immediately after analysis and retained evidence written to the customer's own storage. No proprietary code ever leaves the customer's environment.
Client Profile
The client is the R&D division of a mid-size printing technology company. The company designs and manufactures professional printing systems — commercial offset press controllers, wide-format printers, and industrial label printing systems — sold to print shops, publishing houses, and manufacturing facilities globally. The R&D division employs roughly 200 engineers across firmware development, mechanical design, color science, and print engine calibration. Engineers are distributed across a handful of sites, with the majority at the primary engineering center, but with a growing remote and hybrid component that took shape after 2022.
The deployment was self-funded by the R&D IT security lead after a routine build server log review uncovered a firmware developer committing proprietary source code to a personal GitHub account from his workstation — three weeks of daily commits before anyone noticed. The funding came out of the division's existing security budget. There is no formal expansion plan to other divisions — manufacturing, supply chain, and sales manage their own endpoints under separate governance. The R&D team owns its ~200 Windows workstations outright, sets its own policies, and stores its own evidence in a private blob store already used for engineering document archives.
Global R&D Footprint
Engineering teams across multiple sites, with primary engineering center and distributed engineers
Engineering Scope
Firmware, mechanical design, color science, print engine calibration — distinct rules for each discipline
R&D Workstations
~200 Windows workstations — engineers, CAD operators, firmware developers
Funding & Governance
Self-funded by R&D IT security — no company-wide rollout planned
The Challenges
A mid-size printing technology company realizing its USB blocklist has a critical blind spot — proprietary source code leaving through the browser, personal cloud, and home workstations
USB Controls Can't Catch Browser-Based Exfiltration — And That's How Proprietary Code Was Actually Leaving
The company's group policy was strict: no removable USB storage on R&D workstations, encrypted engineering drives only, and a fleet-wide blocklist enforced by endpoint management. None of that stopped a firmware developer from opening GitHub in Chrome and pushing proprietary source code to a personal repository — every day for three weeks, until a routine build server log review caught it. The IT security team had no way to see what was happening inside the browser window. They knew something was wrong; they couldn't prove it until the GitHub activity log surfaced the commits. The team needed to see what was on the screen at the moment the code left, not three weeks later from a vendor's audit log.
R&D Teams Aren't Uniform — Firmware, Mechanical Design, and Color Science All Need Different Rules
The R&D division isn't one workflow, it's four. Firmware developers live in their IDEs, pushing to internal GitLab for code review. Mechanical designers spend their day in CAD software, exporting to the internal PDM. Color scientists work in proprietary calibration tools, tuning ICC profiles for different substrate-ink combinations. Print engine calibrators run diagnostic software on physical machines. A rule that flags GitHub for one team is a daily work tool for another. The IT security team needed a way for engineering managers — not vendor consultants — to write rules in plain language that match what their own teams actually do.
The CTO Needed Evidence, Not Assurances — and the Build Logs Weren't Enough
When the GitHub breach went to the CTO, the obvious question was: show us the screenshot. The team had build server logs showing the developer's personal GitHub commits and the date range — but no visual evidence of what was on the screen at the moment the code left. The CTO needed to be able to point to a screenshot and say 'this is what was on the screen when the policy was broken,' with the file preserved in a chain-of-custody store the IT security lead controls. For a printing technology company, source code is the core IP — and the CTO's position on IP protection is backed by a board that's seen competitors lose market share to products built on stolen firmware.
Remote and Hybrid R&D Work Was Expanding the Attack Surface
After 2022, a growing share of the R&D team was working hybrid or fully remote. Engineers were taking work home, using personal equipment at least part-time, and the informal rule that 'you can finish the firmware module over the weekend' had become a de facto workflow. The IT security lead had no visibility into what was actually happening on those home setups: whether engineers were pushing code from personal machines, copying firmware binaries to personal cloud storage to review on a tablet, or — most worrying — whether the same GitHub behavior discovered in the incident was repeating on personal hardware where the USB blocklist didn't even run.
The Solution: PrivateDLP
The R&D IT security lead chose PrivateDLP for the one capability the existing stack didn't have — visibility into what was happening on the screen, with screenshot evidence captured at the moment of a policy violation
Centralized Web Management Console
The R&D IT team manages all ~200 engineering workstations from a single web console hosted inside the company's existing network. Role-based policies are pushed out by discipline — firmware, mechanical design, color science, print engine calibration — so each team gets rules that fit what they actually do, and engineering managers can submit plain-language rule requests that the security team translates and deploys in under an hour.
Windows Audit Client
A lightweight Windows client runs on each R&D workstation, capturing periodic screenshots and applying the active policy in real time. The client enforces USB controls, blocks the personal cloud and personal email sites the policy team has flagged, and screenshots are queued for analysis only when the workstation is in scope of an active rule. Engineering applications — IDEs, CAD software, calibration tools — run without interference; the client is scoped to the policies that matter for IP protection, not general productivity surveillance.
R&D Deployment: ~200 Windows workstations across the engineering division — firmware, mechanical design, color science, and print engine calibration. Rollout completed in approximately six weeks from procurement to last-site deployment. Manufacturing, supply chain, and sales are out of scope; they manage their own endpoints under separate governance.
Data Handling Choice: Screenshots are analyzed by an AI model the customer's IT team selected and configured themselves — the default model is one option, but this customer routed screenshots to an LLM they already had approval to use internally. Screenshots are deleted immediately after analysis, and any violation evidence is written to a private blob store the IT security lead already uses for engineering document archives. The customer owns its evidence end to end. No proprietary code leaves the engineering network for AI analysis or evidence storage.
Implementation & Key Capabilities
PrivateDLP gave the R&D IT security lead the screen-level visibility and evidence chain the existing DLP stack couldn't — wrapped in a deployment the CTO could approve
AI Screen Auditing With Natural-Language Rules Written By Engineering Managers
The capability the IT security lead was buying: AI analysis of periodic screenshots, with rules that line managers can write in plain English and the security team can deploy in minutes:
- Plain-language rule definition: A firmware team lead writes a rule like 'flag any screenshot showing source code in a personal GitHub commit window' — no regex, no DLP consultant
- Periodic screenshot capture from the Windows audit client, queued for analysis only while the workstation is in scope of an active rule
- Role-scoped rule sets: firmware, mechanical design, color science, and print engine calibration each get their own policy bundle — so a rule that flags personal GitHub for firmware doesn't trigger false positives for mechanical designers using internal GitLab
- Audit trail of every rule change — who wrote it, who approved it, when it went live, and which workstations it currently applies to
Privacy-First Screenshot Handling — Customer's AI, Customer's Storage
The IT security lead signed off on the deployment because the data handling met the same standard the engineering division applies to its own IP:
- Screenshots are deleted immediately after AI analysis completes — they are not retained on the workstation or in any queue once the analysis result is recorded
- The customer's IT team selects which AI model performs the analysis — the default model is one option, but this customer routed screenshots to an LLM they already had approval to use internally, with all inference happening inside the engineering network
- Screenshots are not used to train any AI model, including the customer's own — analysis is read-only and the model has no retention path back to the source data
- Violation evidence is written to a private blob store the IT security lead already uses for engineering document archives, with chain-of-custody metadata captured at the moment of write — not retroactively
Configurable Violation Alerts With Screenshot Evidence
The CTO's question was 'show us the screenshot.' The alerting system is built to answer it:
- Real-time alert to the IT security lead and the CTO the moment a rule fires, with the violating screenshot attached and the user, workstation, timestamp, and active rule identified
- Alert routing by rule severity — a proprietary code upload to personal GitHub pages the on-call security analyst; a low-severity policy nudge is logged for the morning review
- Screenshot evidence preserved in the IT security lead's blob store for the retention period the company's IP protection policy requires — currently five years for confirmed IP breach artifacts
- Investigation-ready export: the IT security lead can produce a single ZIP of screenshots, rule versions, and access logs for any workstation over any date range, formatted for the CTO's review or legal counsel if needed
Enterprise Device & Network Control Built Around How R&D Actually Works
The screen auditing is the differentiator, but the deployment also replaced two legacy endpoint tools the R&D team had been maintaining on the side:
- USB read/write control with a hardware allowlist — encrypted engineering drives approved for legitimate data exchange; everything else blocked at the endpoint
- Web allowlists and blocklists by role — firmware developers get the internal GitLab and approved documentation sites; mechanical designers get the internal PDM and approved CAD portals; personal cloud and personal email are blocked at the browser level for all R&D roles
- Application control and firewall rules — the IDE, CAD software, calibration tools, and internal GitLab are allowlisted for network access; everything else is denied by default
- Time-based policies — stricter rules apply during core business hours when engineers are at their workstations; the rules are logged rather than enforced during approved overtime windows to reduce friction for legitimate evening work
What Changed In The R&D Division
Four months after the rollout, the team is catching what their USB blocklist couldn't — and producing evidence the CTO can hand to the board without rebuilding it from scratch
| Metric / Objective | Before PrivateDLP | After PrivateDLP |
|---|---|---|
IP Exfiltration Incidents Caught | USB blocklist showed nothing; the GitHub breach was caught three weeks later from a build server log, not from any internal alert | 5 confirmed policy violations flagged in the first 60 days — including 2 that the team would not have caught from logs alone |
CTO Audit Response Time | Questions about the GitHub breach took weeks to answer; the team was reconstructing events from build logs and GitHub's activity report | IT security lead produces screenshot evidence on demand; subsequent CTO questions answered the same day |
Confirmed Source Code Exfiltration | 1 confirmed breach (firmware developer uploading to personal GitHub); IT security had no way to know if it was an isolated incident or a pattern | 0 confirmed IP exfiltration events in the 4 months following rollout; 3 caught-and-corrected before any code left the network |
R&D Overtime Compliance | Overnight and weekend R&D work was invisible; engineers routing work through personal cloud to 'finish at home' had become a de facto workflow | Time-based policies surfaced a small group of repeat after-hours personal GitHub activity; addressed via policy update and team training, no repeat incidents |
"We were never going to catch a personal GitHub commit with a USB blocklist. The first time the AI flagged a firmware source code window alongside an open GitHub upload window, we had the screenshot we needed to act — without having to wait three weeks for a build server log to surface it. That evidence is what the CTO actually needed to see, and it's what the board was asking for when they saw what happened. Six months in, the screenshot is the artifact, not the log line."
"I'd been asking for screen-level IP monitoring for eighteen months and getting the same answer from every vendor — six-figure SOC integration, year-long rollout, and a regex language my firmware team leads can't read. What I actually needed was a rule my color science manager could write in a sentence and the security team could deploy the same morning. The first time one of those rules fired, we caught a mechanical designer who'd been quietly uploading CAD export files to a personal Google Drive after hours — not malicious, just working from home through her personal cloud like half the team was doing. But the kind of thing that becomes a competitor briefing if you find it six months later in a forensic audit."
The R&D division's deployment is small, self-funded, and intentionally bounded to the workflows the security team can directly govern. Manufacturing, supply chain, and sales run their own endpoint programs under separate governance. What changed inside the R&D division is the kind of change that doesn't show up in a feature list: when something looks wrong on an engineering workstation, the security team can answer the CTO's question with a screenshot, in the same hour, from evidence the company already owns.
The deployment is not a company-wide rollout plan. It is a division that found a blind spot, bought a tool that fit the gap, and built a rule set its own engineering managers can actually maintain.