Your agent's screenshot tool is reading your passwords

18 September 2026

If you have given an AI agent a screenshot tool on the Mac you actually work on, it has almost certainly seen something you would not have shown it. Not because it is malicious. Because a screenshot does not know what it contains.

What is actually in the picture

Think about what is on your screen right now. Not what you are looking at - everything that is on it. On a working developer's machine, a full-screen capture routinely contains at least one of:

A password manager that happens to be unlocked
A sign-in field with a partially typed password in it
A .env file open in an editor tab you forgot about
An API token that a command printed into a terminal ten minutes ago
A customer's name, email or case notes in a support tool
A 2FA code, visible for the thirty seconds it is valid

Every one of those goes to the model as image data, and from there into whatever the conversation is stored in. Not stolen - just sent, because you asked for a screenshot and a screenshot is all of the screen.

Why "I'll just be careful" does not hold

The obvious answer is to close sensitive things first. It fails for a mundane reason: the agent decides when to take the screenshot, and it takes a lot of them. An agent working through a five-step task screenshots after every step. You cannot audit a moment you did not choose.

The second answer is to only screenshot one window. Better, and still leaky: the window you are automating is often the one with the login in it. That is usually why the agent is there.

Why redacting afterwards is not redacting

The instinct when building this is to capture the image, then find the sensitive regions, then paint over them. It produces a correct-looking output file and it is wrong, for a reason that is easy to miss:

capture  ->  write PNG  ->  find regions  ->  paint  ->  write again
                  ^
                  here, for a few milliseconds, an unredacted
                  picture of your desktop is a file on disk that
                  any other process on the machine can read

A few milliseconds is not nothing when a process can poll. And the window is not the real problem - the real problem is that a security property with a race in it is not a security property, it is a race you have not lost yet.

The order has to be: capture into memory, find the regions, paint them, then encode and write. The unredacted bitmap should never exist anywhere but in the process's own memory. That is a small change to write and a large change to the guarantee.

The detail that breaks most implementations

macOS marks password fields for you, which makes this sound easy. It is easy, and there is exactly one trap, and nearly everyone falls into it.

Where the field lives	How macOS marks it
A native app (Mail, System Settings, a Cocoa app)	Role `AXSecureTextField`
A web page, or an Electron app - Slack, VS Code, Notion, anything built on a web view	Role `AXTextField`, subrole `AXSecureTextField`

Check only the role, and your redaction covers native fields and misses every password field in every browser and every Electron app. Which is to say: it misses the ones people actually use.

We shipped that bug ourselves for about an hour. The test passed the whole time, because the test used a native field.

What a password manager needs is different

For a vault - 1Password, Bitwarden, Keychain Access - field-level redaction is the wrong shape entirely. There is no safe part of that window. Descending into a password manager's UI to work out which bits to hide is the same mistake in a smaller font.

Black out the whole window, and do not walk into it to decide.

That leaves a list of which apps count as vaults, and that list is the honest weak point of any tool that does this. Ours contains the password managers we thought of, in one country, on our own machines. It does not contain your bank, your company's secrets manager, or whatever is popular where you live. That is not a problem one team can fix by working harder - it is fixed by many people each adding one line, which is why there is an issue form for exactly that and it needs no code.

Black, not blurred

Blur and pixelation look thorough and are not. A model good enough to read your screen is often good enough to read through a light blur, and pixelation of a known font is a solvable puzzle. Opaque black is not a stronger version of blur - it is a different thing, and it is the only one with no recovery path.

What this still does not cover

Redaction covers what the operating system marks as secure. A password sitting in a plain text editor is not marked. A token in a terminal buffer is not marked. An API key in a config file on screen is not marked. No amount of care at this layer finds those, and a tool that claims otherwise is selling you something.

When the screen holds something the system cannot know is sensitive, the answer is a read-only mode or closing the window, not a cleverer filter.

How to check your own setup in two minutes

Open a sign-in page with a password field and type a few characters into it.
Ask your agent to screenshot that window.
Look at what came back.

If the characters are visible - even as dots, since dots tell an attacker the length - your tool is not redacting. If the field is black, try it again in a browser and in a native app, because those are two different code paths and passing one does not mean passing the other.

It is a two-minute check and it tells you more than any README.

Computer MCP does the capture-redact-write order described here, checks role and subrole, and blacks out whole password-manager windows. It is MIT, runs on your Mac, and there is no service of ours in the path. The security model spells out what it does not protect you from, which is the part worth reading.