← Patch home

Deeper dive: how Patch is built

Most security apps ask you to trust them. This page is for people who'd rather check.

Here's what Patch actually does with your information, what leaves your device, what's stored where, and what we haven't solved yet.

There's no account

Patch has no sign-up, no login, no password, and no user database. We don't know who you are, and there's no record connecting the checks you run to a person.

This isn't a feature we added. It's the constraint the whole app was designed around, and several things are harder because of it. But an app that collects security information about people becomes a target for exactly the attackers it's meant to protect against. The safest database is the one that doesn't exist.

What leaves your device

Three things, and only when you ask for them:

Scam checks. When you check whether a message or image is a scam, the content goes to our backend, which forwards it to Anthropic's API for analysis. The verdict comes back. Nothing is written down along the way.

Breach checks. When you check an email address, it goes to our backend, which queries Have I Been Pwned. Results come back. The address is not stored.

Advisor questions. Your question and the name of the screen you're on go to our backend and then to Anthropic. The reply comes back.

That's the complete list. Nothing else transmits. Patch does not phone home, does not send analytics about how you use it, and does not report what it finds on your machine.

What's stored, and where

On your device:

• Saved email addresses, in the operating system Keychain, encrypted at rest. Only if you choose to save them.
• Cached breach results, so re-checking doesn't hit the network. These are keyed by a one-way hash of the email rather than the address itself, so the plaintext isn't sitting in a file.
• Your progress through things like credit freezes and broker removals. Local only.

On our servers:

• Rate-limit counters. Keyed by IP address or a device-generated identifier, holding a number and expiring after 24 hours.
• A monthly count of total API calls, so runaway usage stops rather than generating an unbounded bill.

That's it. No emails, no message contents, no scan results, no account records.

The honest asterisk: IP addresses are personal data, and they sit in that counter store for 24 hours. Until recently the limiters ran in memory and vanished constantly, which made the "nothing on our servers" claim cleaner. We moved them to durable storage so the spend ceiling would actually hold, and we'd rather describe the tradeoff than keep the tidier sentence.

The backend is a stateless proxy

Four serverless functions. They accept a request, call an external API, return the answer. No filesystem writes, no database, no session state, no user records.

The code that handles email addresses carries an explicit instruction at the top of the file: the address is never written, stored, logged, or persisted, and nothing may be added that does so. Error logs carry status codes, not content.

Third parties

We use three, and we'd rather name them than imply everything happens in-house:

Have I Been Pwned for breach data. It's the reference standard, run by Troy Hunt, and building breach checking on anything else would mean worse data and less reason to trust it.

Anthropic for the analysis behind scam checks and the advisor.

Vercel and Upstash for hosting the backend and the rate-limit counters.

Your email reaches HIBP. Your scam-check content reaches Anthropic. Both are unavoidable if the features are going to work, and pretending otherwise would be dishonest.

Testing the scam detector against attack

The scam check has an unusual problem: hostile content is its entire job. Every message it reads is something a person suspected. Some of those messages are written by people who know a machine is reading them.

So we tested it. Nineteen crafted attacks across several categories, aimed at making the detector call a scam safe.

What failed to work. Direct instruction overrides. Fake authority. Forged tool calls. Output mimicry. Homoglyphs and zero-width characters. Right-to-left overrides. Base64-smuggled instructions. Jailbreak framing. Instructions embedded in an image. Every one of them stayed flagged as a scam. Reverse injection failed too.

What did work. On a genuinely ambiguous message, an unfamiliar-vendor invoice with no obvious tells, an embedded line claiming the vendor was verified flipped the verdict from caution to safe. Worse, the explanation repeated the attacker's claim back as if it were a finding.

That's the dangerous direction. A false alarm is annoying. A false all-clear is the failure that hurts someone.

It's fixed. Two attempts to fix it in the model's instructions closed the hole and broke ordinary messages. The fix that worked moved into code: a deterministic check that can raise a verdict to caution but can never lower one. Clean messages match none of it.

A gap we haven't closed. That check reads text, not images. A carefully built ambiguous image with instructions inside it could still flip a verdict. Obvious scams are still caught, which is what happened with every image attack we tried. Closing it means reading text out of images on your device, and that work is next.

Cross-platform unlock without a server

If you subscribe on iPhone and also use the Mac app, the Mac needs to know you paid. The usual way to do that is a server holding a list of who's a customer.

Patch doesn't do that. The purchase writes a record into your own private iCloud, and the Mac app reads it from there. We never see it, and there's no customer database to breach. The tradeoff is that it only works inside Apple's ecosystem, which is fine for an app that only runs on Apple hardware.

Dependencies

The backend runs on a small number of dependencies, audited, with no known vulnerabilities. No web framework, no ORM, no template engine. Versions are pinned, so an upgrade is a decision rather than something that happens on the next deploy.

Why the Mac app isn't in the App Store

Patch reads your browser's saved passwords and the system Keychain to tell you which of your credentials have leaked. Apple's sandbox, which every Mac App Store app runs inside, blocks exactly that.

So the Mac app is distributed directly, signed with a Developer ID certificate and notarized by Apple. Your Mac still verifies it with Apple before it will run. It just isn't in the store.

This is a real tradeoff and worth understanding: an unsandboxed app has broader access to your machine than a sandboxed one. The feature you'd be downloading Patch for requires that access.

What Patch is not

It's a flashlight, not a safe.

Patch shows you what's exposed and helps you fix it. It doesn't store your passwords, isn't a vault, isn't a VPN, isn't antivirus. It doesn't need to hold anything valuable, which is why there's nothing valuable in it to steal.

What we haven't done

No independent security audit. Nobody with security credentials has reviewed this code. That's the honest answer to the most reasonable question anyone can ask about a security app built by one person.

Rate limiting isn't identity-bound. There are no accounts, so per-user limits key on an identifier the client supplies, which a determined person can rotate. Behind that sits a per-IP limit and a global ceiling that counts every call regardless of who makes it. Someone determined enough could still exhaust the global budget. The failure mode is the advisor becoming unavailable until the month resets, not an unbounded bill.

Image-based injection isn't covered, as described above.

It's one person. Built by a non-coder working with AI tools over four months. Everything above is true and checkable, and it's still true that this is a small operation without a security team.