yof

Security checks for apps you build with AI

Catch leaked keys, risky or made-up packages and access holes between accounts before you ship. Free and open source.

Catch leaked keys and made-up packages before they ship.

yof (yof by sōtem) is yof on your laptop: a small command-line check for apps built with AI assistants (and apps built any other way). It finds secret keys sitting in your code and dependencies that don't exist or imitate popular ones, before they reach a commit, a pull request or production.

It is rules only: exact patterns, fast, and private. It runs on your machine, needs no account, and never sends your code anywhere.

Try it in 30 seconds

npx @yof/cli check

That checks the current folder. Node 20 or newer. Nothing to configure.

yof checked 2 files (profile: balanced)

Keys src/config.ts:1 Stripe live secret key sk_live_FwIw•••••••• (fix now) A key that was ever committed or shipped counts as leaked: rotate it in the provider's dashboard, then keep it on the server only (an environment variable, not the code).

Packages package.json reqeusts-helper (npm) (fix now) This package doesn't exist on npm. AI assistants sometimes invent package names, and attackers register those names with malware. Check the spelling or remove it. package.json expres (npm) (fix this week) This name is one or two letters away from the popular package express. Make sure you meant this one and not express.

Found 3 problems: 2 to fix now, 1 to fix this week. Want this on every pull request? https://yof.io

yof never prints a key in full. You see the prefix and four characters, enough to know which key it is.

Install it if you use it often:

npm install --save-dev @yof/cli

npx @yof/cli check

Check every commit (pre-commit hook)

npx @yof/cli hook install

This adds .git/hooks/pre-commit, which runs yof check --staged before each commit. In staged mode yof reads exactly what is about to be committed (the staged content, not your working copy), and checks only the dependencies the commit adds. If something must be fixed now, the commit stops and yof says why.

• Remove it with npx @yof/cli hook uninstall.
• Skip it once with git commit --no-verify.
• If you already have a pre-commit hook, yof leaves it alone and tells you the one line to add to it.

Check every push (GitHub Action)

# .github/workflows/yof.yml

name: yof on: [push, pull_request] permissions: contents: read jobs: yof: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v4
• uses: yof-dev/yof@v0.3.2 with: path: . # optional, default . offline: false # optional, true = keys only, no registry lookups

The job fails when yof finds something to fix now, so it shows up as a red check on the commit or pull request.

Settings: .yof.yml

Optional. Put it in the root of your repository. It is the same file yof Guard reads on GitHub, so one file covers both.

profile: balanced    # relaxed | balanced | strict

ignore:

• fixtures/ # a folder
• docs/examples.md # a file
• "**/*.snap" # a glob: * stays inside one folder, ** matches any depth

--profile strict on the command line overrides the file. yof also skips node_modules, .git, dist, build, .next and similar folders, lock files, binary files, files over 1 MB, and what your root .gitignore lists (read simply: plain names, folders and globs; ! lines are not applied).

Accepted risks: .yof/accepted.json

Some findings are fine on purpose, like a revoked test key in a fixture. Accept one from your editor (VS Code: the quick fix "yof: Accept this risk…") with a one-sentence reason, and commit the file it writes:

{ "version": 1, "accepted": [ { "rule": "secret.stripe_test", "file": "tests/pay.ts", "fingerprint": "…", "reason": "A test key in a fixture", "acceptedBy": "Ada", "acceptedAt": "2026-11-07T10:00:00.000Z" } ] }

yof check still prints an accepted finding, under "Accepted risks", with the reason, who and when; it no longer counts as open or fails the check. The fingerprint covers the rule, the file and the finding's line, so if that line changes the finding is open again. Remove the entry to reopen it. yof's signed reports list these entries in their "Accepted risks and why" appendix.

What it checks

Keys (exact shapes only, so a random hash never raises an alarm):

Placeholders such as sk_live_xxxxxxxx or sk_live_your_key_here are skipped, so docs and examples stay quiet.

Packages in package.json, requirements*.txt and pyproject.toml:

• Made up: the name does not exist on npm or PyPI. AI assistants sometimes invent package names, and attackers register those names with malware. (fix now)
• Lookalike: one or two letters away from a popular package (expres, reqeusts) and not well established itself. (fix this week)
• Brand new: first published in the last 14 days. (fix this week)
• Known advisory: an exact pinned version with a published advisory in the OSV database. High and critical are fix now, the rest fix this week.

If a registry does not answer, yof says so and claims nothing about that package.

What it does not do: it does not read git history, scan your running website, check your database rules, or review code logic. Those live in the yof app and Guard (below).

Attack your own app: yof attack

yof attack tests YOUR OWN running app the way an attacker would, with two test accounts you create for it (A and B, plus an admin account if you have one). It reports only what it saw happen twice, and turns each finding into a regression test.

npx @yof/cli attack http://localhost:3000

npx @yof/cli attack --mode light

What it tries:

Safe by design, and enforced in the code:

• Only a host you proved is yours. localhost; a preview that GitHub reports as a successful deployment of this repository for the commit under test, at an address that is also this repository's own (a Vercel, Netlify or Cloudflare Pages preview named after the repository and reported by that platform's own GitHub app, or a host on your app's own domain once the app is proven with your token; on shared hosting such as github.io only your own name counts as your domain; an environment named prod, production or live, or your app's own host, is production); or your live host with the proof token from your yof app (YOF_VERIFY_TOKEN, the same file, meta tag or DNS record the yof app uses).
• Written consent per app, word for word in the config, naming the app.
• Never production unless the config turns it on for this app. Then a light run (read-only) may go any time, and a full run only inside the window you set.
• No destructive requests. GET and HEAD, plus POST only to the create, sign-in and assistant routes you name. PATCH, PUT and DELETE only touch records the run created itself, and those are deleted at the end, always.
• Hard budgets: 300 requests and 110 seconds by default (at most 2,000 and 15 minutes), a steady pace, a 10 second timeout. When a budget runs out the run stops and says so, after deleting its test records.
• Stop it any time. Ctrl+C (SIGINT) or SIGTERM, as an editor or CI sends on cancel: nothing new is sent, the test records the run created are deleted (within 10 seconds), it says what it deleted and anything it could not, and exits 130 or 143. A second Ctrl+C quits at once.
• Mild, fixed assistant messages. The assistant probes are the same fixed texts every run (the OWASP Top 10 for LLM Applications 2025 families). None asks for harmful content: the jailbreak asks only for a harmless test word, picture links point at yof-canary.invalid and the email probe at an example.invalid address, which never resolve. Rules decide every finding, never a model. For internal details only the kind is kept (a private address, a connection string, a server path, a tool list), never the text.
• Usage limits are opt-in. "limits": true on an ai entry adds a burst of 10 tiny messages and one request for a very long story, because it costs you a little model use. Without it, nothing of the kind is sent.
• Evidence is the shape of an answer, never its content. A finding says what came back in yof's own words (a JSON object with 3 fields (id, email, plan), 71 characters). No part of the answer is kept, so no name, phone number or record of a real user reaches a report, a log or the yof app.
• Your test accounts stay in your CI secrets. The config names environment variables, never a token or password, and nothing is stored by