Securing AI agents in the enterprise: prompt injection, data leaks and shadow AI

Up to date as of October 25, 2026. Attacks and frameworks are evolving very quickly in this area. This article will be expanded as new publications come out.

Not long ago, generative AI in the enterprise boiled down to a chat assistant that answered questions. Today, agents read inboxes, summarize documents, query knowledge bases, call APIs, create tickets or modify code. Every piece of content they read becomes a possible way in, and every permission they are granted, a lever for an attacker.

From assistant to agent: what changes

An assistant answers; an agent acts. It chains steps together, uses tools, keeps a memory and can talk to other agents. Standardized integration protocols now make it easy to connect an agent to dozens of tools and data sources.

The underlying problem lies in the very nature of language models: they cannot reliably tell an instruction from data. A text they read can therefore be interpreted as an order.

The main attacks

Indirect prompt injection

The attacker does not need access to the agent: it is enough to place instructions in content the agent will read, such as an email, a web page, a shared document or a log entry. The agent may then disclose information, change its behavior or trigger actions.

This is not theoretical. In June 2025, Microsoft fixed EchoLeak (CVE-2025-32711, CVSS score 9.3), a flaw in Microsoft 365 Copilot: a single booby-trapped email could lead the assistant to exfiltrate the user’s data, without any click on their part. No malicious exploitation was reported.

Excessive permissions

The more rights an agent has, the more serious a successful manipulation becomes. An agent that can send emails, change access rights or approve payments becomes a formidable attack vector if it is hijacked.

Leakage of sensitive data

An agent connected to many sources can expose information the user is not entitled to see, for example if a knowledge base was indexed without carrying over the access rights of the original documents. The prompts and answers themselves, if retained by a provider, can also contain confidential data.

Poisoning of memory and knowledge

A booby-trapped document added to a knowledge base, or malicious information stored in an agent’s memory, can influence its answers and actions for a long time, well after the initial attack.

The supply chain

Extensions, connectors, tool servers, downloaded models: every third-party component added to an agent widens the attack surface, just like a software library.

Shadow AI, an underestimated risk

Even before official agents, there are uncontrolled uses: employees who paste confidential documents into a public AI service, install browser extensions with broad access or use their personal accounts. These uses, often in good faith, escape all governance.

Banning them is not enough. You need to measure them (proxy and DNS logs, CASB-type solutions), offer an approved alternative and train teams in the right habits.

The frameworks to get organized

OWASP: the OWASP GenAI Security Project publishes a Top 10 of risks for applications built on LLMs (2026 edition) and, since December 2025, a Top 10 dedicated to agentic applications. It covers, among others, excessive agency, agent goal hijacking (typically through prompt injection), tool misuse, identity and privilege abuse, and memory poisoning.
ANSSI: its Recommandations de sécurité pour un système d’IA générative (security recommendations for a generative AI system, April 2024) set out 35 recommendations covering the whole lifecycle, with an emphasis on segmentation, logging and access filtering.
MITRE ATLAS: a knowledge base of attack tactics and techniques against AI systems, built on the model of MITRE ATT&CK. It is invaluable for building detection scenarios.
AI Act: for high-risk systems, Article 15 requires an appropriate level of cybersecurity (see our analysis AI Act: the new timeline after the Digital Omnibus).

A seven-step approach

Inventory the assistants, agents, connectors, extensions and accounts in use, including undeclared uses.
Apply least privilege: a dedicated identity for each agent, minimal rights, read-only by default, short-lived access tokens.
Treat all external content as untrusted: separate instructions from data, filter inputs and outputs, block exfiltration channels (links, remote images, unexpected outbound calls).
Require human approval for sensitive actions: payment, sending outside the organization, deletion, change of rights.
Log and monitor: prompts, tool calls and data accessed, fed into the SIEM with dedicated detection rules (abnormal volumes, unusual tools, unknown destinations).
Test regularly: penetration tests targeting prompt injection with every new version, new model or new connector.
Govern: an acceptable use policy, a catalog of approved tools, a review of suppliers (data location, reuse for training) and team training.

And for the SOC?

Agents must be monitored like privileged accounts: their actions must be correlated with the rest of the activity in the SIEM, and a response playbook must provide for revoking their tokens, disabling a connector or purging a compromised memory.

Conversely, when the SOC itself uses AI to triage alerts or summarize incidents, the same rules apply: the logs being analyzed may contain malicious instructions, and the AI must remain the analyst’s assistant, not the decision-maker.

Sources

← All insights