Every claim on this page has a receipt.

Local first, by design.

Yad runs inside your own real Chrome browser, on your own computer. Not a cloud browser sitting on a server somewhere else.

It has two free parts, and you need both. Part A is this Chrome extension, the hand: it reads the page in front of you and acts on it, clicking, typing, navigating. Part B is the Companion, a small free app you download and run once on your own computer, the brain: it is the only piece of Yad that ever does the actual AI thinking or touches your raw API key. Part A alone can't think. Part B alone can't see your browser. Install both once and you're set. The Companion is Windows only for now.

You bring the AI: Groq, Google Gemini, OpenRouter, a custom endpoint you type in yourself, or a fully local model. Yad never holds an AI key on your behalf in some hosted account of ours, and never resells access to one.

Sensitive page content, passwords, card numbers, the fields that should never leave your screen, is masked before anything reaches any AI, cloud or local. Payment and checkout pages are always blocked from autonomous action, even when Yad is running in full-auto mode. No exceptions.

That was already true. What follows is what we built on top of it: locking down the one piece of sensitive data Yad has to touch, your API key itself.

Encrypted the instant you paste it, on a machine that remembered nothing.

Here is the exact mechanism. The first time you paste an API key into Yad, the extension sends it once to your local Companion. The Companion immediately locks that key using Windows' own built-in encryption, DPAPI, scoped to your Windows user account, so only that same account on that same machine can ever unlock it again. The Companion sends back an encrypted blob, the extension throws away the plaintext it was holding, and from that moment on the extension only ever stores and handles the encrypted blob. The raw key is never shown again, and it is never written to disk anywhere in readable form. When the Companion actually needs the key to call your AI provider, it decrypts it into memory for that single instant and nothing more.

We didn't assume that works. We proved it, the way a brand new user actually experiences it: with the real packaged installer, the exact file you'd download, run from a completely clean folder with no prior state and no leftover .env file from development. A freshly started Companion, in a different folder, with zero memory of anything that came before, was handed nothing but the encrypted blob. It correctly unlocked the key and activated the AI provider.

Then we tried to break it on purpose. We fed a freshly started Companion a corrupted, garbage blob instead of a real one. It did not crash. It did not activate anything. It failed safely and stopped, exactly the way a security boundary is supposed to fail.

A cap you set. A stop button that actually stops everything.

Every single AI call Yad makes, across every feature, is counted against a daily cap you set yourself. The default is 1000 calls a day, yours to change. That check sits at the one choke point every AI call in the entire system has to pass through on its way out, so there is no side door and no code path that skips it.

There's also a one-click Stop button. Press it, and every further AI call is blocked instantly, full stop.

Both the daily cap and the kill switch state survive a Companion restart, because a guard that resets itself when the app restarts isn't a guard. And we rebuilt both to fail closed instead of failing open: if the saved state is ever missing or unreadable for any reason, Yad's default is to block calls, not to quietly allow them and hope for the best. That matters most exactly when you're not watching. An autonomous task can never sit there draining your key while you're away from your desk.

Your key has exactly one place it's allowed to go.

Your API key is only ever sent over the network to the single AI provider you personally chose when you set Yad up: Groq, Google Gemini, OpenRouter, or a custom endpoint you typed in yourself. It is never sent to any server that we, the Yad team, control. There is no relay, no proxy, no logging endpoint that sees your key in transit.

Yad does have one feature that phones home: the recovery brain, a small system that learns from failed browser runs to get better at recovering from them across users. Even that feature, the one part of Yad explicitly designed to send data back to us, is deliberately narrow in what it's allowed to send. It transmits a bare website hostname and a short reason code, nothing else. Never your key. Never the content of the page you were on. Never the full URL, which could itself carry sensitive identifiers.

We put our own code on trial before you ever ran it.

Before any of this shipped, the new security code went through an 18-agent, AI-driven adversarial code review, a process the developer designed, built, and ran himself. Said plainly, because it matters: this is not a third-party audit firm, not a paid penetration test, and not any kind of certification. It's a rigorous, automated, multi-pass review the developer runs against his own code, the same way he'd run a test suite, except the reviewers are independent AI passes instructed to try to break the code rather than confirm it works.

Three separate lenses went through the code hunting for different things: one for plain correctness bugs, one for security holes specifically, and one for failure modes and edge cases that only show up when something goes wrong. Then a separate verification pass went back and rechecked every single claimed finding against the actual code before anything was accepted as real. A review that only lists suspicions isn't worth much. This one had to prove each finding against the real source before it counted.

The result: 12 real, confirmed issues. Two are worth naming directly. The kill switch state was not actually surviving a Companion restart, which would have quietly reopened the spending gate every time the app relaunched. And a PowerShell subprocess used during encryption was being launched by a bare program name instead of a locked-down absolute path, exactly the kind of gap that could let a planted fake binary intercept a key if one ever made it onto the search path. Both of those, and all ten of the others, got fixed.

Every fix was re-verified, not just with unit tests in isolation, but with live smoke tests and a full end-to-end test that drove the real Companion process through the actual native-messaging wire protocol Chrome itself uses to talk to it, the same channel a live session uses in production. Not a simulation of it.

We don't just review the code. We try to break it.

A code review reads the source. That's necessary, but it's not the same as actually attacking the running thing the way someone with bad intentions would. So after the review above, we put on that hat ourselves and went after Yad's own live components directly, the same instincts a real security researcher brings to a target.

We tried to sneak a payment page past the checkout guard eleven different ways: capital letters, double URL-encoding, hiding it in a hash route, path-traversal tricks, a null byte. All eleven were caught. We tried five dangerous link types a page could hand the agent, including one designed to run arbitrary code in your browser. All five were refused.

We attacked the Companion's local control channel with a DNS-rebinding trick, the exact method a malicious webpage would use to make itself look like it's calling from your own machine. Blocked, including on the two most sensitive routes: one that can read files from your computer, and one that can run JavaScript in your browser.

We fed the wire protocol between the extension and the Companion garbage bytes, a fake multi-gigabyte message length, and a message deliberately built to blow past its own size limit. The process didn't blink. We hammered the daily spend cap right at its exact edge to hunt for an off-by-one, and fired a hundred simultaneous kill-switch toggles at once looking for a race condition that could corrupt the saved state. Clean on both.

Nothing here was staged for this page. Every attempt above was run against the real, compiled, running code, not a description of what should happen.

No. Zero crashes, zero regressions.

Security work that quietly breaks the product it's protecting isn't a win. After every fix from that review was in and re-verified, we reran Yad's own task benchmark suite in full, the same suite that drives a real Chrome browser through real websites end to end to measure whether Yad can still actually do its job. Zero crashes. Zero regressions in the agent's core task-completion pipeline. The hardening made Yad safer without making it worse at the one thing it exists to do.

Rigor lives in the details too.

A few more changes landed in the same review pass. Smaller individually, each one closes a real gap.

Owning your limits is part of the engineering.

Not an afterthought bolted on for legal cover. Here's exactly what this page is not saying.