An AI assistant that only drafts text can be wrong, awkward or occasionally unhelpful. An AI agent is different. It can read a shared inbox, search internal documents, create a ticket, update a record or prepare a message for a customer. That is useful right up to the moment an untrusted email, web page or document starts steering the agent somewhere it should not go.

The new attack surface is ordinary content

OWASP places prompt injection at the top of its 2025 list of risks for LLM applications. The basic problem is disarmingly simple: a language model receives instructions and data in the same medium — language. A malicious instruction can be typed directly into a chat, but the more interesting version arrives indirectly, hidden in material the agent is asked to read.

Think of an assistant that summarises supplier emails. The email is supposed to be data. Yet it may contain text designed to influence the assistant: ignore the user’s request, look for a different document, disclose a detail, or favour a particular result. The user may never see the instruction. The agent has still processed it. When that agent also has access to systems and tools, the concern shifts from an odd answer on screen to what happens after the answer.

This is not a prompt-writing problem

It is tempting to respond with a longer system prompt: tell the model to refuse malicious instructions and move on. That is worth doing, but it is not a security boundary. OWASP is explicit that there is no known foolproof prevention for prompt injection. The UK government’s AI cyber security code also names indirect prompt injection among the risks that make AI systems different from ordinary software.

The practical question is not whether an agent can ever be confused. It can. The question is what the surrounding system allows a confused agent to do. A good design assumes untrusted content will reach the model sooner or later, then makes sure that content cannot turn itself into authority. The model may recommend an action; policy and people decide whether it is allowed.

Agent permissions are the real blast-radius control

The NCSC’s guidance on agentic AI makes the point plainly: start small, keep tasks tightly bounded and never give an agent unrestricted access to sensitive data or critical systems. Least privilege is not a checkbox here. It is the difference between a bad summary and a material incident.

An internal knowledge assistant may need read-only access to a small, curated set of procedures. It does not need mailbox-wide search, a long-lived administrator token, the ability to invite external users or a direct route to send messages outside the company. An agent that drafts a reply can stop at a review screen. An agent that changes a payment record, grants access or sends data externally should meet a hard policy gate and a human approval step.

A sensible first deployment for an SMB

Start with a narrow, reversible task: classify support requests, summarise approved documents, prepare a draft response, or extract fields from a known format. Keep the agent read-only where possible. Give it short-lived credentials, a small set of allow-listed tools and logs that record what it read, which tool it tried to use and what was finally approved.

Then test it as an attacker would. Put adversarial instructions into a harmless test email, PDF, knowledge-base article and web page. Check whether the agent changes course, tries a tool call, reaches for data outside its scope or produces an unusual external request. The objective is not to prove that the model is perfect. It is to prove that the business remains safe when the model is imperfect.

The rule worth keeping

Treat every document, email, web page, attachment and tool response as untrusted content — even when it looks routine. Treat the agent’s output as a recommendation, not an instruction to execute. Those two habits turn a vague AI security discussion into decisions that an IT team can implement.

brianda.cloud helps smaller organisations introduce AI in that order: define the task, map the data and permissions, keep actions scoped, add approval gates, and test the workflow before it touches a critical system. The goal is not to make AI slower. It is to make useful automation safe enough to keep.

Sources

This brianda.cloud analysis is based on the public sources listed below. It is practical operational guidance, not a guarantee that any individual AI system is secure.

Sources consulted for this analysis:

  1. LLM01:2025 Prompt InjectionOWASP Gen AI Security Project · 2025
  2. Thinking carefully before adopting agentic AINational Cyber Security Centre (UK) · 2026
  3. Code of Practice for the Cyber Security of AIUK Department for Science, Innovation and Technology · 2025
  4. AI RMF: Generative Artificial Intelligence Profile (NIST AI 600-1)NIST · 2024-07
  5. AI Security Report 2026Check Point Research · 2026-07-14