AI agents that autonomously call tools, read internal documents and communicate with external systems have become a fixture in many organisations in 2026. That same autonomy also makes them attractive as an attack target. A series of recent publications describes how prompt injection can turn an agent with internal access into what effectively amounts to an insider threat: a privileged identity that follows instructions from an untrusted source. For professionals working with confidential or high-risk data, the question therefore shifts from “what can the AI do” to “what can a misused AI do, and who can verify that afterwards?”
From text manipulation to access to internal systems
Prompt injection is the insertion of malicious instructions into the input of an AI model, for example hidden in a document, email or web page that the agent processes. As long as a model only generates text, the impact remains limited. However, once an agent is allowed to read files, call APIs or communicate externally, a successful injection can lead to unauthorised access and data leaks.
The arXiv preprint Lessons from Penetration Tests on Large-Scale Agent-Based Systems documents this on the basis of penetration tests against real agentic systems. The researchers show that agents with broad tool and data access can be compromised through prompt injection and related input manipulation, resulting in unauthorised file and API access and data exfiltration. Their conclusion is sober: sandboxing, fine-grained access control, input and output sanitisation, logging and mandatory access control at system level are needed to limit the blast radius when an agent can reach internal systems.
Treat the agent as a privileged identity
The Cloud Security Alliance goes a step further in Agents in the Wire: AI Agents as Enterprise Insider Threats and explicitly positions the agent as a potential insider. According to the CSA, an agent that is allowed to read sensitive files, access internal APIs and communicate externally calls for security controls comparable to those of a privileged human user — plus additional safeguards, precisely because the agent is susceptible to prompt injection.
In practice, this means that organisations should include agents in their existing identity and access management practice: least privilege, auditable access and incident response are part of that. The premise is that the agent is not a separate, unregulated category, but an identity that is managed just as strictly as other accounts with access to confidential information.
Architecture that limits damage
The most reliable defence is architectural, not merely a better prompt. That is the common thread in TeqVolt's 2026 Defense Playbook. The advice: separate “reader” agents that process untrusted content from “privileged” agents that may reach sensitive data. Add to this strict egress controls, approval gates for dangerous operations and output validation before side effects occur. Circuit breakers and allowlists ensure that a successful injection does not automatically result in data leakage or system compromise.
TechStories Labs describes similar building blocks in its overview for 2026: sandboxing, semantic filtering of retrieved content, output monitoring and strict privilege minimisation. The core message is that modern agent architectures must separate untrusted input from sensitive tools and data, and that input and output verification has by now become a basic requirement for agents with internal access.
This approach aligns with formal risk frameworks. PromptHalo's research note on NIST guidance summarises that it is advisable to constrain model behaviour, enforce least-privilege access, separate and label untrusted external content before it enters the context, and require human approval for high-risk actions. This recognises prompt injection as a distinct AI security category, not as a peripheral phenomenon.
What this means for working with confidential data
For lawyers, notaries, occupational physicians, journalists, researchers and compliance teams, a consistent picture emerges from these sources. Two principles are central: untrusted content must not reach sensitive data and tools unfiltered, and every meaningful AI action must be verifiable afterwards. Verification, access control and traceable logs are therefore not a compliance formality, but a security requirement.
At I am Vera, we translate this same principle into everyday practice. Vera is not a chatbot and not a language model of its own, but a verification console that makes control steps visible. The Semantic Privacy Shield carries out pre-processing and anonymisation on EU infrastructure; the workflow is designed to send only anonymised content to the selected AI models. If the privacy check does not pass, nothing is forwarded. This aligns with the idea from the NIST summary of separating untrusted content before it reaches the context.
In addition, through multi-model verification and structured logging, Vera enables greater visibility into what has happened with a query and an answer. This does not remove the possibility of hallucinations and offers no assurance about correctness or truth, but it supports the user in following and assessing verification steps. Documents can be viewed and edited within the same secure environment via Vera Office, with the professional remaining at the helm.
The lesson from 2026 is clear: as agents gain more internal access, the emphasis shifts from clever answers to bounded, verifiable actions. The professional's final judgement always remains with the person working with the data.