Verify NoxKey for yourself
Don't take our word for it. macOS ships with the tools you need to confirm that NoxKey can't make network connections, can't silently read files outside its sandbox, and hasn't been tampered with. A handful of commands, all running in Terminal.
Apple's tools, not ours.
Run these in Terminal. NoxKey can't change the output.
What NoxKey can't do
NoxKey ships as a signed, sandboxed app. The sandbox profile is embedded in the signed binary and enforced by the macOS kernel — not by NoxKey.
The network client entitlement is not granted. The kernel drops any socket, DNS lookup, or HTTP request NoxKey attempts.
com.apple.security.network.client — absentThe network server entitlement is not granted. NoxKey cannot bind a listening TCP or UDP socket.
com.apple.security.network.server — absentNoxKey has read-only access to five specific agent config paths (Claude Code's two configs, Cursor, Windsurf, Claude Desktop) and write access only to its own sandbox container. Any other file access requires you to hand it the file through a macOS Open/Save dialog — the sandbox rejects silent reads of your home directory, Documents, or other apps' data.
com.apple.security.temporary-exception.files.home-relative-path.read-onlyNoxKey's Keychain access group is limited to dev.noboxdev.noxkey. It cannot read or modify items stored by other apps.
The signed entitlements
This is the exact sandbox profile embedded in NoxKey's signed binary. The command in the next section dumps this same XML live from the installed app.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.security.temporary-exception.files.home-relative-path.read-only</key>
<array>
<string>/.claude.json</string>
<string>/.claude/settings.json</string>
<string>/.cursor/mcp.json</string>
<string>/.codeium/windsurf/mcp_config.json</string>
<string>/Library/Application Support/Claude/claude_desktop_config.json</string>
</array>
<key>keychain-access-groups</key>
<array>
<string>$(AppIdentifierPrefix)dev.noboxdev.noxkey</string>
</array>
</dict>
</plist>
Ask your AI to verify
If you use Claude Code, Cursor, Windsurf, or any MCP-capable agent, paste the prompt below into its chat. The agent runs the checks with its own Bash tool, shows you the raw output, and explains what each result means. NoxKey isn't involved — the agent is using Apple's verification commands directly.
Copy this into your AI agent
The prompt tells the agent to show you the raw output, not just summarize — so trust doesn't silently transfer from NoxKey to the agent. You still see what Apple's tools actually reported.
Verify that the NoxKey app installed on this Mac is sandboxed and untampered. Run each command below with your Bash tool, show me the raw output of each, then tell me in plain language whether the result looks right. Don't just match my "Expected:" line — use your own judgment. If something in the output looks concerning even though it technically matches, flag it. If something technically deviates but is obviously benign, explain why. 1. codesign -d --entitlements - /Applications/NoxKey.app Checks: what does the macOS sandbox allow this app to do? Expected: com.apple.security.app-sandbox = true; NO com.apple.security.network.client or network.server keys anywhere; exactly 5 paths under com.apple.security.temporary-exception.files.home-relative-path.read-only (Claude Code, Cursor, Windsurf, Claude Desktop configs); keychain-access-groups scoped to dev.noboxdev.noxkey. Flag: any network.* entitlement, any unexpected file paths, or a different keychain group. 2. codesign --verify --deep --strict /Applications/NoxKey.app Checks: does every file inside the bundle still match Apple's signature? Expected: exits silently (no output, status 0). Flag: any output at all — it means the bundle was modified after signing. 3. spctl -a -vv /Applications/NoxKey.app Checks: does Apple's Gatekeeper accept this app, and where did the signature come from? Expected: "accepted" with source = "Mac App Store". Authority lines typically name Apple's App Store signing chain (e.g. "Apple Mac OS Application Signing") — Apple re-signs MAS apps, so the developer name isn't guaranteed to appear. Flag: "rejected" or a source that isn't "Mac App Store". If the authority text looks unusual, review the full chain before concluding the bundle is compromised. 4. pgrep -xl NoxKey Checks: is exactly one NoxKey process running? NoxKey must be open for commands 5 and 6 to work. Expected: one line, named "NoxKey". Flag: multiple processes or any with a suspicious name — could indicate an impostor binary running under the same label. 5. lsof -p $(pgrep -xo NoxKey) Checks: what files and sockets does the running NoxKey process have open? Expected: local files inside ~/Library/Containers/dev.noboxdev.Noxkey/ and a Unix domain socket at /tmp/noxkey-sock-*. NO IPv4 or IPv6 rows. Flag: any rows where the TYPE column is IPv4 or IPv6. 6. lsof -i -P -p $(pgrep -xo NoxKey) Checks: does NoxKey have ANY inbound or outbound network socket — listener or connection? Expected: empty output. Zero rows. Combined with check 1 (no network entitlements) this proves the kernel blocks inbound/outbound network I/O entirely — it isn't just that none is happening, the sandbox makes it impossible. Flag: ANY output row — every one means NoxKey holds an IP socket, which shouldn't be possible. After running all six commands, structure your reply like this: === TOP-LINE SAFETY VERDICT === Lead with a single paragraph answering this question in your own words: "Based on what these commands actually show, is this app safe to use for storing sensitive information like API keys, passwords, and tokens?" Give me a clear recommendation — Safe, Cautious, or Unsafe — and the one reason that drives it. Don't hedge unnecessarily, but don't overclaim either. === SUPPORTING ANALYSIS === Now back up the verdict with your own cross-checks: - Are the results internally consistent (e.g. entitlements say no network AND lsof shows no IP sockets)? Call out any contradictions. - Did you notice anything suspicious the mechanical Expected/Flag lines above might miss: unusual signing identities, strange file paths, surprising open handles, odd process state, wrong Gatekeeper source, duplicate processes? - Threat-model briefly: could anything in this output let NoxKey exfiltrate data, persist beyond its sandbox, or read other apps' secrets? === OPTIONAL NEXT STEP === If the first six checks pass and the user wants extra assurance, recommend they run (themselves, with sudo): sudo nettop -p $(pgrep -xo NoxKey) -l 2 -x — live-samples network traffic. Don't run it yourself; it needs the user's password.
Or run them in Terminal yourself
Paste each command into Terminal. If anything looks off, the sandbox isn't enforcing what we claim — and NoxKey can't hide the mismatch because it doesn't run these commands.
1. Dump the live entitlements
Read the exact sandbox profile baked into the signed binary.
codesign -d --entitlements - /Applications/NoxKey.app
app-sandbox true, files.user-selected.read-write true, the five temporary-exception.files.home-relative-path.read-only paths, and the keychain-access-groups entry. $(AppIdentifierPrefix) is expanded at signing, so the live output shows a Team ID prefix — that's normal. No com.apple.security.network.client or network.server keys anywhere.
If you see network keys: the binary you installed isn't the one we ship. Stop using it and reinstall from the Mac App Store.
2. Confirm the binary is untampered
Check that the signature still matches every file inside the app bundle.
codesign --verify --deep --strict /Applications/NoxKey.app
Any output —
a sealed resource is missing or invalid, not signed at all, etc. — means the bundle was modified after Apple signed it. Don't trust it.
3. Ask Gatekeeper who signed this app
Apple's own acceptance check — also prints the signing authority chain.
spctl -a -vv /Applications/NoxKey.app
accepted, with source=Mac App Store. Authority lines typically read Apple Mac OS Application Signing chained up to Apple — the App Store re-signs submissions, so the developer name isn't guaranteed to appear.
If rejected, or the source isn't "Mac App Store", the bundle on disk isn't the App Store build we ship. If only the authority text looks unusual, walk the full chain before treating it as tampering.
4. Confirm exactly one NoxKey process is running
NoxKey must be open for the next two commands. This also catches an impostor binary running under the same name.
pgrep -xl NoxKey
NoxKey.
Multiple processes or a suspicious name means something else is using the label — don't trust the remaining checks until you investigate.
5. Inspect every file handle NoxKey has open
List sockets, pipes, and files the running process is holding.
lsof -p $(pgrep -xo NoxKey)
~/Library/Containers/dev.noboxdev.Noxkey/, a Unix domain socket at /tmp/noxkey-sock-*, and standard system libraries. No IPv4 or IPv6 rows.
If you see IPv4/IPv6 rows: NoxKey has an open network connection. That shouldn't be possible without the network.client entitlement — file a report at [email protected].
6. Prove network I/O is impossible, not just absent
Filter the running process for any Internet socket — inbound, outbound, or listening.
lsof -i -P -p $(pgrep -xo NoxKey)
Why this proves impossibility: command #1 already shows the sandbox doesn't grant
network.client or network.server. This command is the runtime counterpart — NoxKey holds zero IP sockets because the kernel rejects every attempt to open one. Any line of output would mean the sandbox isn't enforcing the entitlement profile, which shouldn't be possible without a macOS bug.
7. Live-monitor network traffic
Watch NoxKey for any packet it sends or receives while you use it.
sudo nettop -p $(pgrep -xo NoxKey)
Why sudo:
nettop needs root to attach to another process. Requires entering your macOS password — this isn't a command you'd bake into automation, it's the one you run when you want live proof.
How NoxKey is distributed
NoxKey is shipping exclusively through the Mac App Store. Every build is signed with a No Box Dev certificate and goes through Apple's manual App Review before it reaches you — a human at Apple inspects the entitlements, the sandbox profile, and the binary itself against the App Store guidelines on every update. The macOS App Store is the only install path; there is no side-channel updater baked into the app.
The sandbox profile above is part of that signed binary — it cannot change at runtime. Shipping an update that quietly added network access would require a new binary with different entitlements, a fresh App Review pass, and a new App Store release. Command #1 (codesign -d --entitlements -) would immediately show the difference on the copy running on your Mac.
Command #3 (spctl -a -vv) should report source=Mac App Store. A different source — or any other authority chain — means the binary you're running isn't the one we published through Apple.
Limits — what this doesn't prove
We can't yet prove the signed binary matches our public source. NoxKey is open source under MIT at github.com/No-Box-Dev/Noxkey, but we don't ship reproducible builds today. You can read the code and you can verify the signed entitlements — bridging the two requires a reproducible build, which is on our roadmap.
A root attacker with SIP disabled can replace /Applications/NoxKey.app. At that point, any app on your Mac is at risk — not just NoxKey. Apple's Gatekeeper and SIP raise the bar; they don't eliminate it. Command #2 above (codesign --verify --deep --strict) is how you detect tampering after the fact.
Report a security issue
Found something that contradicts the claims on this page? Email [email protected] with the output you saw and the command you ran. We read every report.