Blog

Prompt injection in AI agents: why architecture matters more than the model

Prompt injection in AI agents is an architecture and compliance problem. Why separated privileges, controlled memory and visible logs are needed.

July 24, 2026 · Victor Angelier

Prompt injection is increasingly described as a problem with the language model itself. Yet the recent incidents and analyses from the spring of 2026 paint a different picture: it is about the architecture within which AI agents operate. When an agent has access to internal systems, sensitive files or external tools, the risk shifts from 'a wrong answer' to concrete harm: data breaches, unwanted actions and untraceable errors. Anyone deploying AI agents in the vicinity of confidential information therefore cannot view prompt injection separately from security and compliance.

From a model problem to a structural vulnerability

The post-mortem by Clawvard School describes how incidents in May 2026 — including the so-called BadHost CVE and a Copilot-like attack — turned AI agents with access to sensitive data into practical attack targets. The core of their analysis: effective defence requires supply-chain hygiene, sandboxing of tools, marking untrusted content and filtering output. Relying on the model alone is not enough.

Zylos AI documents how prompt injection and tool hijacking spread through an agent's memory and tools. Their recommendation is a layered defence stack: least-privilege credentials, execution in a sandbox and integrity checks on long-term memory. The idea is that an attack which passes one layer does not automatically gain control over the entire agent.

These technical insights are underpinned by peer-reviewed research. The survey in Frontiers in Computer Science maps data breaches and privacy failures in agentic AI and recommends architectural measures: memory isolation, regulated persistence, secure context management, strict API scoping, differential privacy during training and continuous red-teaming specifically aimed at prompt injection. The message is clear: secure deployment of AI agents around sensitive data is fundamentally a question of architecture and verification.

Prompt injection as a compliance problem

The security question cannot be viewed separately from regulation. AI Dev Day India treats prompt injection as the core attack class for agents that process untrusted content, and explicitly links it to the Article 15 robustness obligations of the EU AI Act for high-risk systems. Organisations deploying such systems must therefore treat prompt injection as both a security and a compliance issue.

Help Net Security adds recent incident data to this: prompt injection still drives most documented agentic AI security failures in 2026. The article places these incidents against the backdrop of increasingly stringent reporting regimes, including DORA, NIS2, the RAISE Act in New York and California SB 53. The consequence is twofold: organisations must not only counter prompt injection, but also be able to detect, reconstruct and report attacks in good time.

What this means in practice

A consistent picture emerges from the sources of measures that together form a 'harness' around an AI agent:

  • Separated privileges according to the least-privilege principle, with a clear distinction between read and write actions.
  • Sandboxed execution so that tool use remains isolated from the rest of the environment.
  • Controlled memory architecture with integrity checks and isolation, to limit injection via stored context.
  • Output filtering and marking untrusted content, so that external data is not treated as an instruction.
  • Traceable session logging for detection, reconstruction and reporting.
  • Continuous red-teaming aimed at prompt injection, as the Frontiers survey emphasises.

For professionals who work with confidential files — lawyers, notaries, company doctors, journalists, researchers and compliance teams — it is above all the interplay between security and demonstrability that is relevant. Not only 'is the agent secure', but also 'can I show what happened'.

Where a verification layer can help

This shift touches on the field of a privacy-focused verification console such as I am Vera. Vera is not a chatbot and not a language model of its own, but a verification layer that makes control steps visible. In the Semantic Privacy Shield, documents are anonymised on EU infrastructure before content is sent to the selected AI models; the workflow is designed to forward only anonymised content, and if a privacy check fails, nothing is forwarded. This is consistent with the sources' principle that untrusted content should not reach a model or tool unfiltered.

By making verification steps and multi-model checks visible, such an approach can help to assess AI answers more critically and can give greater insight into what has happened to a document. Working with documents can moreover take place within the same secure environment via Vera Office. Importantly, this does not ensure correctness, does not remove the risk of hallucinations and does not make anonymisation perfect. The professional final judgement always remains with the user.

The common thread in the recent analyses is clear. Prompt injection is not a bug that disappears with a single patch, but a structural characteristic of agents that process untrusted content. The defence lies in the architecture: tightly separated privileges, controlled memory, visible logs and explicit tests. Anyone deploying AI agents around sensitive information would do well to make those measures demonstrable — both for the security of data and for compliance with emerging AI and incident-reporting obligations.

← All articles