Cybersecurity
Computer Use & the Bot Problem
Building Mary and VisionAX taught me something I didn't set out to learn: the same architecture that makes computer use private also makes it convincing. That's worth writing about honestly, not just proudly.
Everything I've shipped so far — Mary reading the accessibility tree instead of screenshots, VisionAX falling back to on-device vision instead of a cloud model — was designed around one goal: never leave the machine, never guess at pixels when structure is available. Good privacy engineering. But privacy and detectability are, on platforms designed to tell people and bots apart, often the same axis viewed from two sides.
What a platform is actually checking for
A social platform doesn't verify humanity directly — it can't. It verifies a pattern of plausible behavior: mouse movement with the jitter a trackpad has, requests that come from a browser with a real rendering pipeline, timing between actions that matches how long a person takes to read something before clicking it, sessions that look like they came from one continuous person rather than a script replaying a macro. Traditional bot networks fail these checks because they usually skip the screen entirely — they call an API directly, or drive a headless browser that never paints a frame. Both leave fingerprints: missing headers, inhuman timing, a navigator.webdriver flag, a burst of identical requests with no browsing in between.
Computer-use software closes exactly that gap, and it does it for good reasons. Mary reads the accessibility tree because that's the same structure macOS itself hands to VoiceOver — it's ground truth about what's on screen, not an inference. VisionAX exists for the moment AX goes dark, so the fallback degrades in capability, never in honesty about what's really there. Put together, an agent built this way isn't simulating a session. It's driving the actual OS input path: real click events at real coordinates, a real render pipeline behind them, keystrokes with the timing jitter of whatever policy is generating them. None of the traditional bot signals apply, because none of the traditional bot shortcuts were taken.
That's not a flaw specific to Mary or VisionAX. It's a property of the whole category: any agent that operates a screen the way a person does is, by construction, harder to distinguish from a person. The better computer use gets at its actual job — being a legible, on-device operator of a real machine — the less purchase platform trust-and-safety has on it. I don't have a fix for that tension to offer here, and I'd distrust anyone who claimed to. What I do have is a reason multiplying it by a bot network changes the stakes past the point of a shrug.
Why "at scale" is the part that matters
One agent operating one machine on someone's own behalf is a pair programmer, or a person who can't use a mouse getting their computer to work for them. The same capability, run unattended across a farm of virtual machines with rotating identities, is a way to manufacture the appearance of thousands of independent people holding an opinion, engaging with a post, or agreeing with each other — during, say, an election, when that appearance is worth more than at almost any other moment. Coordinated inauthentic behavior isn't a new problem; platforms have fought it for a decade. What's new is that the tooling for it no longer has to look automated to look automated.
I'm not going to describe how to build that farm, and I'd decline if asked — that's the difference between naming a risk and handing someone the means to realize it. What I think is worth naming plainly, because it's structural rather than incidental, is this: the capability that makes computer use good for accessibility, for pair programming, for anyone who wants their machine to act on their intent, is the same capability that makes it good for manufacturing fake consensus. There isn't a version of "operate a real screen convincingly" that only works for the first use.
Why that means it has to be open
Given a dual-use capability like that, the question isn't whether to build it — computer use is being built regardless, by well-funded actors with every incentive to keep it closed. The question is what you do about the fact that it's dual-use. I think the answer is the opposite of the instinct a company protecting a product usually has.
A closed computer-use agent is a black box on both ends. Nobody outside the vendor can verify what guardrails exist — rate limits, refusal to interact past certain trust boundaries, logging that would let an abuse pattern be traced back. Nobody outside the vendor can verify those guardrails stay in place across a silent update, or that the same binary isn't licensed differently to a customer with different requirements. And the platforms trying to defend against misuse of the tool are working blind against it — no way to study what it actually does at the input layer, no way to build a detection signature against known behavior, because there's no artifact to study except the aggregate effect of a bot network they're already too late to stop.
Open source doesn't neutralize the dual-use problem — anyone can still read an open project's source and build something abusive from it, and I'd be lying if I said VisionAX being GPL-3.0 makes that impossible. What it changes is who gets to find out how the tool works, and when. A closed vendor's safeguards are a claim you take on faith, discoverable to the public only after harm and an investigation. An open project's safeguards are a diff anyone can read the day it lands — and just as importantly, so is the absence of one, before someone builds the missing piece into something worse. That's the whole argument for building Mary and VisionAX the way I have: not because openness prevents misuse, but because it's the only version of this capability where the people trying to defend against misuse aren't permanently a step behind the people building it.