When Trusted Identities Stop Behaving: The SOC’s AI Challenge

176 Views

It is 2am, and a service account that has run the same overnight job for two years has just pulled a customer export that it has never touched. The credentials are valid and the permissions were approved. Nothing in the alert says it is wrong, and nothing says it is fine. In most SOCs, that alert waits until someone has an hour to find out which is the case.

Scenes like this are becoming more common as AI agents, copilots and automated workflows take on real work across the business. They retrieve information, interact with applications and take actions on behalf of users and systems. Each one runs on access someone granted on purpose: tokens, service accounts, API keys and application permissions.

For security operations teams, appropriate access is the starting point. The harder question is whether what happens through it makes sense.

AI Is Changing What the SOC Must Investigate

An employee identity is relatively easy to reason about. A person signs in, works within an assigned role and does things a colleague would recognise. However, non-human identities behave differently. Service accounts, machine identities and automation credentials run around the clock and touch many systems without a person starting each action.

AI agents add another layer, because they can reason, choose tools and act in pursuit of a goal. That changes what an analyst has to establish: which agent acted, under whose credentials, and whether it has ever done this before.

OWASP’s AI Agent Security Cheat Sheet names tool abuse and privilege escalation among the key risks, warning that agents may exploit overly permissive tools to perform unintended actions or reach unauthorised resources. It recommends granting agents only the minimum tools their task needs, scoping permissions at tool level and requiring explicit authorisation for sensitive operations. Those controls limit what an agent can reach. The SOC still has to know what the agent did with that access, whether that was expected, and what else it touched.

The Evidence Rarely Sits in One Place

To understand what an AI or non-human identity has done, an analyst usually needs evidence from several systems: the identity platform, SaaS audit logs, cloud infrastructure, endpoint alerts, API activity and threat intelligence.

On its own, an unusual action by an agent may not look worth escalating. The picture changes when the same agent has also reached an unfamiliar resource, connected to a newly observed endpoint and stepped outside its usual pattern. Analysts need enough context to see that those events belong to the same incident. Separate alerts about each one add to the queue without answering that.

Where Today’s SOC Model Strains

In most SOCs, that correlation is still done by hand. An analyst moves between consoles, works out what sits behind the alert and decides whether the combined evidence warrants escalation. Coverage stops where the team’s hours stop, and every new agent, automated process and machine-to-machine connection adds another identity and another behaviour pattern to the same queue.

The questions are the same every time. What triggered the alert? Which systems, identities and resources are involved? What has the identity done? Is that normal here, and does the combination point to a real threat? Turning scattered evidence into a clear, decision-ready account of what happened is what answers them.

When analysts start from those answers rather than having to assemble them, they are far better placed to separate real risk from background noise.

How the Work Connects

A collective of specialised AI agents can work an alert like the 2am export example end to end: what the identity is permitted to do, what it has done before, what changed recently and who owns the systems it touched. The agents hand findings to each other, from threat intelligence to hunting to investigation, without anyone carrying the work across. What reaches the analyst is a finding with the evidence and the reasoning attached, ready for a decision.

Here the defender holds the edge. Agents working inside your environment know what normal looks like, what shifted last week and which person owns which host. An attacker using a borrowed identity does not.

OWASP lists excessive autonomy among the key risks of AI agents and recommends human approval for high-impact actions. In the SOC, that oversight works best as boundaries that your team sets: what the agents may act on alone, where they stop, and what always comes to a person, with a record that shows the limits held. Your analysts own every verdict, and their time goes to the calls that need their experience, with the evidence already assembled.

Security Operations Must Keep Pace with AI

AI adoption is not going to wait for security to catch up. The business wants agents that reconcile invoices overnight and answer customers at midnight, and security teams need an approach that makes that possible rather than blocking it.

Identity and access controls remain fundamental, but they answer only part of the question. The rest is behaviour: how each identity acts in practice, how its activity connects across the environment, and when approved access is being used in a way that nobody intended.

Approved credentials, sanctioned API access and intentionally granted permissions do not make every action taken through them legitimate. Telling the two apart is now part of the SOC’s everyday work.

Investigating Identity in Context

As AI becomes part of everyday business processes, identity-related activity has to be investigated in context, with permissions, behaviour, threat intelligence and security telemetry brought together so that analysts see the whole picture rather than one alert at a time.

Trusted access will keep growing, because the business wants what AI agents deliver. The SOC does not need to slow that down. It needs to know, for every identity, whether what it’s doing makes sense here. When every alert is worked in context and your analysts start from a finding rather than a queue, a trusted identity that stops behaving in a trusted way becomes one more call that your team makes with the evidence in front of them.