TL;DR
Amazon Quick Desktop’s new “local-first” model introduces a high-risk Excessive CAP profile. Noma Security researchers identified three critical attack vectors: the manipulation of agents to write and stage malicious code scripts in local directories, the hijacking of browser automation to execute destructive actions in authenticated SaaS sessions, and the vulnerability of Scheduled Agents to automated data exfiltration via indirect prompt injection.
The launch of Amazon Quick Desktop app marks another significant shift in how AI is allowed to interact with local employee workstations. Moving beyond the browser tab and into a native, persistent desktop environment, Amazon Quick gains access to local files,and cross-app workflows.
While the integration drives productivity, it also shifts the security boundary from the cloud to the user’s hard drive. Noma’s Security Research Team took Quick for a spin to identify the primary misconfigurations and architectural risks inherent in Amazon’s new local-first model.
How Does Amazon Quick Desktop App Access Local Files?
Unlike previous web versions, the Amazon Quick Desktop app operates with direct visibility into the local file system. It indexes “Spaces,” which are designated folders where the agent learns from documents, spreadsheets, and code.
Amazon Quick Desktop Agent
-
Over-Permissioned Indexing:
The most common misconfiguration is folder creep. This occurs when users grant the agent access to root or sensitive directories such as ~/Documents or ~/Code. If an agent indexes a folder containing SSH keys, .env files, or browser session exports, that sensitive data becomes part of the agent’s Personal Knowledge Graph. This makes sensitive data retrievable via simple natural language queries.
-
Local Staging for Malicious Binaries:
Because the agent can write and edit files in these local folders, it can be manipulated to stage malicious scripts. A compromised prompt could instruct the agent to update a local utility script with malicious code. The user might then execute that file manually, unaware that it was modified in the background.
Local Attack Surface Risks: Sandbox Hijacking and Human Proxying
Our research further revealed that technical boundaries, such as the OS-level sandbox, are not absolute when faced with context-based attacks. Below are two of the most critical risks identified by the Noma Security Research Team.
-
Sandbox Hijacking via Context Poisoning:
Using similar methods discovered in our GeminiJack research, an attacker can hijack the local sandbox without needing a direct network exploit. By placing a “poisoned” context into a folder indexed by Amazon Quick Space, an attacker can embed hidden instructions that the agent treats as a command. When the agent processes this file, the “context attack” forces it to create a malicious Python or JavaScript written to the local machine. This allows an attacker to use the agent’s own internal tools to generate malicious payloads or prepare data for exfiltration from right inside the workstation.
-
Privilege Escalation via Human Proxying:
While the sandbox is designed to block dangerous system calls such as modifying your registry or firewall, the agent can bypass these rules by recruiting the user. We identified a pattern where a misdirected agent, blocked by the sandbox, will provide the user with “step-by-step instructions” to run the restricted command manually in their terminal. Because users often trust the agent’s context, they unknowingly act as a High-Privilege Proxy. This effectively turns a blocked sandbox action into a successful system compromise, a new vulnerability class discovered by Noma Security termed Advisory Bypass.
Malicious Skill Injection
Amazon Quick allows users to add “Skills” that extend the agent’s capabilities. Our research shows that these skills can be weaponized to create a silent, permanent backdoor into the agent’s logic.
-
Supply Chain Risk:
The user downloads a legitimate-looking (but malicious) skill from an open-source web platform, resulting in a persistent malicious runtime instruction loaded into the agent. This can lead to destructive actions, exfiltration of sensitive data, and the downloading of malicious files from the browser.
-
Indirect Prompt Injection Skill Creation:
This risk often starts when a user asks the agent to surf the web for a research. Through Indirect Prompt Injection, an attacker-controlled website can trick the agent into “self-installing” a new skill. The agent essentially builds its own malware based on the malicious data it just read. This creates a permanent vulnerability that triggers during every chat, even after the original research task is finished.
Browser Automation and Session Hijacking
One of the most powerful features of the desktop app is its ability to control the browser using the user’s existing authenticated sessions, such as cookies and active logins.
-
Destructive Actions in SaaS:
If the agent is hijacked via a malicious prompt, it can perform actions within any app the user is logged into. Examples include deleting Salesforce records or modifying GitHub repo permissions.
-
Data Exfiltration via GET Requests:
Our research also confirms that the browser tool can be forced to leak data. By appending sensitive local information discovered via the local file index to a URL as a query parameter, the agent can fetch a URL that is actually an exfiltration point for an attacker.
Amazon Quick Scheduled Agent Vulnerability
The defining feature of Amazon Quick Desktop is the Scheduled Agent. These are persistent background tasks that monitor inputs such as Slack channels, emails, or Jira tickets to take proactive action.
- Indirect Prompt Injection: This is the highest risk vector for the desktop app. Because a scheduled agent is constantly reading untrusted data such as incoming email, an attacker can send a message containing hidden, malicious instructions which will be stored as context.
- Automated Data Leakage: A hijacked scheduled agent can be instructed to scrape the local file system and send the contents to a Slack channel or an external URL while the user is away from their terminal.
Noma’s Assessment: “No Excessive CAP” Problem
Our research team applied our No Excessive CAP framework (Capabilities, Autonomy, Permissions) to this desktop environment. Amazon Quick currently sits at a high-risk intersection of all three. By granting a persistent agent the Capability to browse and write files, the Autonomy to run on a schedule, and the Permissions of the local user, the blast radius of a single prompt injection becomes catastrophic. Built-in safety features are insufficient when the agent is designed to trust the very data it is meant to process.
Harden Your Amazon Quick Deployment
Before deploying Amazon Quick across an enterprise environment, Noma recommends security teams educate their users and encourage implementing the following hardening measures:
-
Strict Space Scoping:
Enforce a policy of Least Privilege for file access. Users should index only specific project folders, not their entire user directory and ensuring not to index anything with secrets.
-
Human-in-the-Loop for Write Operations:
Disable “Auto-Execute” for any agent actions that involve file writes, email sending, or browser-based state changes. Require a manual user to click ” Approve ” for every outbound action.
-
MCP Server Allowlisting:
Control which Model Context Protocol (MCP) servers the desktop app can connect to. (We suggest limiting access to only official MCPs.)
Conclusion
Amazon Quick Desktop offers a powerful new way to work, but its always-on nature and local file access require different considerations and a new approach to endpoint security. Organizations must get in the habit of thinking about and planning agentic security where agents are akin to privileged local users with an unpredictable logic chain, instead of thinking they are simply replicating or replacing traditional human workflows.
