AI Agent Data Exfiltration Lab: Make an Assistant Read the Admin’s Email

This article presents a security lab demonstrating how AI agents can be exploited to exfiltrate data by circumventing access controls. The core vulnerability occurs when AI tools lack built-in authorization checks and instead rely on the model's instructions to enforce permissions. The issue matters because as AI assistants gain access to sensitive systems like email, files, and CRMs, this attack pattern is transitioning from research demonstrations to real-world exploits.

• Models are not security boundariesThe article emphasizes that AI agents decide which functions to call based on conversational input, not policy enforcement. The model's instructions may state 'only help with user data,' but these are text that the model weighs against user arguments, meaning persuasive requests can override them. This is the foundational principle—authorization must live in the tools themselves, not in the model's system prompt.
• Tool design flaw enables the attackThe read_email tool accepts any user ID and returns mail for that user without checking who is making the request. The tool has access to the session's user identity but never compares it against the requested mailbox. This design—trusting the model to enforce permissions—is what allows an unprivileged user to access the admin's inbox when the model is convinced to call the tool with the admin's user ID.
• Persuasion tips the balance over policyThe attack succeeds by framing a plausible business reason for accessing another user's mailbox, such as verifying a migration or running an audit. The model, when given both its restrictive instructions and a credible-sounding task, uses persuasion rather than policy to decide what to do. A direct request for unauthorized data is more likely to be refused than the same request wrapped in a legitimate-seeming context.
• Authorization must check session identityThe core principle for defense is to treat every tool call as if a malicious user made it directly. Tools should extract the user identity from the session, not accept it as a parameter from the model's arguments, and then reject any requests outside that user's authorized scope. This moves the security boundary from the AI model into the actual tool implementation.
• Least privilege and confirmation limits exposureThe article recommends giving agents only the tools and scopes needed for their task, reducing the damage if the model is manipulated. Additionally, requiring explicit user confirmation for sensitive actions like reading other mailboxes, sending messages, or exporting data adds a friction point that makes exploitation harder. These controls do not rely on the model's judgment.
• Real-world incidents are now occurringThe article cites EchoLeak (CVE-2025-32711), a zero-click vulnerability in Microsoft 365 Copilot disclosed in June 2025, where a crafted email could make the assistant leak data from the user's context. The article notes that as companies connect assistants to mail, files, and CRMs, this class of bug is moving from research to real incidents, elevating the practical importance of these vulnerabilities.
• Fundamentally an IDOR problem with AIThe article explicitly connects this vulnerability to Insecure Direct Object Reference (IDOR) attacks, noting that the exploit is 'effectively IDOR with an AI model choosing the ID.' The fix is the same: check object ownership on the server for every request. This reframes the issue as a classic authorization failure rather than an AI-specific problem, making it more tractable for security teams familiar with traditional web vulnerabilities.
• Assessment technique identifies agent risksThe article provides a practical security review method: list an agent's tools, then for each tool ask 'what happens if the model calls this with an argument the user should not control?' This single question is presented as a reliable way to surface most agent vulnerabilities, shifting the focus from the model's behavior to the tool's permission enforcement.

Bottom line: AI agent vulnerabilities arise from tools that lack built-in authorization checks and instead depend on the model to enforce permissions—a boundary that persuasion can overcome. Secure AI agents require authorization logic inside every tool using real session identity, least privilege access, sensitive action confirmation, and continuous monitoring of tool calls.