Governance · 5 minute read
Computer-Use Agent Security: Controls That Hold
Computer-use agent security rests on six controls: an isolated environment with only the applications the task needs, credentials created for the task and never borrowed from a person, environment-level allowlists of applications and URLs, treatment of on-screen content as untrusted, human approval before consequential actions, and full session recording for audit and investigation.
A computer-use agent is a user of the desktop it runs on. Whatever that desktop can reach, the agent can reach, and unlike a scripted bot, the agent can be talked into doing things by the content it reads. Those two facts define the security model. This guide sets out the controls, the threat the model is built around, and the questions to ask before and after launch. It expands the security section of the computer-use agents in the enterprise whitepaper and applies the general model in the agent identity and access control whitepaper.
What is the threat model?
| Threat | Mechanism | Consequence without controls |
|---|---|---|
| Over-reach | Agent runs on a desktop with broad access | Any misstep or steer touches unrelated systems |
| Credential misuse | Agent uses a human's session or a shared account | Misattribution; full inherited access |
| Injected instructions | On-screen text redirects the agent | Data exfiltration or unauthorized actions |
| Misread screens | Similar controls, dialogs, dynamic layouts | Wrong actions on the right system |
| Task drift | Plausible but wrong path | Wasted steps; unintended actions |
| Data exposure | Screenshots and recordings contain sensitive data | A new sensitive data store |
Injected instructions are the distinctive threat. Every other integration method reads structured data; a screen agent reads whatever is displayed, including content an attacker can place on a portal, in an email preview, or in a document. The general threat is described in what is indirect prompt injection.
What are the six controls?
1. Isolation
Each agent runs in a dedicated environment: a browser profile or virtual desktop with only the applications the task needs, no persistent state between tasks unless required, and no access to email, chat, file shares, or the corporate network beyond allowlisted destinations. The environment, not the prompt, is the boundary.
2. Task-scoped credentials
Credentials are created for the task, granted minimum permissions, issued from a broker, and rotated. The agent's own identity is recorded on every action. It never runs under a human's session. See secrets management for AI agents.
3. Allowlists and blocklists
Applications, windows, and URLs the agent may interact with are enumerated and enforced at the environment or proxy level. Everything else is blocked. Prompt-level restrictions ("only use these sites") are advisory and fail under injection; environment-level restrictions hold.
4. Untrusted-content handling
On-screen content is data. The runtime keeps it out of the instruction position, the agent's tools are restricted so a redirected agent cannot do damage, and consequential actions require confirmation when the plan changed after reading new content. Test with adversarial pages.
5. Approval gates
Reversible actions flow; consequential ones, payments, account changes, messages, deletions, pause for a human who sees the screenshot and the intended action. The pattern follows human-in-the-loop AI explained.
6. Session recording
Every session is recorded: screenshots or video, actions, reasoning where available, credentials, approvals, outcomes, with a trace identifier. Recordings are reviewed on a sample and on every incident. They also contain sensitive data, so they are redacted and access-controlled like any regulated store.
How does browser isolation differ from desktop isolation?
| Aspect | Browser agent | Desktop agent |
|---|---|---|
| Attack surface | The browser and allowlisted sites | The operating system and installed applications |
| Isolation unit | Browser profile or container | Virtual desktop or VM |
| Credential scope | Site accounts | System and application accounts |
| Blocking | URL allowlist, download control | Application allowlist, network and file controls |
| Recording | Page-level | Full screen |
Default to browser agents; move to desktop agents only when a thick-client application forces it.
What should be tested before launch?
- Allowlist enforcement: navigation to a non-allowlisted URL fails at the environment.
- Credential scope: the task account cannot reach unrelated records.
- Injection: pages containing instructions do not cause consequential actions without approval.
- Gates: consequential actions pause and resume correctly; expired approvals reject.
- Recording: sessions are complete, linked, and redacted.
- Kill switch: the agent can be stopped mid-task and its credentials revoked; see AI agent kill switch design.
What questions should a security review ask?
- What can this environment reach, and how is that enforced?
- Whose credentials does the agent use, and who issued them?
- What happens when the page says "ignore your instructions"?
- Which actions pause for approval, and who approves?
- Where are recordings stored, who can see them, and how long are they kept?
- How is the agent stopped, and how quickly?
- What did the shadow-mode evaluation show on adversarial cases?
What are the common failures?
- Shared desktops with broad access.
- Borrowed logins.
- Allowlists in the prompt.
- No gates on submit buttons.
- Recordings nobody reviews, or recordings nobody protects.
How does FISTA Solutions help?
FISTA Solutions builds computer-use agents as governed AI agents with these controls designed in: isolated environments, brokered credentials, environment-level allowlists, injection testing, approval queues, and recording. Our forward deployed engineers work with your security team so the controls fit your platform, and the AI enablement practice makes them reusable across tasks. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.
To review a screen-agent deployment, message FISTA on WhatsApp, or read how to build a browser automation agent for the implementation.
Share-ready article cover
Download the generated social format.
Clear answers
Questions raised by this field note.
Straightforward guidance for evaluating scope, fit, and the next step.
01What is the biggest security risk of computer-use agents?
Combining broad desktop access with the ability to be steered by on-screen content. If an agent runs on a shared desktop under a human's session and reads a page containing crafted instructions, it can be redirected to act with all of that person's access. Isolation, scoped credentials, and untrusted-content handling remove that combination.
02Can a computer-use agent use an employee's login?
It should never. Running under a human's session inherits their entire access and misattributes every action to them. Create credentials for the task with minimum permissions, issue them from a broker, rotate them, and record the agent's own identity on every action.
03How do you defend against prompt injection on screen?
Treat everything the agent reads as data rather than instruction, restrict the environment so a redirected agent cannot reach anything beyond the task, require confirmation before consequential actions when the agent's plan changes after reading new content, and test with pages and documents that contain injected instructions.
04What should be recorded?
Every session: screenshots or video, the actions taken, the model's stated reasoning where available, the credentials used, approvals and their approvers, and outcomes, linked by a trace identifier. Retain per policy with redaction of sensitive on-screen data, and review a sample regularly.
Continue exploring
Related capabilities
Start with the hard problem
Need the outcome owned, not merely analyzed?
Tell us where delivery is constrained. We’ll map the fastest credible path from intent to verified production.