Matt Goodrich

I started this project to replace Paperless-ngx.

The first safety change I made for my agents was the one that does the least.

Every recurring failure in the loop ends up as one of two things: a line in a policy file, or a small script that cleans up after it.

Where the queue lives decides what the work costs.

In Agents Don’t Travel Well I called pasting screenshots into a remote Claude Code session my biggest day-to-day gripe with the whole setup.

I did not set out to build a patchwork.

Every platform team has the same argument eventually, and it never ends the same way twice.

A request comes into your product carrying a real, authenticated user.

Set the rule: no corporate laptops, and no VPN.

A ticket for production access sits in a queue for three days.

Every time we came back to authorization in the product, the model had grown.

For most of the history of access control, logging in was a one-time decision.

Put your secrets in one vault.

I was most of the way through writing about break-glass access when I realized I had only written the prevention half.

Grant someone read access to a database and you have made a decision about a system.

The problem that started this was not philosophical.

A user calls GET /invoices/4471 and gets back an invoice.

A VPN does one thing well and one thing badly.

Zero trust gets sold two wrong ways at once.

You can prove exactly who is making a request and still have no idea what they are making it from.

A phishing page can copy your login screen perfectly.

The pitch for role-based access control is clean and convincing.

Single sign-on solved logging in.

When a new hire cannot log in on day one, you hear about it within the hour.

I almost did not write this one.

At 3am the database is down, the on-call engineer needs in, and the system that normally grants access is part of what is broken.

Every plan to get the secrets out of your workloads runs into the same wall.

Count the identities in your company.

“No standing access” is the goal everyone agrees on and almost nobody can explain the mechanics of.

This is the map for the identity series: one argument about building identity security for the company you actually have, broken into posts you can read in any order.

The pitch for workload identity is clean.

A developer has permission to assume one role.

I started writing a different post.

A simple question that most engineering organizations can’t answer: which code in our repos was written by AI, which was written by humans, and who is accountable for each?

The protocol wars everyone braced for in 2025 are over, and they ended in a way most of the predictions missed.

The shape that made AI useful for access reviews fits a lot of other compliance work too.

Every quarter, an email arrives.

The articles arguing that MCP is going away in favor of direct API calls with workload identity are half right.

The MCP authorization spec was written for an AI client with a browser and a user who can click through consent.

An AI agent is not a user, and permissioning one like a user is the most expensive shortcut in the AI rollout.

An AI agent’s identity is a non-human identity, and ninety percent of what governs it is decades-old hygiene.

In the last post I argued that the value stream needs an owner.

Your company has an org chart.

The first security hire at a company is asked to be seven specialists at once.

Open any LinkedIn feed in 2026 and you’ll find someone insisting that AI agents will rm -rf production any minute now.

.env was already a compromise.

AI just hits different.

The first time I opened the BlackDuck API documentation, I thought building a vulnerability collector would take a couple weeks.

A CISO once said to me, “Vulnerability management is easy.

I recently picked up Team of Teams by General Stanley McChrystal, and one concept from the book has been rattling around in my head ever since — the distinction between complicated and complex.