Most security leaders I talk to assume that agentic AI means they need to go build something new, whether that is a new team, a new function, or a new box in the org chart that owns “AI risk.” They don’t, at least not yet.
Here is the thing almost nobody says out loud: the people who can handle an AI agent behaving like a fast, non-deterministic insider are already sitting inside your organization, spread across your SOC, your IAM team, and your identity governance function. They have the skills and they have the context. What they don’t have is a line drawn between them that tells each of them what they own when an identity goes off course. That line is the work, and it is on you as the leader, not on a new hire.
Your insiders are not just humans anymore
For a long time the insider was a person. Then non-human identities showed up, and we treated those as static, repetitive things, a service account or a token meant to do the same job the same way over and over. Nobody really connected non-human identities to the insider problem, because they didn’t behave like a threat, they behaved like a fixture.
Agentic AI broke that. Even when a person builds an agent to do something genuinely productive, the agent is non-deterministic. So now you have a new class of insider: the rogue agent, the actual attacker using an agentic identity as their proxy, and the everyday employee working through their own agent. AI is your insider threat, and it does not clock in like a human does. It works at machine speed, with real credentials and real permissions, and most of the time nobody is watching it after it authenticates.
Here is the part that makes this manageable instead of terrifying. Human, non-human, agentic: on the inside, they are all the same. They are all identities. The only real difference is behavior and what you can expect from each: a human works like a human, a non-human identity does very repetitive and structured things, and an agent is essentially a human that can move at machine speed. Stop thinking of these as three different kinds of things that each need their own program. They are one thing, identity, doing different jobs in different ways. Once you see it that way, you stop needing three new teams.
Response still belongs to the SOC
The SOC’s job is response. You are not going to take the response function away from the SOC and hand it to somebody else, and you shouldn’t try. Anything that generates an alert, by the nature of being an alert, is going to land with a response team that investigates and responds. That doesn’t change because the identity in question happens to be an agent.
What changes is the shape of the information the SOC needs to do that job well. The SOC does not hold all of it, and it never did. The context that actually decides an identity case lives in other parts of the org: some of it with your IAM team, some with identity governance, some with the app owners. The data exists. It is just not housed in one place, because that is not how security teams were built.
The data already exists. It is just scattered.
Security teams are organized by function. Network here, hardware there, IAM over in its own lane. That is how the discipline evolved, and it is fine for most things. Identity security is the exception, because it does not live cleanly in any one of those lanes. It cuts across all of them.
So the leader’s job is not to stand up a new silo. It is to break the existing ones down enough that context can move. When an alert fires, the person holding it needs to be able to reach the entitlement data, the behavioral baseline, the business context, and the person who can actually make a decision, without spending two or three times the investigation window just finding out where those things live. The information is there. Someone just has to connect the dots and decide, in advance, how they connect.
What it actually felt like from the identity seat
I spent years on the identity side of a large enterprise SOC before I moved to the vendor side, and I want to be honest about what that felt like day to day, because the fix only makes sense if you have lived the problem.
We had our own identity threat detection. But because of the size of the org, response had to reach out into the rest of the enterprise. We were, functionally, a data hub. An alert would fire in one of our posture tools. Then the real work started. We would reach out to whatever app team owned the surface, Salesforce, Workday, whatever it was, and gather context about the identity the alert was about: what permissions and entitlements they had, and what they usually do, which is often very different from what they are supposed to do. Only after all of that stitching could we make a call about the best course of action.
It was a jigsaw puzzle where everyone else was holding the pieces. Most of the investigation time was not analysis, it was liaising: explaining the situation to the next person, waiting on context, and stitching a trail of behavior together by hand. If things had been pointed in the right direction from the start, if I had known exactly where to look and those app teams had known to expect the request, the whole thing would have been faster and my job would have been a lot easier.
The missing piece was never the tool. It was the predication.
If I could go back and ask the SOC for one thing, it would not be a better dashboard, it would be knowing the appropriate response for the situation in front of me.
Threat hunting is one problem. Responding is a different one, and it is enormously configurable. How you respond, when, how quickly, and how harshly all depend on context you often do not have at decision time, like whether this is a VP, an engineer who went off the rails, or just an agent doing a job it was overprovisioned for. Without that context, even the response becomes its own investigation. You are making a high-stakes call as a shot in the dark, and that is a bad place to put a good analyst.
The same predication problem sits on the IAM side. IAM people carry deep knowledge and real industry experience. The issue is that when they suddenly get asked to do threat-hunting work they have never done, in a seat they have never sat in, it creates hesitance and confusion, not because they can’t help but because nobody told them it was coming. Enable them ahead of time. Tell them plainly: this is part of the job now, here is what you will be asked for, here is how to do it. That single act of setting the expectation removes most of the blurriness. It is internal enablement, and it comes from the top.
So who owns the insider risk workflow?
Here is the workflow I would draw. Every one of these roles can be a different person in a large shop, or the same person wearing several hats in a small one. The point is that the hats exist and someone has to own each.
It always starts with an alert from a tool, which goes to the signal owner, the person looking at the screen. They own the track from open to close. Their job is not to have the answer but to move the alert to the next stage and make sure it gets wrapped up at the end, knowing full well they don’t yet have all the information.
From there it goes to the investigation owner, who pulls the context into one place and decides what to do with it. To do that, they have to talk to an identity authority, someone with the standing to make a decision about an identity. In a big enterprise that is often an up-and-to-the-left conversation, your boss’s peer, and that person needs to know these requests are coming so they can validate them quickly instead of being ambushed.
Alongside that sits the identity conversation owner. Being able to make a decision about an identity is not the same as being the one who talks to the actual person behind it. If it is a human, someone speaks to the human, and if it is an agent, someone speaks to the agent’s owner. The data you gathered has to be validated with the human in whatever loop exists. In parallel, a business context owner works out where the alert meets the dollar sign: what these entitlements touch, what damage was done or could be done, what it costs in assets and time to unwind.
Once you have the right context and the right people, the identity authority talks to a response authority, which sits closer to the SOC. This is where the rubber meets the road. Not only do you have to be able to make a decision, you have to make the right one, and that takes both seats in the room. If one person holds both hats, it is a short conversation. Then it spins back to the investigation owner to close, back to the signal owner to close the ticket, and the backend keeps running the way it was built to.
Every one of these people already works in your enterprise. They are just not connected like this, because identity risk was never housed in a single team. Draw the line on a diagram, tell each person what the line means for them, and you cut a huge amount of time and confusion out of every identity case you will ever run.
Even if you are the whole team
If you are a smaller shop and you are wearing all of these hats yourself, this is not busywork you get to skip. It is the opposite. Write the workflow down anyway. Use it to structure your own thinking, to communicate what you did, and to audit yourself after the fact so you can defend the decision you made. And assume the company is going to grow, because when it does, the diagram you already have is the thing you hand to the second person you hire.
The ownership is in every row
One last point, because it is the one people get wrong. Responding to an identity threat is a shared responsibility, and I mean that literally. Somebody owns the final decision, yes. But because identity carries so much context, every seat in this workflow shapes the outcome. Pull entitlements from a person or an agent and you affect whatever productive work those entitlements existed to enable. So you are never assessing only the risk of what already happened. You are also assessing the risk your response itself creates.
That is why no one in this chain is just a cog. If you own a row, you own a piece of the outcome, and it is your job to keep everyone else’s row in mind when you act. The tools matter, and near real time detection of a sequence, rather than waiting for one bad event to trip a rule, is where this is heading. But the reason most identity cases drag is not the tooling. It is that nobody drew the line between the people who already have the pieces. Draw it, and you will find you had the team all along.
