Cloud AI Agents: Your Project, Not Your Whole Laptop
A trusted Claude Code extension update in Cursor's marketplace arrived with code for a persistent SSH backdoor. It used the legitimate extension identity. Developers installed a tool to help them work and got an attack on their workstation instead.
An AI agent needs your project. It does not need the keys to your laptop. That is why we run the Flux agent in the cloud: give it the context to build a complete device, while keeping your workstation and credentials out of its reach.
One update, a whole workstation
On October 30, 2026, The Hacker News reported that a malicious Claude Code extension update had reached developers through Cursor's extension marketplace. Cursor identified version 2.1.313, available on October 29, and said it affected at most 5,000 users.
The code attempted to add an attacker's SSH key, establish a reverse SSH tunnel, and install persistence. It also collected host details, the configured Git email, and environment-variable names that revealed which credentials were present.
The malicious update was not developed by Anthropic. It reached users through the distribution channel they trusted. Once installed, it ran inside the environment where they did their work.
That is the problem with giving an agent your workstation: you give its software supply chain that access too.
Your laptop is more than one project
An engineering workstation holds a lot more than the job in front of you. SSH keys. Git credentials. Supplier accounts. Customer files. The next controller's PCB and firmware. An unreleased actuator assembly. Years of work that has nothing to do with today's task.
An unrestricted local agent runs with your account's access to that environment. A request to work on one project comes with access to files and credentials for many others.
The agent should get the project. Not inherit the engineer's digital life.
Put the agent in a workspace built for the job
Moving agent execution into an isolated cloud workspace draws a boundary around the work. The agent gets the design context and service access it needs. Your home directory, personal SSH keys, and unrelated customer files stay on your machine.
That gives engineering teams a smaller blast radius and controls they can manage in one place:
- Isolated execution. The agent runs code in its own sandbox, separate from the workstation you use every day.
- Scoped access. The work gets the project and service permissions it needs, rather than a personal credential that opens every repository or customer account.
- Secrets outside the agent's view. The agent uses authorized services without reading the raw credential.
- Central monitoring and patching. Managed environments give the provider one place to monitor, update, and revoke access. Teams do not have to clean up each engineer's laptop.
Our agent never sees your secrets
In Flux, you add API keys through a secure secret dialog. Our agent never gets to see the raw value. It sees a placeholder. Its sandbox gets a placeholder too.
You choose the websites that can receive the credential. When an authorized request goes to one of those sites, Flux substitutes the real value into the request. Other sites get the placeholder. You also choose whether the secret is available to one conversation, a project, your projects, or your organization.
The agent can use your distributor account to price a controller's BOM or your manufacturing account to get a quote for its mechanical parts. It gets permission to use the service, not a copy of the key. We explain that flow in Your API Keys, Used Safely.
Permission to use a secret should not mean permission to know it.
Keep the agent next to the design files
For hardware teams, the design files are the IP. The controller schematic, PCB, mechanical assembly, firmware, and manufacturing output belong to the same device. The agent needs that context to do useful engineering work.
Flux runs its agent in the cloud alongside the design files in your Flux project. It works on the whole device there, in the browser. No local agent installation with broad access to your workstation.
This is how I want AI hardware engineering to work: the agent has the context to build the device, and your team keeps control of its access.
Give your agent the project. Keep the keys to your laptop.
Build your next device with Flux.
Frequently asked questions about cloud AI agent security
An isolated cloud workspace separates agent execution from the engineer's workstation. The agent gets the project files and service permissions for the job. Personal SSH keys and unrelated files stay on the engineer's machine, while monitoring, patching, and access revocation are managed centrally.
No. Add a key through Flux's secure secret dialog, and the agent and its sandbox see a placeholder. Flux substitutes the real value into authorized requests to the websites you allow. You control the allowed sites and which conversations, projects, or organization can use the secret.
The Flux agent works in the cloud alongside the electronics, mechanical parts, firmware, and manufacturing files in your Flux project. Your team works with it in the browser, without installing an agent on each engineer's workstation.
Related Content
Your AI Agent Can Outgrow Its Editor: Hardware Design Workflows Beyond EDA and CAD Features
AI Is Coming for Your CAD Skills. Let It.
Automated PCB Manufacturing Needs Automated Design
How to Choose Decoupling Capacitors with PDN Simulation, Not Rules of Thumb
Gerber File Check: The Flux Agent Checks Your Files Before Fabrication
Stack Overflow for Hardware Engineering: Ask AI Inside Your Design
Let’s start building.
Let’s build your idea together. All you need to do is describe what you want to make, or what problem you want to solve. Flux will work with you to make it a reality.
