AI Agents Don’t Need More Intelligence. They Need Better Boundaries.
As artificial intelligence moves from answering questions to taking actions, organisations need to rethink where capability ends and authority begins.
For the last few years, most people have interacted with artificial intelligence in a fairly contained way. You ask a question, the system produces an answer, and then a human decides what to do with it. Even when the answer is wrong, misleading or confidently invented, there is usually still a person between the model and the real world. That model is changing quickly.
AI systems are increasingly being connected to the applications and platforms that organisations use to run their businesses. Instead of simply summarising information or drafting text, they can now read email, open tickets, query databases, retrieve documents, analyse security alerts, call APIs, modify records and, in some cases, execute operational tasks without direct human intervention.
This is usually described as agentic AI. The terminology is relatively new, but the underlying shift is easy to understand: AI is moving from being a tool that advises people to becoming a system that can act on their behalf. That distinction matters because it changes the nature of the security problem.
For a long time, much of the discussion around AI risk focused on whether models could hallucinate, expose sensitive information, produce harmful content or be manipulated through prompts. Those concerns have not disappeared, but they become much more serious when the same model can also do things.
An incorrect answer from a chatbot may waste someone’s time. An incorrect action from an autonomous system connected to production infrastructure can have consequences that are operational, financial or reputational.
The question is therefore no longer simply whether an AI system is intelligent enough to perform a task. In many cases, that has already been answered. The more important question is how much authority the organisation is willing to give it.
From assistant to operator
Consider a relatively ordinary enterprise use case.
A company wants to improve its vulnerability-management process. It connects an AI agent to its vulnerability scanner so the agent can identify new findings and determine which ones appear most important. Initially, this is little more than an analytical function.
The organisation then decides that the agent could save additional time by looking up the affected assets in the CMDB and identifying the responsible teams. That requires another integration. Soon afterwards, the agent is given access to the ticketing platform so that it can create remediation tasks automatically.
At that point, the process is already useful. The system can identify a vulnerability, determine who owns the affected server and create the necessary ticket without an analyst having to do the administrative work.
The next step seems equally logical. Give the agent access to Teams or email so that it can contact the system owner directly. Later, perhaps allow it to trigger approved remediation scripts for straightforward cases.
None of these decisions is particularly unusual, and none is necessarily a bad idea. The problem emerges from their cumulative effect.
What began as an assistant that analysed vulnerability data has gradually become an operational identity with access to several different systems and the ability to perform actions across them.
At that point, the organisation should stop thinking primarily about the AI model and start thinking about the authority surrounding it.
What can the agent see? What can it change? Which credentials does it use? Can its access be restricted to individual functions? Can it distinguish between reading information and modifying it? Can its actions be traced back afterwards? Who decides when its permissions should increase? Most importantly, what happens when it makes a mistake?
These are not new questions. Security teams already ask them about users, administrators, applications and service accounts. AI introduces a new type of actor, but it does not invalidate the principles that already exist.
Why mistakes become more important when software can act
Automation has always carried a particular kind of risk. A human can make a mistake, but automated systems can repeat the same mistake very quickly. That difference matters.
If an administrator accidentally disables the wrong user account, there is usually an opportunity to notice the error before it becomes widespread. If an automated process incorrectly decides that hundreds of accounts meet the same condition, the organisation may discover the problem only after the action has already been repeated many times.
AI introduces additional uncertainty because the decision-making process is not always deterministic. Traditional software generally follows predefined logic. If a certain condition is met, a certain action occurs. Large language models work differently. They interpret instructions and context, and their behaviour can vary depending on the information presented to them.
This flexibility is precisely what makes them useful. It is also why organisations should be cautious about allowing the model itself to determine the boundaries of its authority.
A system can be extremely capable while still being unreliable in particular circumstances. It can misunderstand instructions, misinterpret ambiguous information or behave unexpectedly when it encounters content specifically designed to influence it.
This becomes especially important when the AI consumes information from outside the organisation.
Prompt injection becomes an access-control problem
Prompt injection is often described as a weakness in which an attacker places instructions into content that an AI system later processes. Those instructions attempt to influence the system into ignoring part of its original task or behaving differently from what its operator intended.
When AI was primarily used for generating text, this was largely treated as a model-behaviour problem. Once the AI has access to tools, it becomes something more serious.
Imagine an agent responsible for reviewing incoming supplier documentation. The system retrieves a document and analyses its contents automatically. Hidden somewhere inside that document is an instruction aimed not at the human reader, but at the AI processing it.
The instruction might attempt to convince the agent to retrieve additional internal information, include confidential data in its response or perform some unrelated action.
If the AI can only summarise the document, the effect may be limited. If the same agent has access to internal file repositories, email, customer information or administrative APIs, the attack can potentially make use of those permissions. The problem begins to resemble social engineering.
Traditional phishing attacks try to persuade legitimate users to misuse their access. Prompt injection can attempt to persuade an AI agent to misuse its access instead.
The attacker does not necessarily need to compromise the underlying application or steal credentials. The attacker is attempting to manipulate an authorised identity into taking an action on their behalf.
Once viewed in that way, the central issue becomes much clearer. The weakness is not merely that the AI can be influenced. It is that the influenced system may possess enough authority for the manipulation to matter.
Instructions are not security controls
One of the easiest mistakes to make when building AI agents is to treat the system prompt as though it were a security boundary. An agent may be given instructions such as “never delete production systems”, “do not send confidential data externally” or “always ask for confirmation before making significant changes”.
Those instructions are valuable. They help define the expected behaviour of the system. They should not, however, be confused with actual access controls. If an AI agent possesses credentials that allow it to delete production infrastructure, then the organisation is still relying on the model to decide not to use that capability. That is a fragile design.
Security teams would not normally give a junior administrator unrestricted access to the entire production environment and rely on an onboarding document telling them which buttons they should avoid. The more appropriate approach is to restrict the account so that it can perform only the actions required for the role. AI should be treated in much the same way.
If the agent does not need to delete servers, it should not have that permission. If it needs to read customer information but not modify it, those functions should be separated. If it can prepare a financial transaction but should not be able to authorise one, the authorisation capability should exist somewhere outside the AI’s control. The distinction is important because it separates intelligence from authority.
The AI can determine what it thinks should happen. A separate control layer determines whether the requested action is actually permitted. That is a much stronger security model than assuming that a sufficiently well-written prompt will always produce the desired behaviour.
AI agents should become first-class identities
This leads naturally to identity and access management. When an AI agent performs meaningful work inside an organisation, it should increasingly be treated as its own identity rather than as an invisible extension of the person using it.
That identity should have clearly defined permissions, just as a user or service account would. Its credentials should be managed. Its access should be reviewable. Its actions should be logged. Where appropriate, privileged access should be temporary rather than permanent.
This approach also solves an important accountability problem. If an employee asks an agent to perform a task and the agent then modifies a record, creates a ticket or changes a system configuration, the organisation should be able to distinguish between the employee’s actions and the agent’s actions. Without separate identities, that distinction can become blurred.
The problem becomes even more pronounced when multiple agents are introduced. A finance agent, a security agent and a software-development agent may all be built on similar technology, but there is little reason for them to share the same access. The finance agent may legitimately need to process invoices. The security agent may need access to logs and vulnerability data. The development agent may require access to source-code repositories.
Their permissions should reflect their roles, not the fact that they all happen to be based on AI.
In practical terms, this means organisations should resist the temptation to give AI agents broad access because it makes integration easier. Convenience at the integration stage can become excessive privilege later.
Human approval still has a role
The obvious solution to many of these concerns is to place a person in the middle of every process. That would certainly reduce some risks. It would also remove much of the value of automation. The objective should not be to require human approval for every action. It should be to identify the points where the consequences change significantly.
An AI system investigating a security alert should not need permission to query threat-intelligence sources or retrieve relevant log information. Those are low-risk analytical activities. The same system may also be allowed to perform certain routine containment actions automatically where the risk is well understood.
However, disabling a critical production account, blocking a major network segment or making a configuration change that could interrupt customer services may justify a different level of control. The same logic applies outside security.
An AI system could research an article, generate a draft, prepare metadata and upload it to a content-management system without requiring approval at every stage. Publishing that article under an organisation’s name creates a different kind of consequence, so retaining a human decision at that point may be sensible. This is not a failure of automation. It is simply recognising that not every action carries the same level of risk.
The difficulty is designing the process well enough that human approval remains meaningful. If an operator receives hundreds of approval requests each day, those approvals will eventually become routine. People begin clicking “approve” because approving is what they normally do. At that point, the organisation may still have a formal human-in-the-loop process, but the control itself has lost much of its value.
Human involvement should therefore be concentrated at decisions where judgement genuinely matters.
The surrounding architecture matters more than the model
There is a tendency to treat AI security as a model-selection problem. Organisations spend considerable effort deciding which models employees can use, which providers are acceptable and where information is processed. These decisions are important, particularly where sensitive data is involved. Agentic AI introduces another layer that deserves equal attention: the tools connected to the model.
A very capable AI system with no access to external systems may still produce incorrect information, but its operational impact is limited. A less capable system with broad administrative access to cloud infrastructure can create far greater damage. This means the interfaces between the AI and the systems it controls should be designed carefully.
Rather than giving an agent unrestricted administrative credentials, organisations can expose limited functions through controlled APIs or broker services. An infrastructure agent may be able to retrieve system health, restart a predefined service or create a maintenance ticket without being able to delete a virtual machine.
A finance agent may be allowed to prepare a payment request while the underlying payment platform continues to enforce independent approval. A customer-service agent may be permitted to issue refunds below a certain threshold but require escalation above it.
In each case, the AI remains useful because it can perform meaningful work. The difference is that the security boundary exists outside the model. If the AI requests something it should not be able to do, the surrounding platform rejects the action regardless of how persuasive the model’s reasoning might be. That is the kind of separation organisations already rely on in mature security architectures, and there is no reason AI should be treated differently.
What happens after something goes wrong?
The discussion around AI agents often focuses heavily on prevention, but organisations also need to consider investigation and recovery. Once agents begin making autonomous decisions, traditional logging may not be enough.
If an agent modifies a system, investigators will want to know more than simply the final API call. They may need to know who initiated the original task, which agent processed it, which systems the agent consulted, which actions it requested, which permissions were exercised and whether any human approvals were involved. This becomes more difficult as agent architectures become more complex.
A person might give a task to one agent, which delegates part of the work to another agent. That second system may query several databases and call additional tools before returning the result. To the user, the entire process may look like a single action. Underneath, however, it may involve a chain of identities and decisions. If the outcome is incorrect, that chain needs to be reconstructable.
This is where familiar disciplines such as audit logging, privileged-access management and security monitoring become important again. Agentic AI may be new, but the need to understand who did what, when and with which authority is not.
Autonomy should increase gradually
There is a natural tendency within AI development to measure progress by how much human involvement can be removed. A system that completes an entire workflow autonomously appears more advanced than one that stops and asks for approval. That may be useful when demonstrating technology. It is a poor measure of production readiness.
The better question is not whether the AI can complete the task without a person. It is whether the organisation can tolerate the consequences when the AI performs that task incorrectly. For many organisations, the sensible answer will be to increase autonomy gradually.
A new agent may initially operate in an advisory mode, analysing information and recommending actions without being allowed to execute them. Once its behaviour is understood, the organisation can allow it to perform low-risk tasks automatically. More sensitive capabilities can be added later, with additional monitoring and approval requirements where necessary.
Not every system needs to reach full autonomy. In fact, some processes may never benefit from it. A system that automates 90 or 95 per cent of a workflow and requires a person only at a critical decision point may deliver nearly all of the operational benefit while retaining an important level of control. That can be a better outcome than pursuing complete autonomy simply because the technology makes it possible.
Intelligence and authority are not the same thing
AI agents are likely to become significantly more capable over the next few years. They will understand more context, interact with more systems and complete increasingly complex work. Organisations will naturally want to take advantage of those capabilities. The mistake would be to assume that increased capability should automatically result in increased authority.
An AI system may be capable of understanding an entire production environment without needing permission to modify it. It may be able to prepare a financial transaction without being allowed to approve it. It may be able to analyse identity activity without automatically disabling accounts. These are not artificial restrictions on the technology. They are normal security boundaries applied to a new kind of identity.
Security has spent decades learning that users, applications and service accounts should receive only the access they actually require. The same principle works remarkably well for AI. The technology may be new, but the lesson is not. We do not need to prevent AI agents from becoming more capable. We need to make sure that capability and authority do not become the same thing.
