Unintentional Risk Shows You What's Broken. Intentional Risk Tests If You Can See It

Things have changed a lot through my 13 year career building insider risk programs. New technologies have come and go, we even have a new type of insider who’s joined the workforce: the AI agent. Despite all this change, something that stood out to me is that (not unlike many aspects of cybersecurity) the core principles remain unchanged. In the end, the goal is to decide if someone or something is doing harm to your organization, intentionally or unintentionally.‍

The core principles remain because the core issues are still not properly addressed in many organizations, even with a robust toolset in place. Successful insider risk programs aren’t only about the tech stack.  They all have two things in common: integration with the IR process, and were tuned to  know your teams, policies and procedures. Without that context, every finance person exporting a spreadsheet looks like a threat. This is why SecOps teams live in a perpetual state of alert fatigue. 

Since it is still a huge challenge for many organizations, in this writeup I want to focus on the difference between intentional and unintentional insider risk, and how I approach each one. And because the insider is not always a human anymore, I'll finish with what changes when it's an AI agent.

Unintentional: people trying to get the job done

My favorite unintentional risks are a byproduct of people attempting to optimize their jobs: Shadow IT, data leaks, and now Shadow AI, which is a combination of both.

• Shadow IT: tools you didn't know someone, or whole teams, were using.
• Data leaks: someone just wants to get the job done and shares data with the wrong audience, uploads it to an unauthorized website, or sends it over email.
• Shadow AI: unapproved AI tools. It's software you didn't know about, but in many cases it's also software that leaks data. Pasting a customer contract into a random chatbot to "make it shorter" is the new forwarding to personal Gmail.

These incidents are more predictable to handle. 2 of the 3 listed have been known issues for years. What is often missing is having the full loop. When I wrote procedures for them, my thought process was:

1. Contain. Remove the shared link, delete the file, ask the vendor to delete the data if you can.
2. Ask why. Why could they access the tool or share the data? Find the exception or broken guardrail in your system.
3. Fix it. Create an implementation plan and involve the team that owns the control.
4. Notify the user. Here I usually worked with the security awareness team. Depending on the case, it can be an awareness plan, a training, or just a notification.

Important to add: insider risk incidents usually have a long post-mortem. In other words, they tell you something is most likely not working as expected. And yes, sadly, many security incidents happen unintentionally.

Intentional: someone who knows your detections

These are trickier. Now you have an insider threat actor who seeks to do harm. This actor has knowledge of the org’s inner workings and thus how to exploit them. Depending on the level of access and their role, they might even be aware of your detections and guardrails.

These are more difficult to address because they can be anything: a developer exporting source code, a salesperson taking competitive intel and sales data, any employee taking sensitive and confidential data, or someone inside your company who is paid to do harm.

There are multiple ways to go after it:

• Some actions will trigger your default DLP rules.
• Some will show up as alerts in your EDR or SIEM.
• Canary tokens and deception tech catch people looking where they shouldn't.
• For everything else, you need an insider risk platform that monitors activity and employee behavior.

As if that wasn’t enough, the trickiest part is yet to come. All of this must be done without alerting the perpetrator that you’re on to them. Your rules need to be more careful in this case because if you spook them, they might take a different route. Default DLP catches the careless ones. The careful ones are methodical: they use screenshots, a phone camera, or hide data moves in small chunks or legitimate workflows.

One implementation I have seen: when someone leaves, check the last 30 to 60 days for large data copies, unusual PRs, and access to applications they don't normally use.

A common misstep that can make quite the difference in an investigation is not bringing HR and legal in early. You need evidence that holds up, and employee monitoring has legal limits, especially in the EU. Violating the law to collect evidence can be the difference between having a defensible case and a really expensive court battle, depending on the severity of the incident.

The messy middle: you don't know intent on day one

The same action, like uploading files to a personal drive, can be either case. Intent is what the investigation tells you, not the label you start with. And a compromised account looks exactly like an insider until you find the attacker behind it.

So I think intentional insider risk is a mix of your usual security detections and the places where a specialized platform comes into play.

And now the insider can be an agent

Everything above assumes the insider is a person with motive and intent. That's not true anymore. Agents have valid identities, real permissions, and access to your data. That's pretty much the definition of an insider.

And yes, we had non-human insiders before. Service accounts, scripts, SOAR playbooks. But that automation was deterministic. Same input, same output. You could baseline a service account, and the moment it did something new, that was your alert. To be fair, abused automation wasn't always easy to catch. But at least you knew what normal looked like.

Agents don't work like that. They reason. The same agent with the same permissions can take a different path every time, depending on what it reads or updates to the model itself. So "it did something new" is not a signal anymore. It's a Tuesday. That's the shift: you can't detect an agent by its baseline alone, you need to know what triggered it and why it acted.

The Above Theory team and Forscie built the Synthetic Insider Threat Matrix (SITM) for exactly this. It extends the Insider Threat Matrix to AI agents and breaks an incident into five layers:

• Directive: what the agent is told to do.
• Configuration: what it can reach. Identity, tools, retrieval, memory.
• Invocation: what triggered it to act at that moment.
• Adverse outcome: the damage.
• Opacity: what makes it hard to see, explain or prove afterwards.

What I like is that it maps almost one to one to how I already run insider risk.

In my unintentional loop, I ask why they could access the tool and where the broken guardrail is. In SITM terms, that's Directive and Configuration. An agent with a broad directive that runs under the user's identity is the same Shadow AI problem, just running 24/7 at machine speed.

And the intent question gets even messier. An agent has no intent, they just have directives. Their example: an employee asks an internal assistant to summarize a vendor proposal. Hidden text in the file redirects the assistant, and the data leaves over approved email under the employee's identity. The employee did nothing wrong. Whoever wrote the hidden text was very intentional. And the audit log blames the employee. Nothing got compromised, every step was the system doing what it was configured to do.

That's why Opacity is the layer I'd fix first. Same as with human insiders: if you can't reconstruct who did what, under whose access, you can't decide intent and you can't take it to HR or legal. Decide what you need to log before the incident, not after.

Final Thoughts

Insider risk doesn’t have to be an unsolvable problem. There are several practical enhancements you can implement today to reduce risk. For unintentional cases: contain, fix the guardrail, coach the person. For intentional ones: investigate quietly and keep HR and legal close. For agents: walk the five layers and log enough to prove what happened.

These programs don’t fail simply from lack of tooling. It must incorporate several aspects of the business and keep your people and their agents at the center rather than the technology. All of it only works if your tooling knows what normal looks like for each team. And now for each agent too. What ties all of them together is context. Without that, you’ll continue to overwhelm your SecOps team with alerts and miss the real incidents among them. 

So before you add another tool, ask three questions:

1. Can we tell the difference between someone doing their job and someone doing harm?
2. Can we reconstruct who did what, under whose access, after the fact?
3. Are HR and legal in the room before we need them?

If any of those answers is no, that’s where your program actually starts.

Unintentional risk shows you what's broken. Intentional risk tests if you can see it.