As autonomous AI leaves the lab and becomes a fixture in day-to-day operations, it is clear that AI agents can do more than just experiment. With little need for human input they are now retrieving data, making calls to APIs, deciding on courses of action and seeing multi-step tasks through to completion. Such autonomy is their strength but also what complicates the security picture.
The issue for businesses has shifted from whether these agents are of value to whether they can be put in place without opening up new operational or compliance risks. They can, provided security is part of the design and deployment from the start instead of being tacked on at the end. With the right approach – continuous monitoring, identity-based access and risk-informed oversight – enterprises can move forward without putting security teams in the position of having to put the brakes on every AI initiative.
What makes the risk profile of autonomous AI different
There is a world of difference between traditional generative AI and an autonomous agent. Where the former will churn out text, code or an image in response to a prompt, an agent can take a goal and plan the steps to achieve it, acting across CRM systems, databases and email.
This wider remit means a larger attack surface. An agent with too many permissions might alter records, set off the wrong process or lay bare confidential information. Then there is the matter of prompt injection, where malicious instructions in a document or API response can be used to subvert the agent.
It is not as though AI agents are unsafe by nature. The danger lies in how some organisations deploy them: with broad permissions, long-lived credentials and no real visibility into what is happening, all without assigning proper ownership.
Establishing ownership and visibility
An enterprise must first have a handle on what its agents are and where they are before it can secure them. A central inventory is called for to log the platform, tools, data sources and degree of autonomy for each one, along with who owns it. This is key when staff are developing “shadow AI” applications that have not gone through formal IT channels.
Every agent ought to have a business owner to vouch for its purpose and a technical counterpart to look after its configuration and lifecycle. Centralised governance should not preclude independent development, so long as teams adhere to common standards for everything from testing to incident response.
Non-human identities
AI agents should not be running on an informal API key or a shared login. To know which agent did what and from where, it requires a unique, traceable identity.
Apply the principle of least privilege. Give an agent only what it needs for the task at hand, not free rein over an application. Use managed identities and short-lived credentials rather than static secrets that are easy to copy. And if an agent is working for an employee, let it have delegated access to that person’s permissions, nothing more.
Put in place guardrails based on risk
You would not treat all AI activity the same way. An agent approving a payment or deleting infrastructure warrants closer scrutiny than one simply putting together a summary of internal papers.
A sensible framework might break down as follows:
Low risk involves routine matters like answering questions or organising notes.
Moderate risk covers things like updating non-sensitive records or putting in a ticket.
High risk is reserved for external communications, employment decisions, moving money or revoking access rights.
There are certain high-risk actions that ought to be subject to a maker-checker process, dual authorisation or the like before they are carried out. Then there are other safeguards to consider: controls on credentials and sensitive data, approved destinations, as well as rate, time and spending limits.
But the point is not to do away with autonomy. One wants to introduce some friction where an error might have serious repercussions for the business, be it in terms of reputation, safety, law or finance.
Securing the Tools and Data at an Agent’s Disposal
In the end, an AI agent is no more secure than the systems it is tied to. Enterprises must look at every external service, browser extension, connector, database and API linked to an agent and make sure each has a defined purpose and is limited to what is approved.
Data governance matters just as much. An agent should only pull the information it needs to do its job; confidential material has no place in unsecured logs, public models or with unauthorised third parties. The same policies on encryption, residency, retention and deletion that govern the rest of the organisation should be in effect for an agent’s memory, outputs and audit trail.
One must also be wary of external content. A webpage or email can harbour instructions meant to subvert an agent. To mitigate prompt-injection risks, it is wise to separate trusted from untrusted input, validate tool requests and insist on confirmation for anything of consequence.
