Securing agentic AI

James Hendergart at F5 explains why security must be at the centre of agentic AI development 

AI is entering a new phase: fully autonomous systems capable of operating without human input. This next leap is being called Agentic AI — a term you’ve likely heard a lot lately. The potential benefits are vast, from improved efficiency and productivity to smarter decision-making. But with this autonomy comes a critical challenge: ensuring systems have enough access to function effectively, without compromising security.

 

Security context and access

Security context defines who can do what with a given set of data – managing the parameters around privilege and access levels. Permissions to create, modify or delete data across enterprise systems are dictated by business requirements tied to specific roles. When employees use software to perform their jobs, that software operates within a security context, enforced through accounts.

 

In this model, user accounts are linked to an employee’s identity, while service accounts are designed to manipulate corporate data independently of any individual user’s privileges. 

 

Assigning least-privileged access is typically straightforward for user accounts, since roles determine their access boundaries. But service accounts, though still constrained, are often configured with the most privileged access to enable full execution of tasks across processes. Unlike users who may have full access to some records and limited access to others based on their roles, service accounts usually require unrestricted access across systems to function as intended. 

 

Agentic AI and permission complications

Consider an organisation deploying an agentic AI assistant to support employee onboarding. Each new hire has a defined role, and the AI must access corporate systems accordingly. The assistant operates within the context of the HR personnel managing the onboarding; but what happens when it needs to grant permissions that exceed the HR team’s own access? 

 

With agentic AI, user activity and corporate processes are tightly intertwined. Business processes are designed to deliver outcomes efficiently (i.e., for all customers, employees and use cases). To function effectively, the agent often requires broader access than most individual users. Yet those users or teams are still responsible for initiating, monitoring and overseeing these processes. 

 

This creates a tension. If the agent’s permissions are tied solely to the business process it executes, rather than the access level of the human operator, security risks emerge. Block the action, and the task may fail; allow it and the user could inadvertently gain access to data beyond their privilege level — opening the door to a potential security breach.

 

Additional security steps to prevent breaches

Introducing agentic AI can increase the risk that software initially operating under a user’s context could gain elevated privileges when transitioning to an agent running under a service account. To mitigate this, agentic systems must ensure that privilege escalation and data access remain fully compliant and within security policies. 

 

One effective strategy is process branching to enforce the correct security contexts. For human employees, a sub-task can be assigned to someone with the authority to grant the required permissions, allowing the process to continue only after approval. Agentic systems should follow a similar model, segmenting actions by authorisation level to ensure that sensitive operations are always executed under appropriate oversight.

 

Another strategy is implementing adaptable security context for agents. When an agent is re-authorised each time it takes an action, the temporary permissions grant can also be revoked immediately after the action completes. Together, these two strategies enable the highest level of automation, with the exception of cases best performed with human oversight.

 

Secure by design

Establishing the right security context for AI agents must begin at the design stage. By answering a critical question: is the automated process a personal assistant meant for one or more users, or a generalised business workflow running at scale on behalf of the organisation? 

 

If it’s a personal assistant, map out the process to ensure every action and data access aligns with existing corporate security policies for the intended users. Any exceptions should be isolated, with elevated privilege tasks reassigned to individuals with the appropriate authorisation.  

 

For generalised business processes, review service account configurations to identify potential security gaps, such as those introduced by excessive privilege levels, as in the HR example. And verify that the sensitive data is not inadvertently exposed to users lacking the necessary permissions.

 

By carefully distinguishing between user and service account execution and separating high-privilege tasks, organisations can significantly reduce the risk of unintended security exposures. 

 

---

 

James Hendergart is Senior Director – Technical Research at F5

 

 Main image courtesy of iStockPhoto.com and Khanchit Khirisutchalual