Agents Under Siege: How LLM Workflows Invite a New Breed of Cyber Threats

TL;DR for operators

A support agent reads a customer email. It checks a CRM record. It calls a refund API. It writes a note into long-term memory. It asks another agent to verify policy. Somewhere in that chain, a malicious instruction hides inside a message, document, issue tracker entry, retrieved snippet, schema, or tool response. The model does not need to become “evil”. It only needs to be helpful in the wrong direction.

That is the useful message from Mohamed Amine Ferrag and colleagues’ survey, From Prompt Injections to Protocol Exploits: Threats in LLM-Powered AI Agents Workflows.¹ The paper’s real contribution is not another dramatic list of prompt attacks. We already have enough of those. The contribution is an end-to-end threat model for LLM-agent ecosystems: input manipulation, model compromise, system and privacy attacks, and protocol-level vulnerabilities across host-to-tool and agent-to-agent communication.

For operators, the practical correction is simple: do not treat agent security as a chatbot moderation problem. Treat it as workflow security. Every agentic deployment has multiple trust boundaries: user input, retrieved content, tool schemas, execution sandboxes, credentials, memory banks, plugin adapters, inter-agent messages, and approval gates. Any one of them can become the place where “please summarise this” quietly turns into “please exfiltrate that”.

The paper is a survey, not a new controlled benchmark. Its attack success rates come from different studies, models, datasets, and defences. They are useful for understanding feasibility and severity, not for making neat bar charts in a board deck. Please spare everyone that particular theatre.

The business answer is not “ban agents”. It is to stop pretending that an LLM with tool access is just a text box with ambitions. Production-grade agent security needs least-privilege tool permissions, structured schema validation, credential isolation, sandboxed execution, provenance logs, memory integrity checks, runtime anomaly detection, and stronger verification for MCP and A2A-style integrations.

The first failure is not the model. It is the handoff.

Most AI security conversations still begin in the prompt. That is understandable. The prompt is visible, easy to quote, and wonderfully theatrical. “Ignore previous instructions” has become cybersecurity’s most overused party trick.

But LLM agents are not merely answering questions. They are reading files, searching repositories, querying databases, booking meetings, opening tickets, invoking APIs, updating memories, and delegating tasks to other agents. The moment the model receives tool access, the security object changes. You are no longer defending a conversation. You are defending a chain of actions.

The paper frames this chain across four broad threat domains:

The mechanism is more important than the labels. A modern agent is a sequence of transformations: input becomes context; context becomes a plan; a plan becomes a tool call; a tool call returns observations; observations update memory; memory influences the next plan; the next plan may be delegated to another agent. Each transformation is a place where trust can be smuggled in, lost, or laundered.

That is why the paper’s framing is useful. It does not stop at “the model can be tricked”. It asks a more operational question: where does the trick acquire authority?

Prompt injection becomes serious when it receives a tool budget

Input manipulation is the easiest category to understand and the easiest to underestimate. Direct prompt injection asks the model to override instructions. Prompt-to-SQL injection exploits systems where natural language is translated into database queries. Indirect prompt injection hides adversarial instructions inside content the agent later retrieves. Multimodal variants embed the attack in images or audio. Jailbreaks target refusal mechanisms. Evasion attacks exploit token-level or representation-level weaknesses.

As a chatbot problem, this is annoying. As an agent problem, it is operationally dangerous.

The difference is authority. A normal chatbot can produce a bad answer. An agent can turn that bad interpretation into an API call, a database query, a code change, a purchase, an email, or a file operation. The prompt does not need to “win” philosophically. It only needs to redirect the workflow.

The paper’s examples make this clear. Prompt-to-SQL attacks matter because the model sits between human language and a database. If unsanitised user input is passed into generated SQL, the LLM becomes the friendly receptionist for a very old class of injection attack. Same old burglary, new front desk.

The Toxic Agent Flow example is more agent-native. The attack described in the survey involves malicious instructions placed in a GitHub issue that an MCP-connected agent fetches and processes. The agent is then manipulated into pulling private repository data into context and leaking it through an open pull request. The point is not merely that the prompt was hostile. The point is that the agent treated untrusted external content as operational instruction while holding access to private resources.

That is the pattern operators should remember:

1. The attacker plants instructions in a place the agent is expected to read.
2. The agent retrieves that content during a legitimate task.
3. The content contaminates the agent’s context.
4. The agent uses its existing permissions to perform the attacker’s action.
5. The resulting failure looks like normal automation until someone checks the blast radius.

Traditional prompt filtering helps at step one. It does much less at steps three through five. This is why alignment is not enough. A well-aligned model can still be placed inside a badly aligned workflow.

Persistent compromise is worse because it waits politely

Input attacks are often immediate. Model compromise is more patient.

The paper’s second major category covers prompt-level backdoors, model-parameter backdoors, composite backdoors, data poisoning, retrieval poisoning, federated poisoning, and memory poisoning. These attacks are not always about forcing a visible mistake today. They can implant conditional behaviour that activates later, under specific inputs, observations, or internal states.

That matters because agent systems increasingly rely on reusable components: prompts-as-a-service, fine-tuned models, third-party agents, shared retrieval stores, memory banks, and long-running task histories. Each improves productivity. Each also creates a supply-chain surface. Naturally, the industry discovered convenience and then looked surprised when convenience had permissions.

Composite backdoors are especially instructive. The paper cites studies where triggers can be distributed across multiple prompt elements rather than placed in one obvious token. This matters in multi-step agents because the “complete trigger” may not exist in the user’s first message. It may be assembled across tool outputs, retrieved snippets, memory entries, and inter-agent messages. Detection becomes harder because no single fragment looks damning.

Memory poisoning is even more awkward. Long-term memory is sold as the solution to context continuity: the agent remembers preferences, prior tasks, client details, open commitments, and operational state. But a memory bank is also a writable influence surface. If malicious records enter memory and are later retrieved as trusted context, the attacker no longer needs to be present. The agent carries the compromise forward on their behalf. Outsourcing persistence to the victim system is, admittedly, efficient.

For businesses, this changes the control question. It is not enough to ask whether the model is safe at inference time. Ask whether the agent’s memory, retrieval corpus, fine-tuning data, prompt templates, and tool observations are auditable, reversible, and provenance-tagged.

A practical checklist looks like this:

The phrase “memory integrity” will sound boring until the first compromised agent keeps remembering the attacker’s preference as company policy.

Privacy attacks do not need the model to say the secret aloud

System and privacy attacks in the paper widen the lens again. Here, the adversary may infer sensitive information from outputs, timing, packet sizes, retrieval behaviour, federated updates, or multi-agent interaction patterns. The model does not need to print a password for privacy to fail.

The survey includes speculative decoding side-channel attacks, membership inference against RAG systems, datastore leakage, federated local model poisoning, contagious recursive blocking, and personalised social-engineering simulations. These belong together because they attack the surrounding system rather than a single prompt.

The RAG examples are particularly relevant for enterprises. Retrieval-augmented generation is often presented as the grown-up alternative to hallucination: connect the model to approved documents, generate grounded answers, and everyone can finally stop arguing with the chatbot. But retrieval adds a new confidentiality problem. If the model’s answer reveals whether a document, record, or phrase exists in the external datastore, the system can leak membership information. If prompts can induce verbatim extraction, the datastore becomes less like a library and more like a politely indexed breach.

Side channels add another unpleasant reminder: encryption is not magic dust. The survey discusses attacks where packet timing and size variations can reveal information about token generation behaviour in optimised LLM services. That does not mean every deployment is doomed. It does mean performance optimisation and privacy engineering are now entangled. Faster inference, streaming, speculative decoding, and multi-agent chatter may all alter what metadata is exposed.

For an operator, the practical question is not “does the agent reveal secrets?” It is broader:

• Can an attacker infer whether a sensitive item exists?
• Can they reconstruct fragments through repeated queries?
• Can they use timing or traffic patterns to classify private interactions?
• Can they poison one participant in a federated or multi-agent setting and affect the whole workflow?
• Can a benign-looking instruction create recursive task loops that burn compute or block collaboration?

The paper’s answer is not a single defence. It is defence by architecture: isolation, minimisation, monitoring, and explicit trust boundaries.

MCP and A2A move the battlefield into protocol semantics

The most useful part of the paper is its insistence that protocol vulnerabilities are not ordinary networking bugs wearing AI merchandise. They arise from how agents package context, authenticate actions, discover capabilities, delegate tasks, and interpret structured messages.

MCP is described as the vertical bridge: an agent connects to tools, files, databases, APIs, and services through a standard interface. A2A is the horizontal bridge: agents discover each other, negotiate tasks, exchange artefacts, and coordinate work. That architecture is attractive because it reduces bespoke integration work. It is also dangerous for exactly the same reason. Standardised bridges scale both productivity and mistakes.

The paper’s protocol threat model highlights several recurring classes:

This is where the “prompt injection” framing becomes too small. A malicious instruction is only one part of the exploit. The real failure is often semantic: the protocol cannot distinguish trusted instructions from untrusted content, fresh authority from replayed authority, advertised capability from verified capability, or a delegated task from a laundering operation.

The survey’s CVE cross-mapping is useful here. It connects the taxonomy to real-world vulnerabilities involving LangChain components, Hugging Face SmolAgents, OpenAI Codex CLI, Anthropic MCP-Remote, and MCP Inspector. The examples span indirect prompt injection, SSRF, XML external entity exposure, path traversal, XPath injection, sandbox escape, remote command execution, and missing authentication. These are not all “LLM vulnerabilities” in the narrow sense. That is precisely the point. Agentic AI inherits normal software security problems, then adds language-mediated ambiguity on top. A generous little upgrade.

How to read the paper’s evidence without abusing it

The paper includes many reported attack success rates from the underlying literature. Some are striking: adaptive indirect prompt injection bypassing eight defences with success rates above 50%; compositional jailbreak attacks reporting 95% or higher success on popular models in a cited study; active environment injection reaching up to 93% in AndroidWorld; composite backdoor results reporting 100% attack success in a specific LLaMA-7B Emotion dataset setting with 3% poisoned samples and low false-trigger rate; retrieval poisoning studies reporting high attack success after injecting only a handful of malicious texts.

These numbers are useful. They are not interchangeable.

The survey itself notes that attack success rates are reported from original publications and are not directly comparable because they vary by model architecture, dataset, experimental design, and defence mechanism. That caveat should not be buried in a footnote nobody reads. It changes how the paper should be used.

This distinction matters for business planning. A CISO should not read the paper and ask, “Are we facing a 93% attack success rate?” That is the wrong question, wearing an impressive number. The better question is: “Which of these mechanisms exist in our architecture, and where do they cross a permission boundary?”

The business value is prioritisation, not panic

The paper’s practical value is that it helps teams prioritise controls by mechanism. Security budgets are finite. Threat lists are not. A taxonomy earns its keep only if it helps decide what to do first.

The survey’s feasibility analysis is a good starting point. Input manipulation typically requires low privilege and is highly feasible where public inputs and exposed toolchains exist. Protocol vulnerabilities may require low to medium access but can hit integration boundaries with high impact. Model compromise usually requires deeper access to training, fine-tuning, prompt supply chains, or data pipelines. System and privacy attacks often require runtime, network, federated, or shared-environment access.

This maps neatly to rollout maturity.

Early agent pilots should prioritise the controls that stop low-privilege, high-feasibility attacks:

• Treat all external content as data, never as instruction.
• Apply strict schema validation before tool calls.
• Give each tool the minimum permission needed for the task.
• Require explicit approval for irreversible or sensitive operations.
• Separate read and write capabilities.
• Log every tool call with input, output, authority, and provenance.

Scaling deployments should add controls for persistence and delegation:

• Version and sign prompt templates.
• Track retrieval source provenance.
• Restrict memory writes and support rollback.
• Use per-agent credentials rather than shared service accounts.
• Validate agent identity before delegation.
• Rate-limit recursive task creation.
• Monitor semantic anomalies in tool responses and context transitions.

Enterprise-grade deployments need protocol and governance controls:

• Use short-lived tokens, nonce checks, and mutual authentication.
• Bind tokens to audience, scope, and task.
• Sign discovery metadata and Agent Cards.
• Sandbox plugin and tool execution.
• Audit dependencies and SDK versions.
• Maintain cryptographically verifiable logs for sensitive workflows.
• Red-team with adaptive, indirect, multimodal, and cross-agent attacks, not just toy prompt injections.

None of this is glamorous. That is usually how one recognises real security work.

What Cognaptus infers beyond the paper

The paper directly provides a survey framework, taxonomy, formal threat models, attack examples, feasibility discussion, defence review, and CVE mapping. It does not provide a production deployment study or a unified benchmark across all attack classes.

Cognaptus infers three operational lessons from that evidence.

First, agentic AI security should be owned jointly by AI engineering, application security, identity and access management, data governance, and platform operations. It does not fit cleanly inside “model risk” or “cybersecurity awareness”. The failure path crosses both.

Second, procurement needs to change. Buying or adopting an agent framework should require questions about tool permissioning, schema enforcement, credential handling, memory controls, provenance logging, sandboxing, and protocol verification. A vendor saying “we have guardrails” is not an answer. It is a scented candle.

Third, ROI should be framed around avoided blast radius, not abstract safety. The cost of layered controls is easier to justify when compared with leaked repositories, corrupted records, unauthorised transactions, poisoned memories, runaway API usage, or an agent quietly sending private context to the wrong collaborator.

The boundary: this is a map, not a measuring instrument

The main limitation is methodological. This paper synthesises a broad and fast-moving literature. It is intentionally wide. That breadth is valuable, but it means the paper should not be treated as a single empirical test.

The reported attack success rates come from different papers with different models, datasets, threat assumptions, defences, and evaluation protocols. Some results are from controlled experiments. Some are proof-of-concept demonstrations. Some are cross-mapped to public vulnerabilities. The survey’s role is to organise and interpret this landscape, not to rank every attack by a common metric.

There is also a timing issue. Protocols such as MCP and A2A are evolving quickly. SDKs, defaults, authentication practices, and deployment patterns may change faster than academic taxonomies. That does not weaken the paper’s core insight. If anything, it strengthens it: when the integration layer is moving quickly, security assumptions rot quickly too.

Finally, the taxonomy is not a substitute for architecture review. A company cannot say it has “covered input manipulation” in the abstract. It must inspect where untrusted inputs enter, how they are transformed, which tools they can influence, which credentials are available, what memory can be written, and where agent outputs are trusted by downstream systems.

Security lives in the edges. Agents create more edges.

The real risk is the obedient workflow

The most dangerous agent is not necessarily the one that hallucinates. It is the one that obeys too smoothly.

It reads the malicious issue. It retrieves the poisoned document. It trusts the stale memory. It invokes the over-permissioned tool. It delegates to the spoofed agent. It writes the wrong state. It logs everything beautifully, assuming anyone remembers to look.

Ferrag and colleagues’ survey gives the right mental model for this problem. Agent security is not prompt safety plus vibes. It is end-to-end control over how language becomes action.

Businesses deploying LLM workflows should therefore stop asking only whether the model can resist hostile text. Ask whether the workflow can resist hostile context, hostile tools, hostile memory, hostile protocols, and hostile delegation. That is the difference between a chatbot with a filter and an automation system with a security architecture.

The former is a demo. The latter is what production was supposed to mean.

Cognaptus: Automate the Present, Incubate the Future.