Agent Security › Risks
AI agents don't just generate information, they take action. That changes what can go wrong. The main risks, in plain English, and the principle behind each one.
AI agents introduce a different kind of security risk because they don't just generate information.
They can take action.
Give an AI agent access to your email, files, CRM, browser, codebase or payment systems and you're giving software the ability to operate inside parts of your business.
That can be enormously useful.
But it also means a mistake is no longer necessarily just a bad answer on a screen.
It could become an email that was actually sent, a record that was actually changed, a file that was actually shared or an action that was actually taken.
Understanding that difference is the starting point for AI agent security.
AI agents are not inherently unsafe.
The risk comes from combining three things: intelligence, access and authority.
An agent with very little access can do very little damage. An agent with broad access but no ability to take consequential actions presents a different level of risk. But an agent that can access multiple business systems, make decisions and take actions autonomously deserves much stronger controls.
The important question therefore isn't "Is this AI agent safe?" It is "What could this agent actually do if something went wrong?"
That might be because the agent misunderstood its task. It might receive malicious instructions. It might be given excessive permissions. One of its connected services might be compromised. Or it might simply pursue a legitimate goal in a way nobody anticipated.
Agent security is about reducing the consequences when those things happen.
One of the simplest agent security problems is also potentially one of the biggest. We give the agent too much access.
Imagine a marketing agent that needs customer information from your CRM to prepare campaign reports. It needs to READ customer records. It probably doesn't need to DELETE customer records. But if the integration provides broad access, the agent may receive both.
The same problem can happen with email, cloud storage, databases, accounting systems, websites, code repositories, customer support platforms and payment systems.
Giving an agent broad permissions is convenient. It also increases the consequences of mistakes or attacks.
Give an agent the minimum permissions required to perform its job. This is known as the principle of least privilege. It isn't new. What's new is applying it properly to autonomous AI systems.
Learn more: AI Agent Permissions
Prompt injection occurs when an AI encounters instructions somewhere other than where its trusted instructions are supposed to come from.
For example, imagine a research agent reading webpages. One webpage contains text telling an AI system to ignore its previous instructions and perform another action.
A human sees strange text on a webpage. An AI system may interpret that text as an instruction.
The same problem could exist inside an email, a document, a PDF, a support ticket, a CRM record, an API response, a message from another agent or a webpage.
This becomes much more serious when the AI has tools. A manipulated chatbot might produce a bad response. A manipulated agent might attempt an action.
Don't rely entirely on preventing malicious instructions from ever reaching an agent. Also restrict what the agent can do if one succeeds.
Learn more: Prompt Injection for AI Agents
Agents need ways to access other systems. That often means API keys, OAuth tokens, service accounts, database credentials, session tokens and application credentials.
Those credentials can become extremely powerful.
If an agent can retrieve or expose the credentials it uses, the problem extends beyond the agent itself. An attacker may be able to use those credentials directly.
Agents therefore shouldn't be treated as convenient places to store secrets. Credentials should be scoped, protected and rotated appropriately, and wherever possible should provide only the access the agent genuinely requires.
Give the agent access to a capability without unnecessarily giving it access to the secret that enables that capability.
An agent may legitimately have access to sensitive information. The risk is what happens next.
Imagine an agent that can read customer records, internal documents, contracts, financial information, support conversations or proprietary company information.
Now imagine it is also able to send email, use external websites, call APIs, upload files or communicate with other agents.
Those permissions can combine. Individually they may appear reasonable. Together they can create a route for sensitive information to leave the organisation.
This is why agent security cannot be assessed one integration at a time. We have to look at the combined authority of the agent.
Ask both: what can this agent access? And: where can this agent send what it accesses?
Not every security incident requires an attacker. Sometimes an agent simply does something nobody intended.
A request such as "clean up these old customer records" may sound straightforward. But what does "old" mean? Should records be archived? Merged? Deleted? Which records must legally or operationally be retained?
A human employee might stop and ask. An autonomous system may interpret the goal and continue.
The more consequential the available actions, the more important it becomes to define where autonomous decision-making ends.
Ambiguous goals should not be combined with irreversible authority.
We build agents to solve problems. If the first approach fails, we often want them to try another. That's useful.
Until the thing stopping the agent isn't a technical problem. It's a security boundary.
Imagine: goal, retrieve information for a report. Problem, expected source isn't accessible. Agent response, search for another source. Perfectly sensible. But what happens if that second source is something the agent isn't supposed to access?
Or: goal, send an update. Problem, normal communication tool fails. Agent response, find another way to send it. Again, that can look like good autonomous reasoning.
The distinction between an obstacle and a boundary cannot always be left to the model.
Important boundaries should be enforced outside the agent wherever possible. The strongest boundary is one the agent cannot negotiate with.
Learn more: AI Agent Guardrails
Autonomy isn't automatically dangerous. But different actions deserve different amounts of autonomy.
There is a significant difference between allowing an agent to autonomously search the web and allowing it to send a customer email. There is an even greater difference between allowing it to summarise an invoice and allowing it to pay one.
Businesses need to decide which actions can happen automatically and which should stop for approval.
Increase human involvement as the consequence of the action increases. The aim isn't to approve every action. It is to put people at the important decision points.
Learn more: Human in the Loop for AI Agents
An agent can potentially complete hundreds or thousands of individual actions while working towards a goal. If something goes wrong, businesses need to reconstruct what happened.
That becomes difficult when activity spans multiple tools, multiple accounts, multiple websites, temporary environments, different APIs and other agents.
A simple chatbot transcript may no longer be enough. Businesses increasingly need an operational record showing things such as systems accessed, tools used, actions attempted, actions completed, permissions granted, approvals received, blocked actions, external destinations and changes made.
If an agent can act, its important actions should be observable.
Learn more: AI Agent Monitoring
Agents increasingly won't work alone. A sales agent might ask a research agent for information. A research agent might ask a data agent to query a database. A customer-service agent might ask a finance agent to check a payment.
That creates a new security question: does authority travel with the request?
Imagine Agent A cannot access payroll. Agent B can. Agent A asks Agent B to retrieve payroll information. Should Agent B comply?
Not simply because another agent asked. The receiving agent needs to understand who originated the request and whether the request is authorised. Otherwise one agent may be able to use another agent's permissions to bypass its own restrictions.
Authority should not automatically travel with a task.
Learn more: AI Agent-to-Agent Security
Who does an AI agent actually represent? The person who created it? The employee currently using it? The organisation? The customer? Another agent?
This sounds philosophical until the agent is allowed to do something consequential.
Imagine an employee asks a company agent to issue a refund. The employee isn't authorised to issue refunds of that size. But the agent itself has access to the refund system. Whose authority applies?
The agent shouldn't magically acquire greater authority than the person delegating the task.
An agent's authority should be traceable to an authorised human or organisational policy.
Agents capable of purchasing goods, paying invoices, booking services or otherwise spending money create another obvious risk.
The important controls aren't simply "can this agent spend money?" They include: how much? Per transaction? Per day? With which suppliers? For which purposes? Does a new supplier require approval? Does a changed transaction value require approval? Can the agent create a new payment destination? Can it approve its own transaction?
Financial authority should be explicit.
Never treat "can pay" as a single permission. Financial authority needs limits.
Some mistakes are easy to fix. Others aren't.
An agent can draft an incorrect email and a person can change it. But once the agent sends that email, the situation changes.
The same applies to publishing information, deleting records, transferring money, deploying production code, revoking access, contacting customers, making contractual commitments or exposing confidential information.
Irreversibility changes the risk.
The harder an action is to undo, the stronger the control before it happens.
An agent's security isn't determined solely by the AI model. It also depends on everything connected to it.
That might include the agent platform, MCP servers, APIs, browser tools, plugins, databases, SaaS applications, authentication providers, automation platforms and custom code.
Every connection expands the system. A secure model connected to an insecure tool does not create a secure agent.
Assess the whole agent system, not just the model.
One particularly important boundary concerns whether an agent can change the controls around itself.
Can it create credentials? Install software? Connect another tool? Change permissions? Modify its own instructions? Create another agent? Disable logging? Change a security policy?
An agent shouldn't normally be able to remove the controls intended to govern it.
Agents should not control their own security boundaries.
Some agents operate for seconds. Others may eventually operate for hours, days or continuously.
The longer an agent runs, the more opportunities there are for conditions to change, permissions to become inappropriate, external information to influence behaviour, costs to accumulate, tasks to drift or unexpected actions to compound.
A permission that made sense at the beginning of a task may not make sense indefinitely.
Authority should have a lifecycle. Consider time-limited credentials, task-limited permissions, maximum run times, spending limits, periodic review and automatic expiry.
One of the least dramatic risks may eventually become one of the most common. Employees can increasingly create agents themselves.
That means organisations may have agents operating that central IT, security or management teams don't know exist.
An employee might connect an agent to their inbox, company files, a CRM, Slack, a browser or another business system. Each decision may seem harmless. Collectively, the organisation may lose visibility over which autonomous systems have access to its data.
You cannot secure agents you don't know exist. This is why businesses increasingly need an AI agent register.
Learn more: What Is an AI Agent Register?
Most agent security risks shouldn't be considered individually.
Imagine an agent with READ access to customer records, plus SEND access to email, plus browser access, plus permission to call external APIs, plus long-running autonomy.
Each permission can have a legitimate reason. Together they create something much more powerful.
That is why the most important security question isn't simply "what permissions does this agent have?" It is "what could this agent accomplish using all of its permissions together?"
That is the agent's effective authority. And it may be much greater than anyone intended.
You don't need to remove all autonomy. You need to control it. A sensible starting point is:
Before deploying an agent, ask four questions.
What can it SEE? Files, emails, customer information, databases, credentials, internal systems.
What can it DO? Send, change, publish, spend, delete, execute.
WHO can it act for? Employee, team, company, customer, another agent.
WHERE can it go? Internal systems, external websites, APIs, third-party tools, other agents.
The more powerful the answer to each question becomes, the stronger your agent security needs to be.
It is easy for discussions about agent security to become discussions about everything that could possibly go wrong. That misses the point.
Businesses are adopting agents because they can do useful work. The objective isn't to remove that capability. It is to make autonomy deliberate.
An agent should know its job. The business should know who owns it. Its access should match its purpose. Its authority should be explicit. Consequential actions should have appropriate controls. Its activity should be visible. And the business should always have a way to stop it.
The principle underneath all of this is simple: capability is not permission.
The more capable AI agents become, the more important that distinction becomes.
Before connecting an agent to business systems, work through our AI Agent Security Checklist. It covers identity, ownership, access, authority, human approval, monitoring, containment and governance. Use the AI Agent Security Checklist
We're building Agent Control for businesses that want a clearer view of the AI agents operating across their organisation. It is being designed to show which agents are active, who owns them, what systems they can access, what authority they have, which actions need approval, and whether they're staying within those boundaries.
Because businesses shouldn't have to choose between useful AI agents and control over what those agents can do.
Agent Control is in build. Leave your email and we will let you know when the early-access version is ready.