Your Own Machine Is the Attack Surface: Leftover Credentials, Permission Flags, Untrusted Input

When people talk about AI security, attention usually lands on the model: will it say what it shouldn’t, can it be talked around. That layer really is unstable. Claude is normally so morally upright — won’t do this, won’t do that. But somehow with Baidu it suddenly cooperates with jailbreaks. Looks like Dario has some unspecified trauma from his Baidu days.

I’m not drawing a grand conclusion from that. I just don’t think you can rest your sense of safety on “the model will hold the line by itself.” The things that actually bite you are all sitting on your own machine.

Layer one: the residue you leave on your own disk

Scanned ~/.codex/shell_snapshots/ and found one snapshot exporting 16+ API keys in plaintext, with 0644 world-readable file permissions.

Nobody attacked me. I did this to myself, just by using the tool. To restore the shell environment it writes everything that was exported into the snapshot, and the keys end up lying there, readable by anything running on that machine. Whether the model behaved has nothing to do with whether that file exists.

Layer two: the permission flag you waved through

There are already plenty of horror stories about rm -rf online. Never run that with dangerously skip permission enabled.

That reads like common sense, but it’s the same underlying problem as the previous layer: what hurts you is the scope of authority you handed over, not the model’s judgment. That flag means “I’m not asking anymore.” It won’t make an exception and come back to check with you because a command happens to be dangerous. You gave the whole decision away the moment you turned it on.

Layer three: the untrusted input you let it read

Ordinary folks don’t need to reach for Mythos — Sonnet 4.6 wired up to an MCP can help analyze suspicious malicious emails too. “The email was crudely made, the template placeholders weren’t even swapped out” — I wouldn’t have noticed that if it hadn’t pointed it out. Just remember to tell the model not to click unfamiliar links, unless you have a proper sandbox.

This layer is the capability and the risk at once. I pointed the model at an email I didn’t trust, and it caught something my eyes had skipped. Unswapped template placeholders really are the kind of thing you don’t notice unless someone says it out loud. But that same move means I fed untrusted content to something holding tool permissions. So the reminder isn’t a formality: don’t click unfamiliar links, or else give it a proper sandbox.

The three layers add up to one checklist

These happen in three different places, but you can walk them as one list:

One, scan your machine for plaintext keys lying around, including snapshot directories the tools generate themselves, and check whether the file permissions are 0644 while you’re there.

Two, don’t enable dangerously skip permission for dangerous operations.

Three, when you feed untrusted input to a model, say out loud that unfamiliar links are not to be clicked — or give it a proper sandbox.

None of the three asks you to understand how the model works inside, or to judge whether this week’s jailbreak got patched. All of them happen on the side you control.

I wrote earlier about capability boundaries and de-identifying private data, which was about what shouldn’t go out. This one points the other way: even if you send nothing out, the residue, the flags, and the input are still sitting on your machine.

Whether the model says the wrong thing isn’t up to me. These three are.

One more: don’t brute-force sites that need a login

Honestly, for sites that need a login, I always tell regular users not to go head-to-head with them—just find a third-party scraping database API.

The reason is simple: your token is your account. Push it too far, and the moment the admin drops a “two-dimensional foil” on you, your account is gone. The two-dimensional foil is a reference from The Three-Body Problem. It means a dimensional-reduction strike—the other side doesn’t argue with you, it just flattens you. I had a precious old account I’d used since 2012, and I lost it because I got reckless myself.

Use a throwaway, you say? The time cost of producing throwaways could go toward plenty of other things. So hand it to a professional scraping API, pay a little, and offload the risk. Throwaway-account scraping is their specialty, and going toe-to-toe with anti-scraping doesn’t scare them.

Technically you can of course have an agent log into a backend and crawl it page by page—but being able to do it isn’t the same as it being something you should do yourself.

Merged in: Two Everyday API Key Habits

Would you really let an agent register an API key itself and leave that key sitting in plaintext in the session log?

Also: next up, scan the company website pages daily to see whether a manager has hardcoded an API key into the front end.

Folded In: Every External File Goes to the Sandbox First

When I have Codex read my mail, the habit I set for it is that every external file gets isolated in a sandbox first. So when I see other people getting burned by something attached to an email, nothing happened on my end.