Behavioural analytics has to expand beyond humans, saysSimon Hunt, Chief Product Officer, Securonix, a platform for agentic artificial intelligence (AI).
For years, security teams have built behavioural models around people. We learned that valid credentials only tell so much. A user can have legitimate access to a system and still behave in a way that deserves attention, which is why User and Entity Behaviour Analytics (UEBA) became such an important part of modern security operations today โ intersecting data from multiple sources over extended periods of time to build a story indicating risk has become an essential tool to identify malicious actors, both insiders and outsiders.
AI agents are creating a similar challenge in a different form. They can retrieve data, call APIs, invoke tools, interact with users, and act inside business workflows using permissions the organisation has deliberately given them. The line between AI agents and human operators is beginning to blur. As access expands, security teams need to understand whether an agent is behaving as expected and how its activity fits into the wider environment.
AI agents can work autonomously using their own access rights, or on behalf of users inheriting their rights โ both scenarios are ones that many companies typically struggle to control, but now we have the challenge of agents exploring their โrights perimeterโ much faster than any person could achieve, and without any concepts of appropriateness, company loyalties or wisdom.
AEBA, or Agent and Entity Behaviour Analytics, applies the same behavioural thinking to this new class of identity. It extends the principles behind UEBA into environments where AI agents are beginning to perform work on behalf of people and systems.
Permission not enough
Traditional access controls tell us whether an identity is allowed to perform an action. However, they say less about whether that action makes sense in context. An AI agent may be authorised to access a document repository, call a business application, or interact with a mailbox. If the same agent suddenly begins retrieving much more data than usual, accessing unfamiliar repositories, invoking tools it rarely uses, or operating at unusual times, the permissions themselves offer very little insight into whether that behaviour deserves attention.
Security teams have dealt with versions of this problem for years. Insider risk and compromised accounts both showed us that legitimate access can still produce risky behaviour. UEBA helped teams move beyond isolated events and look at patterns over time, comparing current activity with what was normal for that user or entity.
AI agents require that same depth of context, especially as they become more embedded in day-to-day operations. An agent with permissions to retrieve files and update content โ perhaps performing a task of keeping a website updated, is one mistaken prompt and poor access control rules away from publishing any confidential information it might find.
Understanding agent behaviourย ย
Behaviour becomes useful when thereย isย enough history and context around it.
Consider an agent that normally reads a small number of internal documents and prepares summaries for a particular team. Over time, its activity settles into a pattern. It touches familiar repositories, interacts with a known group of users, and invokes a predictable set of tools. If that pattern changes, there may be a perfectly reasonable explanation, but security teams should still be able to see it.
These are rarely confined to one event. Changes in access volume, tool usage, application activity, user interaction, or operating times can become meaningful when they are viewed together. An agent that suddenly accesses unfamiliar systems and retrieves more sensitive data than usual may deserve investigation even if every individual action remains technically permitted.
The OpenAI and Hugging Face incident gives us a more extreme example of the same principle. In testing, an OpenAI model reportedly chained vulnerabilities, escalated privileges, gained broader access, and eventually reached Hugging Face infrastructure while pursuing the objective it had been given. The concern was not one action in isolation. It was the progression, the persistence, and the way the model adapted as it moved through the environment. This is the same reason behavioural analytics have become valuable for human identities.
What changesย ย
The security implications grow as agents move deeper into operational workflows. An agent that summarises documents has a limited impact. An agent that can invoke APIs, change a business process, access sensitive information, or act on behalf of a user has a much stronger risk profile. The more authority these systems have, the more important it becomes to understand how that authority is being used.
We can no longer rely on โgood users having no malicious intentโ โ AI agents have no wisdom or intent, they follow their instructions as their training and statistical models allow โ they are relentless and also motivated to succeed in their tasks, and as we have seen, have become very successful at quickly expanding their access to data through ACL mistakes, over-provisioning, and even exploitation.
Applying behavioural analytics across human and non-human identities helps identify abnormal agent behaviour, suspicious human-to-agent interactions, unusual tool invocation, unauthorised AI adoption, and potential misuse or compromise. The aim is to bring agent activity into the same security picture teams already use to investigate users, identities, cloud services, endpoints, and applications.
Itโs important operationally because SOC teams already have established processes for investigating unusual behaviour, correlating activity, escalating risk, and reviewing evidence. They are just applying it to one application, rather than getting ahead of increasingly expanding AI. Agent activity should fit into those workflows rather than creating another isolated discipline that analysts have to manage separately.
Behaviour and guardrails
Behavioural analytics can tell a security team that something deserves attention but cannot determine every outcome on its own. A deviation may indicate misuse, compromise, configuration drift, or simply a legitimate change in the way an agent is being used. Security teams need enough context to understand the difference before consequential action is taken, especially when that action could affect a user, a business process, or a critical system.
This is where governance becomes part of the operating model. Findings should retain the context behind them, investigations should be explainable, and actions should be reviewable and auditable. Human approval should remain available when the potential impact warrants it. As more agent activity becomes automated, the checks an experienced analyst would normally apply need to be reflected in the logic around those workflows. That gives teams room to move faster without giving up control over decisions that carry real consequences.
Same path
Security architecture has always had to adapt as new kinds of identities gained access to valuable systems. Cloud identities changed how teams thought about authentication and privilege. Service accounts and machine identities introduced similar challenges because they could perform significant actions without a person sitting behind every transaction.
AI agents are following the same path, with an added layer of complexity because their behaviour can change according to context, instructions, and the systems they interact with. UEBA gave security teams a way to understand human and entity behaviour beyond a simple access decision. AEBA extends that discipline to agents, helping teams establish expected patterns, identify meaningful deviations, and investigate those changes alongside the rest of the environment.
Security teams will still need people who understand the business, the data, and the consequences of a decision. As agents take on more operational work, those teams need enough behavioural context to know when an agent is acting outside the expected pattern and enough control to decide what happens next. We should be designing security around that operating model now.
