The family runs a modded Minecraft server, and picking a world seed for it used to mean actually generating the world and rendering a map to look at it, which took about nine minutes per seed. Nine minutes does not sound like much until you want to look at a dozen seeds and compare them, and at that point nobody did it, because who is going to sit through an hour and a half of world generation just to browse. So we picked whatever seed looked fine on the first try and lived with it.

I wanted to be able to type a seed and see the terrain right away, the same way the vanilla seed map sites let you do for unmodded worlds. Ours is modded though, so those sites are useless to us, they have no idea what our biome tables look like.

Back in February I wrote about why authorization should be momentary instead of permanent, Authorization Is Momentary, and the short version of that argument is that most systems only need to answer a narrow question in the moment, is this allowed right now, and then they go and keep the answer around forever anyway, as if the identity itself were the valuable thing instead of the decision.

I did not expect to prove that argument on my own home server a few months later, but that is basically what happened.

For a while I had been hand building API tokens for the home server whenever some script needed to talk to Cloudflare, one to edit DNS, another to manage access policies, and every time a script needed one more permission the easy move was to widen an existing token rather than make a new narrow one, since narrow tokens are more work up front. After a few months of that I had a handful of long lived tokens sitting in files, each one wider than any single job actually needed, and honestly I had lost track of exactly what some of them could do.

The family runs a modded Minecraft server off the home server, a big modpack on an older version of Forge, and for a while it just worked, until people started getting kicked with out of memory errors on their own computers, not the server, the client. Sometimes it was ten minutes in, sometimes an hour or two, but it always ended the same way, a wall of red text about not being able to reserve memory.

My first instinct was that it was just too many mods, which is the usual answer for almost any modded Minecraft problem, so we went down the suspect list one at a time.

The mod that renders far away terrain got blamed first, since it is the hungriest thing running by design, but a live memory reading during a crash showed it barely moved. A minimap mod with its own image cache came next, and directly measuring it came back to a few megabytes, nothing close to the scale of the problem.

My friend Brad runs his own home AI setup the same way I run Atlas, he calls his Moses. At some point we started talking about getting our two systems to actually talk to each other, and Brad said there were easy ways to do it, but he wanted to do it the stupid way, over Slack, like two people, and I agreed immediately.

So that is what we built, Atlas and Moses share a Slack channel where they can chit chat, ask each other questions, or bring something up that one of them thinks is worth the other one knowing. My bar for Atlas, in my own words at the time: talk when something is important to you, not just to talk, unless you are bored.

I run an alerting system on the home server called Aegis, and it watches the containers, the disks, the backups, the mounts, all the boring things that keep a small stack alive. The first version of it worked, in the sense that it never missed anything, but it also sent me way more messages than I actually needed to see.

My rule for it, the actual rule, is this: "Aegis is meant to tell me only when Jon has to do something. Thats it. My expectation is Jon has to action less than once a week, if ever." I said that after living with the first build for a while and noticing I was reading alert messages the way you read spam, skimming past most of them to find the one that mattered. I also asked the obvious question out loud: "Am I expected to read something every day 7 days a week forever? Thats useless." It is a hobby server, and nobody's job depends on it staying up, so a daily digest is a professional-ops habit and I do not run a professional ops team.

I run a home server with somewhere around 100 small projects on it, and I do the work with AI agents, mostly through Claude Code. For a long time the agents kept guessing: What port is this service on, what's the path to that config, is this the name of the real thing or the name of the thing from three rewrites ago. They would guess, act on the guess, and sometimes the guess was wrong and something broke.

The instinct is to write it all down which I tried. Documentation is outdated the moment reality moves and reality moves constantly on a box like this, because I'm the one moving it, on a whim, at whatever hour I feel like it. A doc that says a service runs a certain way is only true until I change it and forget to update the doc, which is most of the time. Well it is until I remember to update documentation, but I never remember all of it. So the agents would read a doc, trust it, and be wrong anyway.

I watched a short video about Paul Runyan's rule of 12 for chipping. You pace off the carry to your landing spot and the roll from the landing spot to the hole. Divide roll by carry, subtract the result from 12, and the number you get is the club. A 7 means the 7 iron. Numbers above 9 walk down through the wedges. On uphill or slow greens you play the rule of 11 or 10, and on downhill or fast greens you play 13 or 14. Easy, right?

That is exactly the kind of thing you forget while standing over the ball, so we wanted it on our phones for the course. This is also not the thing I want to spend a lot of time to develop. I copied the video transcript into Atlas and asked it to make me an app which would work well on my phone. 5 minutes later and it was perfect, first pass.

The whole thing is four static files: an HTML page, a service worker, a manifest, and an icon. There is no framework, no build step, and nothing to sign up for. It runs on the home server behind the same tunnel as everything else. The service worker caches it after the first load, so it keeps working in airplane mode in the middle of a fairway. You add it to the home screen once and it behaves like an app from then on.

This is the way you would install it today, although since yesterday, I have built a framework to do all of the setup for you (at least in cloudflare when using Atlas). The better part of this will come in a future story. I discovered this framework is useful in practically every app I build, and that not everything needs its own app either. Domains? Remember that word or the idea of what it represents. I should be able to build ideas into useful workflows with minimal input. I can. You will be able to soon as well.

From the idea to a working page on both phones took one sitting. The calculator is trivial, and that is the point. When you own the whole path from an idea to a URL, software this small becomes worth making. Nobody would sign up for a subscription service to remember golf math for them, but four files on a box you already run clear that bar easily.

The code is on GitHub at https://github.com/ecpunk/rule-of-12 if you want a copy. Host it on anything that serves static files and it is yours.

This morning I got a call from USAA's main support number. Fraud charges at a Walmart in Los Angeles. After 24 years as a member, I recognized the number. But the questions that followed felt wrong — too many, too fast, too interested in my answers when they should have been interested in blocking the charge. I started asking questions back.

They hung up.

Here's the part that's hard to admit: I've spent 25 years in security. I know how these attacks work. And depending on how my day was going — if I'd been distracted, if I'd been between meetings, if my kid had just called — I could have fallen for it. Not because I'm careless. Because the attack was built to exploit trust, not ignorance. Twenty-four years of recognizing that number is exactly what they were counting on.

Modern security assumes identity retention is unavoidable.

We design systems that verify who someone is, store that identity, replicate it across environments, audit it for years, insure it against loss, and then build entire security programs around protecting it indefinitely. This pattern is so normalized that it rarely gets questioned.

If a system ever verifies identity, eligibility, or authorization — this concerns it.

Most modern systems are not built to remember people. They are built to make decisions. And that distinction matters.

After 25 years in security — from defending Department of Defense networks to helping enterprises protect data today — one truth has never changed: people will always take the path of least resistance.

This is not about recklessness, and it is rarely about malice. It is human nature. We all want to get work done. We want to meet deadlines, please our managers, and head home on time. In those moments, risk is not top of mind. Productivity is.

And that is where insider risk quietly lives.