The threat landscape

AI agents face unique security challenges that traditional software does not. When you give an AI the ability to act in the world (send emails, write files, execute code, browse the web), you create attack surfaces that did not exist before.

I think of it this way. A chatbot that can only respond with text has limited attack potential. An agent that can access your email, calendar, and file system is a completely different risk profile.

OWASP maintains a widely used list of risks and mitigations for LLM and generative AI applications. The 2025 list is a sensible starting point for agent style systems ^[Source].

Let me walk you through the most critical threats.

OWASP published a separate Agentic Applications Top 10 in December 2025 ^[Source]. This distinction matters. The LLM Top 10 focuses on risks at the model and application layer, such as prompt injection, leakage, and insecure output handling. The Agentic Top 10 focuses on what changes when you give a system tools, memory, delegated actions, and the ability to persist across steps.

I think of it this way. The LLM Top 10 asks "what can go wrong with the brain?" The Agentic Top 10 asks "what can go wrong when you give that brain arms and legs?"

Let me walk through the five most critical risks from this list.

ASI01. Agent Goal Hijack

You might be thinking "this sounds like prompt injection" and you are partly right. Agent goal hijack builds on prompt injection but goes further. A simple chatbot that gets prompt-injected might produce a rude response. An agent that gets its goal hijacked might spend hours systematically exfiltrating data, purchasing products, or modifying files because it has the autonomy to carry out multi-step plans.

The defence here is to constrain the agent's action space. If the CV review agent cannot send emails, the second instruction fails even if the goal hijack succeeds. Limit what agents can do, not just what they are told.

ASI02. Tool Misuse and Exploitation

This is one of the risks that keeps me up at night. The tools themselves are fine. The permissions are correct. The API keys are valid. But the agent's decision about how to use them has been influenced by an attacker.

ASI06. Memory and Context Poisoning

This is far worse for agents than for simple chatbots. A chatbot with a poisoned RAG store might give wrong answers to questions. An agent with poisoned memory might take wrong actions repeatedly over days or weeks, because it "remembers" false facts and uses them to make decisions.

The defence is to treat memory and RAG stores as attack surfaces. Validate what goes in. Version control your knowledge base. Monitor for unexpected changes. And never let agents write to their own long-term memory without oversight.

ASI08. Cascading Failures

Multi-agent systems are becoming more common. You might have an agent that gathers data, another that analyses it, and a third that takes action based on the analysis. If the first agent makes an error, that error flows downstream. Each agent treats the previous agent's output as trusted input. The error grows.

The principle here is that agents in a chain should not blindly trust each other. Build validation checks between agents. Set thresholds for when a human must review. Log every inter-agent handoff so you can trace the failure path.

ASI10. Rogue Agents

This is the scenario that gets the most attention in the press, but it is real. A rogue agent does not announce itself. It continues to produce mostly correct outputs while subtly working against the user's interests. It might be the result of a supply chain attack, a fine-tuning poisoning attack, or emergent behaviour from poorly specified objectives.

Prompt injection is the single biggest security risk facing AI agents today. It is also, unfortunately, one that cannot be completely solved. Let me explain why.

How it works

When you interact with an AI agent, your message gets combined with the system's instructions into a single prompt. The AI has no way to distinguish between "official" instructions from the developer and "unofficial" instructions from you, the user, or from content the agent processes.

Types of prompt injection

1. Direct Prompt Injection

The user directly inputs malicious instructions.

Modern LLMs have some resistance to obvious direct injections, but creative attackers find ways around these defences. The cat-and-mouse game continues.

2. Indirect Prompt Injection

This is more dangerous. Malicious instructions are hidden in content the AI processes, not in the user's direct input.

Why prompt injection is hard to eliminate

In practice, prompt injection is a risk you reduce, not a problem you solve once and forget. The most reliable approach is layered controls and safe failure, rather than a single "magic" detector ^[Source].

1. No clean boundary. LLMs struggle to distinguish between instructions and data. Everything is combined into one prompt. There is no direct equivalent of prepared statements.

2. Probabilistic behaviour. AI behaviour is not deterministic. A defence that works most of the time still fails sometimes. At scale, small failure rates become frequent incidents.

3. Adversarial creativity. Attackers actively adapt. They test prompts until they find a bypass. Jailbreaks often evolve faster than defensive patterns.

What this means for your agents

• Never give AI agents access to truly sensitive operations without human approval

• Assume any AI system can be manipulated given sufficient attacker motivation

• Design systems to fail safely when manipulation occurs

My opinion is that Meta's Rule of Two is one of the clearest mental models we have for agent security. Before you build, ask yourself: does this agent read untrusted content, change things in the real world, and use tools? If the answer is yes to all three, you need to rethink the design or add very strong guardrails.

This hands-on practice tool helps you understand prompt injection attack patterns and how to defend against them. Study attack examples, test your own inputs for suspicious patterns, and learn about defence in depth strategies.

Your AI agent does not exist in isolation. It depends on dozens, sometimes hundreds, of external components.

Supply chain problems are common in package ecosystems. Typosquatting, compromised maintainers, and malicious updates happen in every language. The safest default is to treat anything you install as potentially hostile, then design controls that limit the blast radius.

Protection measures

1. Pin dependency versions to specific releases you have audited

2. Use vulnerability scanning tools like npm audit or pip-audit

3. Verify package authenticity through checksums and signatures

4. Maintain Software Bills of Materials (SBOM) for all deployments

# Good: Pinned versions in requirements.txt
langchain==0.1.5
ollama==0.1.7
requests==2.31.0

# Bad: Unpinned versions (dangerous!)
langchain
ollama
requests

Proportionate Security Approach

For Personal/Local Use:

• ✅ Use local models (Ollama)

• ✅ Keep software updated

• ✅ Basic input validation

• ⚠️ Do not connect to sensitive accounts

For Team/Business Use:

• ✅ All of the above

• ✅ Role-based access control

• ✅ Audit logging

• ✅ Regular security reviews

• ⚠️ Limit external data access

For Public Deployment:

• ✅ All of the above

• ✅ Professional security audit

• ✅ Continuous monitoring

• ✅ Incident response plan

• ✅ Insurance/liability coverage

• ✅ Human-in-the-loop for critical actions