Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: EchoLeak showed that a single crafted email could drive Microsoft 365 Copilot to access internal files and exfiltrate data through allowed channels, according to Sentra's analysis of the CVE-2025-32711 attack path. The deeper lesson is that prompt injection becomes a governance failure when AI assistants can reach too much data and too many outputs at once.
NHIMG editorial — based on content published by Sentra: EchoLeak and the structural risk of prompt injection in Microsoft 365 Copilot
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams reduce prompt injection risk in AI agents?
A: Security teams should reduce prompt injection risk by constraining what enters the context window, limiting tool permissions, and separating untrusted retrieval content from privileged instructions.
Q: Why does indirect prompt injection create a bigger security problem than a simple model bug?
A: Because it exploits trusted workflows, not just model responses.
Q: What breaks when an AI assistant can access private data and untrusted content at the same time?
A: When an assistant can access private data and ingest untrusted content, a small injected instruction can become a data-exfiltration path.
Practitioner guidance
- Scope assistant data reach by default Review which SharePoint sites, mailboxes, documents, and data stores Copilot or similar assistants can access, then remove anything outside the user's current role.
- Classify sensitive content before AI retrieval Apply sensitivity labels and DLP policies so high-value records are excluded from AI context unless the user is explicitly entitled to see them.
- Review external ingestion channels Limit which external emails, documents, plugins, and federated collaboration sources can feed AI assistants.
What's in the full article
Sentra's full analysis covers the operational detail this post intentionally leaves for the source:
- A step-by-step walkthrough of the EchoLeak bypass chain, including classifier evasion and allowed-domain proxying.
- The Copilot-specific exposure conditions that determine when prompt injection can reach internal files.
- Practical guidance on scoping data sources, labeling content, and limiting external ingestion for Microsoft 365 environments.
- The agent review questions Sentra recommends before production deployment of Copilot Studio workflows.
👉 Read Sentra's analysis of EchoLeak and Copilot prompt injection risk →
EchoLeak and Copilot data access: are your controls scoped enough?
Explore further
19/08/2026 4:17 pm
EchoLeak proves that AI assistant security is now a data access governance problem. The vulnerability was patched, but the architectural lesson remains: if an assistant can reach sensitive data, it can also be induced to expose it. That shifts the control conversation from prompt filtering to scoped entitlements, labeled data, and monitored egress. For practitioners, the decisive question is not whether the model is safe in isolation, but what it can touch inside the enterprise.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when an AI assistant overshares sensitive content?
A: Accountability sits with the team that owns the policy, the attribute feeds, and the enforcement points, because ABAC only works when all three are managed together. If any one of them is missing, the organisation has not built a defensible control path, even if the model itself appears constrained.
👉 Read our full editorial: EchoLeak shows why Copilot security is a data access problem
