AI Agents are Changing the Insider Risk Equation

AI Agents are Changing the Insider Risk Equation

We have spent a lot of time in security talking about what happens when AI agents gain access to enterprise systems. Most of that discussion has focused on what an attacker might convince an agent to do, but another side of the problem deserves just as much attention: what happens when the person directing the agent is the risk?

Agents do not need to exploit a vulnerability to create a security incident. They can operate with the legitimate access of the person using them, reach the same files and systems that person can access, and turn a natural-language request into a sequence of actions at a pace humans cannot match. This shift also highlights the convergence of safety and security described in the latest OWASP State of AI Governance & Security report.

At Noma, we recently observed what this looks like in production enterprise environments.

While developing and validating a Noma detection capability for insider-risk behavior, we identified a coding-agent session in which an employee used an agent to collect and transfer private source code, credentials, and other corporate data from their work environment to external cloud storage. The activity unfolded over two days and demonstrated how quickly legitimate access can become a path for data exfiltration when an agent is doing the work.

This occurred while we were validating our detection capabilities. The customer was not actively looking for insider risk involving agents, highlighting why organizations should include agent activity in their insider-risk programs.

What Happened

Over the course of two days, a user instructed a coding agent to access cloud storage that the user described as personal. The agent was then used to clone multiple private repositories belonging to the organization, including the latest code from multiple branches. The source code was packaged into an archive and uploaded to the cloud-storage bucket.

The user then asked whether the code would still work if it were unpacked on another laptop without its Git history. Later, the archive was deleted from the bucket.

The activity did not end there. The user created another storage bucket and instructed the agent to upload files from the employee’s computer and synchronized cloud-storage accounts. The instruction specifically said not to exclude authentication keys or other sensitive files. Tens of gigabytes of data were ultimately transferred.

The sequence matters as much as any individual action. Private company repositories were cloned, source code was packaged and transferred to infrastructure the user described as personal, the user asked about running that code on another machine, the archive was subsequently deleted, and another large transfer followed with an explicit instruction not to exclude authentication keys or other sensitive files.

Each individual action relied on capabilities available to the user and agent. Together, they formed a data-exfiltration sequence.

As Chris Hughes, Noma’s VP of Security Strategy, puts it: “This is authorized access used for unauthorized purposes, which is the definition of insider threat. What’s new is that the agent strips out the friction and the fingerprints. Exfiltrating a codebase and its credentials is now a sentence, executed at a speed and scale no human insider could match.”

This is what agentic insider risk actually looks like

The user no longer has to manually enumerate repositories, copy directories, identify credentials, package files, configure transfers, and move the data. They can express the desired outcome and let an agent execute the intermediate steps. Agents compress the distance between intent and action while amplifying the potential impact of malicious activity on the enterprise.

This is also why treating agent security primarily as a model-security problem misses a significant part of the risk. The model was not the sensitive asset in this session. The source code, credentials, enterprise identity and its permissions, and tools available to the agent were. Ultimately, the risk came down to the actions the agent could take on the user’s behalf and the access that enabled them.

That makes agent security an identity, access, data, and runtime-behavior problem. No traditional security tool, operating in isolation, provides the context required to mitigate it.

The individual action is no longer enough

Traditional DLP and insider-risk controls were built primarily around human identities and human behavior. They can recognize familiar signals, such as a user moving an unusual amount of sensitive data to an unexpected destination. But when an agent acts on a user’s behalf, the identity associated with the action, the way systems are accessed, and the speed and sequence of events can look very different.

Most of the individual actions in this sequence are not inherently malicious. Developers clone repositories every day. Files get compressed, cloud storage gets used, and employees move data between systems. Agents also interact with local files and credentials because those capabilities may be necessary to complete legitimate work.

The problem emerges across the sequence. A repository clone becomes more significant when followed by archiving, transfer to personal cloud storage, a question about using the code on another laptop, and deletion of the archive.

Blocking every one of those actions would make the agent useless. Allowing all of them without context creates the opposite problem.

Security needs to understand the trajectory. What did the user ask for? Which identity was behind the agent? What data did it access? Which tools did it invoke? Where was the data going? What happened earlier in the session, and what happened next? Most importantly, when did a collection of individually permissible actions become behavior that should no longer be permitted?

This is one of the reasons we built Noma’s Runtime Context Engine around the full agent session rather than treating every prompt or tool call as an isolated transaction. AI Detection and Response (AI-DR) uses that context to identify dangerous behavior as it develops. Contextual Policies correlate prompts, tool calls, tool responses, identities, data, agent configuration, and previous activity so security decisions can account for the sequence, not just the individual event.

That distinction becomes important in a case like this. An upload by itself is simply an upload. An upload following the collection of private source code, creation of an archive, interaction with a destination described as personal, and a question about using that code on another laptop is something else entirely.

The hypothetical phase is ending

There has been plenty of discussion about AI agents as an insider threat. Much of it has been hypothetical, but this incident makes the risk concrete. It is unlikely to be an isolated incident and may already be unfolding across enterprise environments as agent adoption and usage grow.

Agents are already operating on employee endpoints with access to private repositories, cloud services, local files, credentials, and other sensitive enterprise data. The same capabilities that make them useful can also give an insider a faster and more scalable way to misuse the access they already have.

This is why security teams need visibility beyond individual prompts, processes, or tool calls. They need to understand what an agent is doing across the full session and recognize when a sequence of otherwise permitted actions becomes dangerous.

In this case, the signal was not any single action. It was the trajectory, which included collecting private source code, packaging it, moving it to external storage, determining whether it could be used on another machine, deleting the archive, and then initiating another large transfer with instructions not to exclude authentication keys or other sensitive files.

Agentic insider risk is no longer a scenario security teams need to imagine. It is behavior they need to detect and stop, and the harsh truth is that legacy security tools do not provide the context required to do so.

Getting Started

Ready to connect Noma? Get setup instructions on our Claude Enterprise integration page.

Want to see it in action? Reach out for a demo.