Finding Shadow Assistants Before They Found Us

The problem

Employees had started using assistants faster than security could approve them. Some used the company's sanctioned enterprise assistant service. Many used personal accounts on public assistants, and nobody could say which ones, how often, or what data was going into them.

The organization needed answers to three questions:

1. Which assistants are people actually using?
2. What sensitive data is being sent to them?
3. How do we reduce that risk without blocking the approved tools people rely on?

What made it hard

• No single tool saw the whole picture. DSPM knew where sensitive data lived, but not where it went. DLP saw data moving, but not which of it mattered most.
• The same assistant service often served both corporate and personal accounts through the same domain, so traffic-based rules couldn't tell them apart.
• Blocking everything wasn't an option. The business had approved assistants for real work, and a heavy-handed rollout would have pushed people to unmanaged devices.

What I did

Connected discovery to enforcement. I used Cyera to discover and classify sensitive data across cloud and SaaS stores, then aligned those classifications with Purview sensitivity labels and DLP policies, so both tools meant the same thing by "sensitive."

Watched the paths data actually takes. Purview covered paste and upload activity on managed devices. Zscaler covered inline traffic to assistant applications. Together they showed which assistants were in use and what was being sent.

Ran in audit mode first. Before enforcing anything, I ran the policies in monitor-only mode to measure what they would catch and how much of it was noise.

Rebuilt policy around instance, not destination. Early results were dominated by false positives from people using the approved assistants correctly. I changed the policy to key on which instance the user was in (the corporate tenant versus a personal account) and on the class of data involved, rather than on the assistant service's domain.

Treated credentials as their own class. Credentials got the strictest rule: blocked everywhere, including in approved tools, with leaked keys handed off for rotation.

What we found

• Shadow-assistant usage was broader than expected: 8 assistant applications in use, most of them unsanctioned.
• Sensitive data was leaving through prompts and pastes, including patient-adjacent records, internal protocol documents, and engineering config.
• The most serious findings were credentials. AWS secret keys and other secrets were being pasted into chats, usually by engineers debugging an error with logs or config files.

Results

• False positives dropped by about two-thirds once policy distinguished the corporate tenant from personal accounts.
• Leaked credentials were deactivated within hours through a defined response: confirm the IAM user, set the key inactive, then rotate and delete.
• Most flagged users moved to the sanctioned assistant after an in-the-moment coaching prompt instead of a ticket two days later.
• Leadership got the first complete inventory of assistant usage across the company, including which tools were approved and which were not.

What I'd do differently

Align data classifications across tools on day one. We spent time reconciling DSPM categories with DLP labels after policies were already running. Agreeing on a shared set of data classes first would have saved weeks.

Build the credential response before turning on detection. Finding leaked keys is only useful if rotating them is fast. That process should exist before the first alert fires.

Related reading

• The Paste Is the Leak: the full write-up on DSPM, DLP, and policy design for shadow assistants.
• Find It Before You Label It: why inventory comes before classification.