Introducing the Synthetic Insider Threat Matrix: The Insider Framework for the Agentic Era

Security has always moved quickly, but AI has created a new definition of “fast” for the entire technology community - especially those of us who work in AI research. 

It seems like every day we at Above Theory see a new agentic technology: support assistants, intranet copilots - operational assistants exist for every business unit these days. Every few weeks we’ll come across something interesting that warrants further research, and each review ends the same way. We could describe what might go wrong in vivid detail, but we still could not cleanly prove how or why.

The typical “wrongs” like vulnerabilities or misconfigurations weren’t applicable to our findings, which is what started us down this path. The only real commonality was the existence of the agent itself, which reminded us heavily of insider threat, obviously the thing most near and dear to us here at Above. But it didn’t feel right to call this insider threat as it stands today because insiders are human, right? 

That may have been true prior to 2026, but these days insiders don’t all live in the organic realm. These developments have created a new layer of insider risk on top of what already existed - similar use cases but completely different methods.

We brought our findings to our friends at Forscie to see how we could operationalize them for the community. We already work closely with them on the Insider Threat Matrix™ (ITM) in both an open source context and within our own product. It was quite clear this was a huge gap in the industry - both in how we protect against it and in how we speak about the threat itself. This was the same thing James and his team tackled years ago with the ITM, which is what led us to what we’re discussing in this post: The Synthetic Insider Threat Matrix™.

What is the original Insider Threat Matrix™?

The original ITM gave defenders a shared language for how trusted humans become threats. Security was primarily discussed in terms of external threats prior to the ITM, but the Forscie team turned that internally so we could speak about it in a common language across the industry. 

By establishing a unified taxonomy for technical logs and behaviors, the ITM removes guesswork from investigations. It enables security teams to identify subtle indicators of compromise early in the kill chain, standardize incident reporting, and build proactive defenses before significant damage occurs. (Figure 1)

While this is comprehensive for human insiders, the synthetic problem is already here. Trusted AI agents can reason, invoke tools, touch data, inherit identities, and take action. The current insider language has been entirely organic…until now. 

What changes when the insider is synthetic?

What makes insider threats hard is the legitimacy: valid accounts, real perms, and actions that looked normal until enough context accumulated around them. An attacker has to get in. An insider is already there, and the entire discipline of insider risk exists because "already there" breaks most of the assumptions the rest of security is built on. 

While the risks are the same between organics and synthetics, how agents work affects how we approach defending against them. Some key questions arose in this exploration:

• If an agent holds a valid identity and real permissions, is it inside the trust boundary or outside it?
• When an agent acts, whose action was it: the agent’s, the employee who prompted it, or whoever wrote the document it read?
• Why do two agents with identical permissions carry completely different risk?
• And when it goes wrong, what would we need to have logged to prove what actually happened?

How do we talk about synthetic insiders?

Our first instinct was to reuse the vocabulary we already had, but we found that while the problems were real, they weren’t addressing our specific findings. Each turned out to describe either a weakness or a result, almost never the path between the two.

Say an assistant exfiltrates a customer list. "Prompt injection" tells you how the behavior was steered, but nothing about why the assistant could reach the list. "Excessive permissions" explains the reach but not the trigger. "Data leakage" names the damage after the fact. Three accurate labels, three different parts of the elephant, no incident.

The more systems we looked at, the more consistent the pattern got. A harmful action almost always needed several conditions to line up at once: 

• what the agent was told to do 
• what its configuration allowed it to reach
• what caused it to run at that moment
• what damage followed
• what made the whole thing hard to see afterwards

The interesting part was never any single condition; it was the relationship between them. It was pretty clear our current verbiage wouldn’t accurately communicate what we needed to. 

Enter the Synthetic Insider Threat Matrix (SITM).‍

Five layers for seeing the whole picture

This line of questioning led us to build different pillars for the SITM that line up with how the agents actually work. (Figure 2)

What are the five pillars of the SITM?

Individually these are unremarkable, but together they let a defender describe not only what happened, but how a synthetic subject became capable of doing it in the first place.

SAR1: Directive
The objectives and constraints that determine how a synthetic subject is meant to behave. This includes public-facing conversational systems, internal assistants, embedded AI features, event-triggered agents, autonomous agents, and misaligned directives.

SAR2: Configuration
The access and settings that define what the subject can do: human or non-human identity, action control, connected tools, enterprise retrieval, external communications, model provenance, orchestration, persistent memory, and standing instructions.

SAR3: Invocation
The input, event, message, tool output, memory state, or other trigger that causes the subject to act. The same agent can be safe under one invocation path and dangerous under another.

SAR4: Adverse Outcome
The organizational harm: exfiltration, unauthorized record changes, fraud, destructive action, impersonation, non-compliant output, boundary escape, harmful propagation, or unbounded resource consumption.

SAR5: Opacity
The conditions that frustrate observation, attribution, explanation, reproduction, or containment, such as concealed reasoning, evaluation-aware behavior, unreliable self-reporting, missing provenance, or gaps in logging.

Each pillar is connected to the others, which is where the value actually lies. A directive only becomes meaningful in the context of a configuration. A configuration only becomes dangerous under a particular invocation. An adverse outcome is only investigable, or not, depending on opacity.

What this looks like IRL

The best way to showcase the SITM is to put it in the context of a real life scenario, so we created one based on several of the systems and environments we analyzed.

The scenario: an internal assistant is deployed to help the commercial team move faster. It can search the company’s document store, it can call a handful of connected business systems, and it runs under the identity of whichever employee is talking to it. Nothing fancy, just an internal ops tool. (Figure 3)

1. Directive: broad, helpful

"Help employees answer questions using internal documents and connected systems." Nothing in that sentence is wrong. It is also unbounded: it does not say which documents, which systems, or which requests should be refused.

2. Configuration: access gained

Rather than holding its own service identity, the assistant acts as the user. Enterprise retrieval is on, several tools are connected, and it can send outbound mail. Every one of those was a deliberate product decision, and each was reasonable on its own.

3. Invocation: untrusted document arrives

An employee asks the assistant to summarize a proposal that arrived from a prospective vendor. The file is unremarkable and has been sitting in a shared folder the retrieval system indexes. Inside it, text that no human reads carefully redirects the assistant’s objective.

4. Configuration: The assistant calls a connected system

The redirected objective is pursued exactly as a legitimate one would be. The tool call is well-formed, authorized, and carried out under the employee’s identity. Nothing rejects it, because there is nothing to reject. This is the system working.

5. Adverse outcome: Data leaves through a legitimate channel 

The result is summarized and sent outward over a communication path the organization approved and monitors for entirely different things. To every control along that path, this is an employee sending an email.

6. Opacity: no trail

Tool-call provenance is thin, the assistant’s intermediate reasoning was never retained, and the audit log attributes the action to the employee. Ask the assistant afterwards what it did and it will produce a fluent, confident account that may not be true.‍

No compromise, all the risk

Notice what is missing in this scenario: there is no point at which anything is compromised. Every step is a system doing what it was configured to do. The incident is not located in any single node; it lives in the sequence.

Which is why "prompt injection" is such an unsatisfying answer alone. Prompt injection explains the steering and nothing else. Remove the outbound mail tool and the same injection is a nuisance. Remove the inherited identity and the same tool call fails. Retain the reasoning trace and the same investigation succeeds. 

The chain, not the link, is what a defender can actually act on.

Viewing this as a chain also helps with the attribution problem. Was the actor the employee, since they prompted it? The agent, since it took the action? These are only two of the options; there's also the orchestration layer, the model provider, vendors, other agents… There are many places for failure here.

In real systems the honest answer is usually "several of these, in a specific order." That is exactly why identity, invocation, action control, provenance, and logging all appear as first-class parts of the model rather than as footnotes to it.

From framework to practice

A framework that only produces better vocabulary is a framework that ends up in a PDF nobody opens. The test we hold the SITM to is whether it changes decisions: what gets built, what gets logged, what ships. In practice, it does five things.

• Threat-model an agent before it ships
  Walk the five layers against the design. Unbounded directives and inherited-identity decisions are visible on a whiteboard months before they are visible in production.
• Map detections to chains, not symptoms
  A rule for "unusual outbound volume" fires at step five. A detection tied to invocation plus tool call fires while there is still something left to stop.
• Build adversarial evaluations around real invocation paths
  Test the agent the way it is actually reached, through retrieved documents, tool outputs, memory state, and messages from other agents, not only through the chat box.
• Decide where preventive controls belong
  The layers make it explicit whether a control belongs at the directive, the identity, the invocation path, or the action itself. Those are four very different engineering tickets.
• Specify the telemetry before you need it
  Opacity is the one layer that is cheap to fix in advance and nearly impossible to fix afterwards. Decide now what you would need in order to reconstruct a decision.

It also draws a cleaner boundary between capability and risk, which is where a lot of AI security conversations go wrong. An agent having access to a tool is a capability. That tool being callable under an untrusted invocation is a risk condition. 

The tool producing an unauthorized business action is an outcome. Missing logs that stop you from proving why it happened are opacity. Four different problems, four different owners, four different fixes, and they get conflated constantly. 

The first question is never "is this AI risky." It’s who did this, under whose access, and whether we can prove it. Most teams have deployed agents far faster than they built any way to answer that.

A map for territory that is still changing

Agentic systems are changing too quickly for any framework to pretend it is finished. New execution models, memory architectures, tool protocols, multi-agent patterns, and evaluation techniques will keep changing what a synthetic insider can do, and some of what is written above will age badly. That is a reason to build a structure that can take on change, not a reason to wait.

The original ITM made human insider behavior discussable in a rigorous, composable way. Synthetic insiders deserve the same treatment now, while the deployments are still new enough to change. As AI systems are handed more trust, more identity, more context, and more authority inside the enterprise, the question is no longer whether they belong in the insider threat model. It’s whether you know how to manage them.