An AI agent that can read your inbox, update customer records or execute code needs more than a well-written set of instructions. It needs clear limits on what it can access, change and share.
Connecting AI to business systems creates opportunities to reduce manual work and accelerate decisions. It also creates routes for attackers to manipulate those decisions, steal information or trigger actions through legitimate tools.
The OWASP Top 10 for Agentic Applications provides a framework for understanding and assessing AI agent security risks. Drawing on this guidance, we explore ten key threats and the practical steps organisations can take to address them.
An AI agent is a software system that uses artificial intelligence to carry out tasks on behalf of a user or organisation. It can interpret a goal, decide which steps to take and use connected tools to complete them, with varying levels of human oversight.
An agent connected to your inbox, customer database or cloud environment needs clear limits on what it can access, change and share. Without those controls, a malicious instruction or incorrect decision could lead to exposed data, unauthorised transactions or disrupted operations.
AI agent security is the practice of protecting AI systems that can plan tasks, use tools and take actions on behalf of users or organisations. It covers the agent itself, its connected applications, its access permissions and the information it processes.
A chatbot limited to answering questions has a different risk profile from an agent authorised to send emails, change configurations or approve transactions. When AI can act, an incorrect or manipulated response can become a business incident.
Prompt injection occurs when malicious instructions influence an AI system’s behaviour. With agents, those instructions can arrive indirectly through a webpage, email, document or tool response encountered during a legitimate task.
For example, an agent reviewing a supplier document could encounter instructions telling it to retrieve confidential information and send it elsewhere. The attacker is attempting to turn material the agent should analyse into commands it follows.
This is an ongoing security challenge, and model safeguards alone do not remove the risk.
How to reduce the risk: Treat external content as untrusted. Restrict which tools and destinations the agent can use, screen suspicious inputs and require approval for sensitive actions. Enforce access restrictions outside the language model so that manipulated instructions cannot simply override them.
An agent becomes more dangerous when its permissions exceed its purpose. A reporting assistant might need to read financial records, but have no reason to edit them or initiate payments.
The same principle applies to autonomy. Even an authorised action may need human approval if it involves deleting records, changing security settings or making an external commitment.
OWASP identifies excessive functionality, permissions and autonomy as underlying causes of excessive agency.
How to reduce the risk: Define the minimum access needed for each task. Separate read and write capabilities, limit available functions and introduce approval gates proportionate to the potential impact. Review permissions whenever an agent’s responsibilities change.
An AI agent may operate through service accounts, API keys, access tokens or permissions delegated by a user. If these credentials are stolen or misused, an attacker may gain access to the same connected systems.
Shared identities also weaken accountability. If several agents use one powerful account, it becomes harder to identify which agent performed an action, who authorised it and which access needs revoking.
NIST’s work on AI agent identity and authorisation reflects the importance of applying identity controls to these systems.
How to reduce the risk: Give agents distinct, traceable identities where supported, with named owners and defined lifecycles. Use short-lived, narrowly scoped credentials and secure secrets management. Preserve the link between an agent’s actions and the user or process that authorised them.
Agents can bring together information from multiple business systems. Without appropriate restrictions, they may expose personal data, confidential documents or commercially sensitive information through responses, messages, logs or connected services.
Consider a customer service agent that retrieves an internal account note and includes it in an external reply. The disclosure may result from poor access controls or an incorrect decision, without an attacker being involved. Sensitive information disclosure is a recognised risk in LLM applications.
How to reduce the risk: Apply data classification and access controls before information reaches the agent. Limit retrieval to the relevant user, customer and task. Use data loss prevention controls, restrict outbound destinations and check how providers and integrations handle retention and logging.
Agents depend on components beyond the underlying model, including software libraries, plugins, connectors and external services. A vulnerable or compromised dependency can undermine an otherwise well-controlled deployment.
Model Context Protocol (MCP) servers, where used to connect agents to tools and data, also belong within this assessment. A convenient integration still needs scrutiny of its permissions, behaviour and maintenance.
AI supply chain security therefore needs to cover the components surrounding the model as well as the model itself.
How to reduce the risk: Maintain an inventory of approved dependencies and integrations. Verify their origin, assess requested permissions, monitor vulnerabilities and review updates. Test changes before deployment, particularly where an integration can execute commands or access sensitive information.
An agent’s decisions depend on the information it receives and retains. Attackers may tamper with knowledge sources or stored memory so that misleading content influences later tasks.
For example, a false instruction saved as a trusted preference could repeatedly redirect an agent’s behaviour. Unlike a single malicious prompt, persistent contamination may affect subsequent sessions. OWASP includes memory and context poisoning among agentic security risks.
How to reduce the risk: Control who can update knowledge sources and agent memory. Record where information originated, retain version history and require validation before untrusted content becomes persistent guidance. Make it possible to remove contaminated records and restore a known-good state.
Agents that generate code, database queries or commands introduce risk when their outputs pass directly into execution.
An apparently reasonable request can produce an unsafe command or an incorrectly scoped query. Malicious inputs can also exploit weak validation to reach downstream systems. OWASP’s guidance on improper output handling describes how insufficient scrutiny can enable injection attacks and code execution.
How to reduce the risk: Treat generated output as untrusted input. Validate tool arguments, use parameterised database queries and restrict execution to isolated environments. Prefer narrowly defined operations over unrestricted shell access, and keep production secrets outside execution environments unless explicitly required.
When several agents collaborate, a mistake or compromise in one can influence others. A research agent might provide an incorrect conclusion that another agent accepts as authority to update a system.
This creates a risk of errors spreading across a workflow, particularly where agents share memory, tools or broad permissions. A successful handover does not establish that the underlying information or requested action is trustworthy.
How to reduce the risk: Authenticate agent communications and validate requests at each handover. Preserve information about sources and authorisation. Give each agent only the access needed for its role, and introduce checkpoints before a chain of decisions reaches a high-impact action.
Agent workflows may repeatedly call models, query services or create additional tasks. Poor stopping conditions, unexpected inputs or deliberate abuse can drive excessive consumption.
The result can include escalating costs, exhausted API quotas and reduced availability for other users. OWASP describes the broader risk of uncontrolled model resource use as unbounded consumption.
How to reduce the risk: Set enforceable limits on spending, runtime, retries, concurrent tasks and tool calls. Alert on unusual activity and stop workflows that exceed agreed thresholds. Test failure conditions, including unavailable services and repeated unsuccessful actions, before expanding deployment.
An agent can cause harm without being compromised. It may misunderstand a request, work from incomplete information or choose an inappropriate action. Excessive trust turns those failures into operational risk.
Human approval helps only when the reviewer can see what will happen. A vague confirmation message is inadequate for a payment, access change or bulk deletion. Monitoring is equally important: teams need to establish what the agent actually did.
How to reduce the risk: Show reviewers the proposed action, affected systems and relevant evidence. Log tool calls, approvals and outcomes, while protecting sensitive log content. Give responders tested procedures to suspend agents, revoke credentials, preserve evidence and reverse changes where possible.
Start with the agents that combine sensitive data access, powerful tools and the ability to act without approval. An assistant answering questions from public documents presents a different level of exposure from an agent changing production systems.
For each deployment, establish:
Use these answers to prioritise testing and remediation. Reassess whenever models, tools, permissions or workflows change, because the scope of an agent’s access can expand long after its initial approval.
Every new connection increases what an agent can accomplish. It can also increase the consequences of a mistake or compromise. Security decisions need to keep pace with that expanding access.
For businesses adopting agentic AI, the priorities are clear: govern agent identities, protect sensitive data, constrain actions and make activity visible to the people responsible for defending the organisation.
Speak to Integrity360 about securing AI adoption across identity, data and business operations.
What Is the Difference Between AI Security and AI Agent Security?
AI security covers the protection of AI models, data and applications. AI agent security adds particular emphasis to systems that use tools and take actions, including their permissions, delegated authority, connections and ability to affect other systems.
Can Prompt Injection Be Fully Prevented?
Businesses should not assume that prompt injection can be eliminated. Defences can reduce successful attacks, but deployments should also limit what an agent can do if manipulation succeeds. Restricting access and controlling sensitive actions helps contain the potential damage.
Why Is Identity Management Important for AI Agents?
Identity management helps establish which agent is acting, what it can access and who is responsible for it. Distinct identities, limited permissions and revocable credentials support accountability and make it easier to contain compromised or malfunctioning agents.
Do AI Agents Need Human Approval for Every Action?
Approval should reflect the consequences of an action. Routine, low-impact tasks may operate within predefined limits. Payments, sensitive disclosures, destructive changes and privileged operations warrant stronger checks. Those checks should be enforced by the application or connected system.
What Should Businesses Do Before Deploying an AI Agent?
Define its purpose, assign an owner, map its data and system access, and set permission limits. Test the complete workflow against misuse and failure scenarios. Establish monitoring, approval requirements and a practical way to stop the agent before granting access to live business systems.