Above Security is the inaugural sponsor of the Insider Threat Matrix
Read more
Israel Bryski
May 20, 2026
Israel Bryski
May 20, 2026
“An employee or contractor with authorized access who, intentionally or unintentionally, caused harm to the firm.”
This was the definition of “insider” from the first insider risk program I ever stood up. It was just one page.. It has been so ingrained in me that I could quote it from memory.Not only has it been this way for years, the definition itself is clean and defensible, and memorable. And wrong.
Not wrong in 2018, when I wrote it, but it’s definitely wrong in 2026. Most of the programs I see today are still operating off a version of that same charter, and it's quietly costing them visibility into much of their actual exposure.
If you read CISA's Insider Threat Mitigation Guide, (which is still the cleanest publicly available primer and one I hand to new hires) the definition reads as "the threat that an insider will use their authorized access, intentionally or unintentionally, to do harm to the department's mission, resources, personnel, facilities, information, equipment, networks, or systems."
NIST's SP 800-53 and SP 800-172 frame it almost identically: "the threat that an insider will use their authorized access, wittingly or unwittingly, to do harm."
Two phrases are doing all the work in both definitions: insider and authorized access.
CISA goes even further to quantify who qualifies as an insider. "Any person who has or had authorized access to or knowledge of an organization's resources, including personnel, facilities, information, equipment, networks, and systems."
For most of my career, I operationalized that as a roster. HR system on one side, joiner-mover-leaver process on the other, badged employees and named contractors in the middle. If you had a row in Workday, you were an insider. If you didn't, you weren't.
That model was already creaking by 2020. It broke entirely somewhere between the rise of agentic AI and the explosion of OAuth-connected SaaS. We just didn't update the definition to match.
Here's what's changed in the last 36 months that the standard definition doesn't accommodate.
I had this conversation with a peer CISO at a mid-size asset manager last month. Their developer productivity team had deployed an agent that could read across their Confluence, Jira, GitHub, and a portion of their data lake. The agent had a service account. The service account had been provisioned a year earlier when the use case was narrower. Nobody had re-reviewed its scope. The agent could see deal memos that humans in adjacent business units couldn't.
When I asked who in the security org owned the agent's behavior, meaning, who would notice if it started moving data in ways it shouldn't, the answer was… a long pause.
This is the gap. By any reasonable reading of CISA's definition, that agent is an insider. It has authorized access, the access is broader than any single employee's, and it can absolutely "do harm to the department's mission, resources, personnel, facilities, information, equipment, networks, or systems,” either through its own behavior or through an instruction injected into its context. But the firm's insider risk program had no mechanism to monitor it because it wasn't in Workday.
The 2025 IBM Cost of a Data Breach Report found that malicious insider breaches are now the most expensive type of attack, costing an average of $4.92 million per incident. This exceeds the global average breach cost ($4.44 million) and highlights that when an identity is compromised or turned, the damage is deeper and harder to contain.
The cost driver isn't the bad actor. It's the well-intentioned human (or agent) operating in an environment too complicated for them to make safe decisions in.
If you've done an OAuth review of your Google Workspace or Microsoft 365 tenant lately, you know what I mean. Every "Sign in with Google" approval an employee clicks is a new identity with read or read-write scope into your environment, created without an access request, without a manager approval, without an HR file, and almost always without a corresponding decommissioning process.
In a tenant of 5,000 employees, it's not unusual to find 1,500 to 3,000 of these third-party app identities, the majority of which haven't been touched in six months and a meaningful fraction of which retain mailbox, drive, or calendar scope.
By the CISA definition, every one of these is an insider. They have authorized access. They were granted that access by someone with the authority to do so. They can be used to do harm. But they almost never appear in an insider risk program's data model, because the data model was designed around humans.
Third party risk is the oldest of the three, but it's gotten meaningfully worse in the last few years because the economics of contractor sprawl changed.
When I ran a program in financial services, the second-line cyber risk team did quarterly attestations of contractor access. We caught real things. But the population we attested over was the population the procurement system knew about. The actual population, the offshore developer's cousin who got temporarily VPN'd in to debug a release, the consultant who was supposed to be off after the engagement closed in March and still had Slack access in October, the vendor employee who switched firms but never had their account reprovisioned because the relationship was at the firm level, that population was always larger than the procurement system suggested.
CISA names this directly. "This status makes it possible for current or former employees, contractors, and other trusted insiders to cause significant damage." The phrase other trusted insiders is doing a lot of work in that sentence, and most programs are not honest about how wide that aperture is.
I want to be careful here, because the natural reaction when you read a list like the one above is to ask which tool catches it, but that instinct is part of the problem.The correct opening questions are:
If your insider risk program charter still reads "employees and contractors," and your firm has materially deployed agents, OAuth apps, or third-party integrations, the charter is out of date. Everything downstream of the charter, your detection coverage, your investigation playbooks, your access reviews, your offboarding procedures, is operating against a smaller population than the actual risk surface.
Updating that charter is not a quick fix. It's a conversation with your CIO, your CTO, your CHRO, your General Counsel, and probably your Chief AI Officer (if you have one) about who owns governance over each category of "insider" the new definition covers. In my experience, that conversation surfaces ownership gaps you didn't know existed and surfacing them is most of the work.
The CMU CERT Common Sense Guide to Mitigating Insider Threats has been saying a version of this for years: insider risk is an organizational and cultural problem before it's a technical one. Most programs I've reviewed have skipped the organizational part and gone straight to the controls catalog. The controls then underperform, and the program gets blamed for the underperformance.
I made that mistake. I'm trying to talk peers out of repeating it.
I'm not going to pretend I have a finished version of this, but then again security is a living, breathing, and evolving practice. I'm working on it in real time, talking to peers, watching how the regulators are starting to frame it. But the working draft I'm using right now reads something like this:
An insider is any human or non-human identity, employee, contractor, vendor, service account, OAuth-connected application, or autonomous agent that holds, or has recently held, authorized access to the organization's systems, data, or decision-making processes, and whose action or inaction could result in harm to the organization, intentionally or unintentionally.
It's deliberately wordier than the CISA version. The 2018 definition was elegant because it was narrow, but so was the attack surface. The 2026 definition must be wider to be useful, and the price of width is fewer crisp sentences.
I'd rather have a charter that covers the actual risk surface than a charter I can quote at a cocktail party.
Next week in Part II I'll get into something the cases I've worked on have been telling me for years: when you walk a malicious insider incident backwards, they all rhyme and there's a thirty-year-old framework that explains why most programs are looking at the wrong stage.
%202%20(1).svg)
