Business pressure to take advantage of agentic AI is leading to security risks, so here’s how to act
For the last couple of years, companies have been using language models to summarise, generate content, and help people move faster but a person still decided what to do with the output. Agents are different. An AI agent can retrieve data, write code, trigger workflows, and operate across applications. Once AI starts doing things instead of just saying things, the security problem changes, because now you have to think about what the system can reach. A lot of people are still focused on the wrong part of this, model accuracy, hallucinations, and output quality. The more pressing question is what these systems can access and what happens when they get it wrong.
AI agents vs generative AI: What changes when systems can act
Traditionally, machine learning systems classified, scored, or predicted. They could tell you whether a transaction looked suspicious, whether a customer might churn, or whether a lead should be prioritised. Generative AI expanded that. Now the system could explain, summarise, translate, and write code. But even then, the model was still predicting the next token and producing an output.
Asking a chatbot how to book a flight is passive. Asking an agent to actually book the flight means it has to review options, make choices, use personal information, interact with external systems, and potentially spend money. That crosses from generation into action, and once you give a system the ability to act, you are dealing with a participant in your enterprise systems, one that operates as an identity inside your environment.
AI agents create risk even when the model is accurate
Today’s models can be very good at prediction but not how confident they should be in that prediction. A system can produce an answer that sounds plausible and still have no reliable sense of whether it is operating in a high or low-confidence situation. With traditional question/answer LLMs, hallucinations are amusing but when a hallucination happens in an agent-based system, your business can be at risk.
Agentic systems are powerful but they are not dependable enough to be trusted on their own, especially when the task involves access, authority, and execution. So instead of asking “How do I make the agent trustworthy?” The better question is, “How do I constrain what the agent is allowed to do?”
This gets more complicated when you stop thinking about one agent and start thinking about systems of agents. Agentic workflows are rarely linear. One agent plans, another executes, a third evaluates the results, etc. They may loop through that process several times until they get to an outcome that works. This can be incredibly powerful. It is also risky. Once you have multiple agents working together, the system is no longer following a narrow, predetermined path. It is exploring options, iterating, and adjusting its behaviour based on feedback.
The same pattern has already shown up very clearly in real-world red-teaming scenarios. The important point is that the system is optimising towards its objective. If the objective is to get information, it will keep exploring until it finds a successful path unless something outside the agent prevents it.
Access control is the real security boundary for AI agents
For an agent to be useful, it needs access and that’s where the security model changes. An agent cannot operate across a workflow unless it can interact with the systems involved. Often, this means operating with inherited permissions, and sometimes it means broad permissions across multiple systems.
In an enterprise environment, the action itself usually does not tell you whether something is wrong. Pulling financial data is normal, as is sending an email. The difference between a valid action and a security problem is context:
- Who is the agent acting for?
- What was it supposed to do?
- What data should it have access to at that moment?
- What action was actually necessary to complete the task?
Without that information, a lot of bad behaviour looks legitimate. The only way to know something has gone wrong is to connect the action to identity, permissions, and intent.
Why is AI agent access control easier to describe than to implement?
Suppose I ask an agent to look at last quarter’s financials and draft an email to my boss summarising the results. That sounds simple, but even that task carries a number of identity questions.
The easy version of the problem is intersection. What can the user access? What can the agent system access? Give the agent the overlap between those two things. That at least prevents some obvious failures.
This does not solve the harder problem, which is context. The agent needs enough access to retrieve the financials. It needs enough access to draft or send the email. It does not, however, need access to unrelated data on the same server or read access to my boss’s emails or even need persistent access to the financials after that part of the task is complete.
What you actually want is correctly scoped, task-specific, temporary access. Give the system only the permissions it needs for the task at hand, and only for as long as it needs them. Limit the blast radius if the system is compromised, manipulated, or simply wrong. This is very close to a zero trust way of thinking with the smallest useful scope allowed.
An unfinished AI agent control model and what you can do about it
Most enterprise environments still rely on broad permissions and persistent access and were designed around static roles. So, over-permissioning happens. You give the agent access to everything it might need, because you do not have a reliable way to determine what it needs at a particular moment. This is how risk expands.
Enterprises are not going to wait for perfect security models before they deploy agents. This means it is imperative that organisations ensure they are putting the right controls in place before these systems become even more deeply embedded in their environments.
Constrain the identity. Constrain the permissions. Constrain the duration of access. Identity connects action to actor. It tells you what the system is doing on whose behalf, helps distinguish valid requests from inappropriate access, and gives you the mechanism to set and enforce boundaries.
Without the right governance, agent behavior may look reasonable… right up until the moment it becomes a breach.
