Computer use agent security is an operating-system question, not a model question
Most pages on this topic talk about prompt injection, OWASP for agentic AI, and the OpenClaw misconfigurations that exposed 4,500-plus installs in early 2026. Useful, but they skip the boring layer that actually decides what an agent on your Mac can touch: macOS TCC, the entitlements file in the .app bundle, and the live event-tap probe that catches stale permission caches. This guide reads Fazm's release entitlements (four keys) and the AXIsProcessTrusted plus CGEventTap check in AppState.swift, then shows you how to do the same audit on any local computer use agent before granting it accessibility.
How safe is a computer use agent on my Mac?
A local computer use agent can only do what macOS TCC lets it do. Read its .entitlements file and the permissions it requests in System Settings; those two artifacts define its blast radius on your machine.
A cloud computer use agent has a different shape. It runs the model in a remote VM and ships your screen and prompts off your machine on every action. Different threat model. Different things to check. Neither is automatically safer; both are auditable if you know which two artifacts to read.
What every other page on this misses
I read the pages that currently come up for this topic. Splashtop and Gartner-style writeups give you the OWASP Top 10 for agentic AI: prompt injection, supply chain, governance gaps, shadow AI. Microsoft Security's post on Copilot Studio walks through tool misconfigurations. Barracuda and McAfee both have OpenClaw explainers. AGAT's 2026 enterprise piece quotes the headline stat that 88 percent of organizations reported a confirmed or suspected AI agent incident last year.
All of that is real, and most of it applies. But none of those pages answers the question a Mac user actually has when they are about to grant an unsandboxed binary the right to read every window on their machine. The question is: once I click Allow, what does the operating system actually let this thing do, and how do I check before I click?
On macOS the answer lives in two places. The first is the agent's entitlements file, declared at build time and shipped inside the .app bundle. The second is the TCC database, which tracks per-capability per-app grants and is enforced by the kernel independently of whatever the agent thinks it has. I will show both, in Fazm's case, then walk through the same audit you can do on any other local agent.
“Four keys. The smaller the entitlements file, the smaller the surface the OS will let this binary touch. There is no app-sandbox key set to true here, because accessibility-API use against other processes is not allowed inside the macOS sandbox.”
Desktop/Fazm-Release.entitlements
Anchor fact 1: the release entitlements file is four keys
Verbatim, from Desktop/Fazm-Release.entitlements
Read the keys. app-sandbox is false (mandatory for an agent that talks to other apps via accessibility). automation.apple-events is true (the agent can send Apple Events; each target app prompts you once). device.audio-input is true (microphone for voice transcription via WhisperKit). device.screen-capture is true (rare visual fallback). The release build deliberately omits get-task-allow, which means you cannot attach a debugger to the running app to scrape its memory.
Compare this to the dev entitlements (Desktop/Fazm.entitlements), which adds com.apple.security.get-task-allow for local debugging. Release strips that. If you ever evaluate a local agent and see allow-jit, allow-unsigned-executable-memory, or disable-library-validation in its release entitlements, those keys loosen Apple's hardened-runtime defenses and deserve a hard question.
Anchor fact 2: the live TCC probe in AppState.swift
Apple's recommended check for accessibility permission isAXIsProcessTrusted(). On macOS 26 (Tahoe), that call has a known failure mode: the answer is cached inside the process, and after an OS update or an app re-sign the cache can stay "granted" even though real AX calls fail. That matters for security because the user-facing answer to "does this app have accessibility?" silently disagrees with the OS-enforced answer, and the agent keeps trying to drive other apps with no observable effect.
Fazm pokes the live TCC database via CGEvent.tapCreate. Event-tap creation checks the live grant, not the cached value. If the two answers disagree, the code logs a stale-cache detection and surfaces a restart prompt to the user after three retries spaced five seconds apart. This is small but load-bearing: it is the difference between "the agent is silently broken" and "the agent tells the user the OS just changed something underneath us".
Cloud computer use agent vs local computer use agent
Two different security models. Different things to check. Pick whichever fits your threat model and your data-handling posture.
| Feature | Cloud agent (CUA, Operator) | Fazm (local) |
|---|---|---|
| Where the model runs | Cloud (Anthropic, OpenAI, Google datacenter) | Cloud OR local (custom API endpoint, including a local Ollama or vLLM) |
| What leaves your machine on each action | Screenshot of your active screen, often plus DOM, plus prompt | Structured accessibility delta plus prompt. No screen pixels by default. |
| What enforces 'agent cannot read X' | Remote VM boundary plus the vendor's policy | macOS TCC. Revocable in System Settings without quitting the agent. |
| How to audit the toolbox | Read the API docs the vendor publishes | Read Desktop/Sources/Providers/ChatToolExecutor.swift in the open repo |
| Sandbox status | Vendor-managed remote sandbox; you do not see the entitlements | Unsandboxed Mac app, four-key entitlements file in the source tree |
| Action latency | 1 to several seconds per action (image upload + vision pass) | Tens to hundreds of ms per action (AX read), plus the model call |
| Network destinations the harness talks to | Vendor inference endpoint + supporting services | Whichever model endpoint you configure. Default is Anthropic. |
| Failure mode when permission is revoked mid-session | Vendor side keeps running; you have to log out of the web app | AX calls return apiDisabled within milliseconds; agent stops |
Both rows are real shipping products in 2026; pick on a per-task basis, not on a vibe.
How to audit any local computer use agent in five minutes
Same workflow whether the agent is Fazm, mcp-server-macos-use as a standalone, the macOS computer-use agent shipped by some other vendor, or something you wrote yourself. Five reads, in order. Most of them complete in well under a minute.
The five-minute audit
Read the .entitlements file
Inside the .app bundle (Contents/Info.plist) or in the source repo. Count keys. Each key is a capability the OS will let this binary exercise after you grant it. A dozen keys is more surface area than four. Anything containing com.apple.security.cs.allow-* (allow-jit, allow-unsigned-executable-memory, disable-library-validation) is loosening Apple's hardened-runtime defenses; ask why.
Note which TCC panes it asks for during onboarding
Accessibility, Screen Recording, Microphone is the floor for a useful agent. Full Disk Access is a step change. Input Monitoring overlaps with accessibility. If onboarding pushes you toward 'Allow All' without naming each pane, that is a smell.
Watch the egress on first run
Little Snitch, Lulu, or read the network code. A local-first computer use agent should be calling exactly two domain families: the model endpoint you picked, and the auth/telemetry surface for the app itself (Firebase, PostHog, Sentry, etc.). Anything else is worth a question.
Check whether the model endpoint is swappable
If the agent only works with one cloud vendor's API, your data-handling story is whatever that vendor's policy says. If you can point it at a local model (Ollama, vLLM, LM Studio) or a corporate proxy (GitHub Copilot's Anthropic-compatible endpoint, an internal gateway), you have an honest local-only path when you need one.
Audit the tool definitions
In an open source agent, this is one file. (Fazm: Desktop/Sources/Providers/ChatToolExecutor.swift, with the per-tool dispatch table at the top.) The size of the toolbox is the upper bound on what the model can do. Fewer tools is fewer ways for prompt injection to escalate. Watch for shell-exec, file-write, network-fetch, and credential-read tools; those are where blast radius lives.
Threat classes and where the OS catches them (or does not)
One way to think about computer use agent security is: which of the common threat classes does macOS catch for free, and which ones you have to design around. This is the split for a typical local Mac agent like Fazm.
Prompt injection from page or document
A web page, PDF, or email body contains hidden instructions that try to redirect the agent. OS layer cannot help here; the model layer can. Mitigation: confirmation gate on irreversible tools, smaller toolbox, prefer local models for sensitive contexts.
Silent screen exfiltration
An agent that captures the screen on every action can leak secrets visible in other windows. macOS Screen Recording permission is per-app and revocable. Local agents that read accessibility instead of pixels do not need to keep the screen-recording channel hot.
Privilege escalation via Apple Events
Apple Events are TCC-gated PER target app. The first time the agent sends an event to Mail or Finder, you get a system prompt naming the target. You can deny per-app and the OS remembers.
File-system overreach
Full Disk Access is its own TCC pane and the OS will not grant it implicitly. If the agent never asks for it, it cannot read ~/Library/Mail, the Messages SQLite, Safari history, or System Settings. Look once before installing, look again every quarter.
Persistent process and login items
An agent that adds itself as a Login Item runs at boot. macOS surfaces Login Items in System Settings and warns you on first install. If a local agent is launching auxiliary daemons, it should be one or two named items, not a swarm.
Stale TCC cache after OS update
On macOS 26 (Tahoe) the in-process AXIsProcessTrusted cache can lie. Fazm probes via CGEvent.tapCreate to detect this and prompts a restart after three retries. Worth knowing because 'agent silently does nothing' after a system update is sometimes a TCC bug, not a crash.
What this means in practice
If you are a Mac user evaluating any computer use agent, the single most useful thing you can do is read the entitlements file and the TCC requests, and treat those as the floor of what the thing can do. The model layer matters for prompt injection and tool selection. The OS layer matters for everything else.
If you are choosing between a local and a cloud computer use agent, the trade is honest. Local: smaller network surface, OS- enforced permission boundary you can revoke in System Settings, higher reliability per action because the read path is structured AX instead of vision. Cloud: someone else maintains the sandbox and the model, you do not have to keep your hardware warm, vendor-side guarantees might be exactly what your data handling agreement needs.
If you build computer use agents for a living, the loop in AppState.swift is worth borrowing. AXIsProcessTrusted is not enough on macOS 26. Add the CGEvent.tapCreate probe; cap your retries; surface a restart prompt instead of silently looping against a stale cache. Your users will not know what TCC is, but they will know the difference between "the agent works" and "the agent just sits there".
Want to talk through computer use agent security for a real workflow?
If you are evaluating a local computer use agent for your team, book 20 minutes. We will walk the entitlements, the TCC pane list, and the model-side boundaries against your specific threat model.
Computer use agent security: common questions
How safe is a computer use agent on my Mac?
On macOS, a local computer use agent can only do what TCC (Transparency, Consent, Control) lets it do. Read its entitlements file and the permissions it requests in System Settings; those two artifacts define its blast radius on your machine. A cloud computer use agent (Anthropic Computer Use, OpenAI Operator, Google's browser agents) trades that local OS enforcement for a remote VM sandbox, plus a network round-trip that carries your screen and prompts off your machine on every action. Different threat models, different things to verify. Neither is automatically safer; both are auditable if you know what to look at.
What entitlements does Fazm declare in its release build?
Four keys, no more. com.apple.security.app-sandbox is false (the agent is not sandboxed because the macOS sandbox prevents accessibility-API use against other processes). com.apple.security.automation.apple-events is true (the agent can send Apple Events to other apps, gated by per-target user prompts). com.apple.security.device.audio-input is true (microphone, used for voice control via WhisperKit). com.apple.security.device.screen-capture is true (screen recording, used for the rare visual fallback when an app has no accessibility tree). com.apple.security.get-task-allow is absent in release, which means a debugger cannot attach to the running app. The file lives at Desktop/Fazm-Release.entitlements in the open-source repo.
Why is the macOS sandbox disabled, and is that automatically a security regression?
Apple's app sandbox prevents an app from reading other apps' processes via the accessibility API. So any agent whose job is to read what is on screen and click buttons in other apps must run unsandboxed; this includes Fazm and every credible local computer use agent on macOS. The mitigation that replaces sandbox is TCC: every sensitive capability (accessibility, screen recording, microphone, automation) requires an explicit user-granted permission that you can revoke in System Settings at any time. The trade-off is real, but unsandboxed plus explicit per-capability TCC grants is the model the OS gives you for this product class. There is not a third option.
What does AXIsProcessTrusted actually verify, and what is its known failure mode?
AXIsProcessTrusted (and AXIsProcessTrustedWithOptions) is the Apple-provided way for an app to ask 'do I have accessibility permission'. It returns a boolean. The known failure mode, present on macOS 15 and 26, is that the result is cached inside the process: after a macOS update or app re-sign, the cache can stay 'granted' even though real AX calls fail with kAXErrorAPIDisabled or kAXErrorCannotComplete. Fazm's AppState.swift handles this by ALSO probing CGEvent.tapCreate (which checks the live TCC database, not the cached value), and if AXIsProcessTrusted returns true but the event tap creation fails, it logs a stale-cache detection and shows a restart alert after three retries spaced five seconds apart.
Can a computer use agent read files I never told it to read?
On macOS, only the ones it has TCC access to. Fazm has accessibility, screen recording, and microphone, plus Apple Events scoped per-target app. It does NOT have Full Disk Access (you have to grant that separately, and Fazm does not request it during onboarding). It cannot read the Library/Mail directory, the Messages database, or contents of System Settings. If you want to know whether a particular agent has Full Disk Access, look in System Settings -> Privacy and Security -> Full Disk Access; if its name is there with the toggle on, it does. If not, the OS will hard-stop reads.
What about prompt injection from a malicious page or email body?
Prompt injection is a real attack class: a webpage or document contains hidden text that instructs the agent to exfiltrate data, send a message, or click a destructive button. The mitigations are not new and they are not specific to a single product. Keep the agent on a model you trust. Run it locally so the prompts and screens are not also leaving your machine. Read the agent's tool definitions; the smaller the toolbox the smaller the attack surface. Use ask-confirmation prompts for irreversible actions (send email, delete file, run shell command). Fazm's chat tool list is enumerated in Desktop/Sources/Providers/ChatToolExecutor.swift; an audit of which tools exist is one file read.
What is the difference between Fazm and a cloud agent like Claude Computer Use, in terms of what leaves my machine?
Cloud agent: every action loop sends a screenshot (sometimes accompanied by a structured DOM) to a remote model, the model returns a tool call, the harness executes it. Your screen, your inputs, and the model's reasoning all transit the network on every step. Latency: one to several seconds per action. Local agent like Fazm: the accessibility tree is read on your Mac via AXUIElementCopyAttributeValue, the diff is computed on your Mac, only the structured delta and your prompt go to the model API (or to a local model, if you pointed Fazm at one via its custom-API-endpoint setting). Latency: tens to hundreds of milliseconds per action, plus the model call. Two completely different data-flow shapes.
How do I evaluate any computer use agent before I install it?
Five things to check. (1) Is it open source, so you can read the tools and the prompts. (2) Read its entitlements file (in the .app bundle at Contents/Info.plist or in the source repo). Count the keys. Each key is a capability you are about to grant. (3) Look at which TCC pane it asks for during onboarding. Accessibility plus Screen Recording plus Microphone is the floor for a useful agent; Full Disk Access is a step up that you should weigh hard. (4) Check the network destinations the agent talks to (Little Snitch, Lulu, or just look at the source). A local-first agent should not be calling out to ten domains. (5) Check whether its model endpoint is configurable, so you can route through your own proxy or a local model if you want.
What does Fazm send to a model API on every action?
By default, the structured accessibility-tree delta from the macos-use MCP server (lines, roles, text, in_viewport flags), plus the user's prompt, plus the chat history. Not the screen pixels. Screenshots are only captured when the agent invokes capture_screenshot, which is a tool the model has to actively decide to use (the system prompt steers it toward macos-use tools first, with screenshots as the fallback for apps without an accessibility tree). If you are running through Anthropic, this matters because it scopes what your data-handling agreement covers; the logs will show structured JSON, not images.
Can the agent disable my permissions, install malware, or delete my files silently?
The agent cannot grant itself new TCC permissions; only you can do that, in System Settings, with your local password. The agent can do anything the existing permissions allow: click a Finder button to drag a file to the Trash, type a Terminal command, send an Apple Event to Mail. So 'silent' depends on whether you wired it up to confirm destructive actions. Keep destructive shell commands behind a confirmation. Most local agents (Fazm, mcp-server-macos-use, the Claude Code CLI) do this for shell commands by default. Software Update, install of new system extensions, kernel-level access — none of these are reachable through accessibility or Apple Events.