MindVault Concept: Identity Uncertainty. A session stays authorized while the organization has no direct evidence of who is operating it. In data protection, it is why the same export can be routine work or a theft.
Data loss prevention tools do real work:
- They classify sensitive files.
- They watch where data goes.
- They block or warn when it heads somewhere it should not.
Many modern platforms go further and tighten or relax rules based on a user's risk level.
But nearly every DLP decision contains the same quiet input: the user. The policy asks whether this account may send this data to this place.
If an attacker is running that account inside a valid session, the answer is still yes. The policy ends up answering for the wrong person.
Same action, different meaning
In 2023, CISA, the NSA, and MS-ISAC warned that criminals were tricking employees into running legitimate remote management tools such as ScreenConnect and AnyDesk, then taking control of their computers. The advisory notes that this software generally does not trigger antivirus defenses.
Now picture a sales director exporting her full customer list on a Friday afternoon.
- For her, it might be routine prep for a quarterly review.
- For someone driving her session through a remote tool, it is the whole point of the attack.
The file, the destination, and the account are identical. DLP sees the same event both times.
The difference is who is at the controls. We call that Operator Continuity: whether the person running the session is still the one it was issued to.
- Confidence high? The export is probably what it looks like.
- Confidence dropped twenty minutes ago, when the interaction pattern changed and the session went remote? The same export deserves a hold and a quick check.
Not replacing DLP, informing it
DLP and session evidence answer different questions. They work best together.
| Question | DLP answers it with | Session evidence answers it with |
|---|---|---|
| What data is this? | Classification and labels | Not its job |
| Where is it going? | Channel and destination controls | Not its job |
| Is this account allowed to do it? | Policy and permissions | Not its job |
| Is the authorized person the one doing it? | Usually assumed | Confidence in the operator, all session long |
NIST's Zero Trust guidance says access decisions should come from dynamic policy that can include behavioral and environmental attributes. Data protection is one of the clearest places to apply that idea.
There is an older idea underneath this one. In 1975, computer scientists Jerome Saltzer and Michael Schroeder laid out design principles for protecting information. One of them, complete mediation, says every access should be checked for authority, not just the first. A session checked once at login and then trusted for hours is exactly the shortcut that principle warns against.
When a sensitive export, upload, or mass download happens, the policy can weigh the latest confidence level:
- High: normal DLP rules still apply.
- Medium: ask for a quick verification.
- Low: hold for review.
- Insufficient evidence: treat as a reason for caution, not an accusation.
That mirrors the ladder in The Proportionate Response Model.
One practical check comes first. A hold only works where the DLP or policy tool can receive the signal, match it to the right session, and act before the data leaves. Where that path is not in place, the signal still adds useful context to the DLP alert for the analyst who reviews it. A pilot should confirm which one you have.
Where session evidence does not help
There are two limits.
The right person doing the wrong thing. When the real employee takes data they should not, or is tricked into sending it, the operator is exactly who the session belongs to. Confidence stays high. That case belongs to DLP and insider risk programs. High confidence should never be read as "safe."
Data pulled from somewhere else. Data taken with a stolen session token from an attacker's own computer never passes through the employee's workstation. Cloud-side controls and identity provider signals carry that case.
A good first pilot
- Pick one high-value data path, such as CRM exports or bulk downloads from a file share.
- For thirty days, record the confidence level at the moment of each export. Change no policy.
- Review the pattern with your data protection team.
If low-confidence exports turn out to be rare and worth a second look, you have your first operator-aware rule, backed by your own data.
MFA proves who logged in. MindVault measures who stayed.
Frequently asked questions
Does continuous identity confidence replace DLP?
No. DLP protects the data itself. Session evidence adds context about who is acting, which helps DLP decide how strict to be in the moment.
What about insiders who misuse their own access?
Session evidence will usually show high confidence, because the authorized person is the one acting. Catching misuse by the right person is the job of DLP and insider risk programs.
Can a confidence signal stop an export?
Only where a tested integration lets the policy tool act on it in time. Otherwise it adds context to the alert for review and investigation.
Will this slow down legitimate work?
It should not for most people most of the time. Restrictions are meant to apply only when confidence drops and the action is sensitive, under policy your team sets. Measure it in a pilot before turning on any enforcement.
Sources: CISA, NSA, and MS-ISAC, Protecting Against Malicious Use of Remote Monitoring and Management Software, AA23-025A, January 2023 (cisa.gov). NIST SP 800-207, Zero Trust Architecture (csrc.nist.gov). NIST SP 800-63B-4, Section 5.3 Session Monitoring (pages.nist.gov).
Ideas we learned from: Jerome H. Saltzer and Michael D. Schroeder, "The Protection of Information in Computer Systems," 1975 (mit.edu).