Agent Guardrails: A Field Guide to Safety & Permissions

Summary

Everyone wants an agent they can let run. Hand it a goal, walk away, come back to finished work. The thing standing between you and that is trust, and trust isn't something you get by hoping the model behaves. You get it by building guardrails: the sandboxes, permission gates, and human checkpoints that make it safe to give an autonomous agent real reach. An agent you have to watch every second isn't saving you any time. Guardrails are what let you stop watching.

This is a field guide to building them. We start from the uncomfortable truth that an agent is non-deterministic, can be steered by the untrusted text it reads, and will eventually do something you didn't predict, so safety has to be a property of the system around it, not a promise from the model. Then we build the layers: containing the blast radius with a sandbox, sorting actions by how badly they can go wrong, gating the risky ones with permissions, and putting a human in the loop exactly where it counts and nowhere it doesn't. We cover prompt injection (why your agent can be turned against you by a web page) and how to defend against it, and we close on the failure modes and a checklist.

It's the counterweight to the rest of this series. The other guides are about making an agent more capable and more autonomous; this one is about doing that without handing it a loaded gun. Get it right and you can finally let the thing run.

This is a living document and will be updated as the tools and patterns evolve.

Loading Why You Can't Just Trust the Model…

Loading Think in Blast Radius…

Loading The Sandbox…

Loading Sort Actions by Risk…

Loading Permissions and Gates…

Loading The Human in the Loop…

Loading Prompt Injection…

Loading Defending Against Injection…

Loading Secrets and Credentials…

Loading Failure Modes and a Checklist…

Do you like my content?

Sponsor Me On Github

Keep reading

AI Project Management: Shipping Software When Agents Write the Code

Something strange happened to my job this year. The typing got cheap. An agent can turn a paragraph of intent into a working pull request while I refill my coffee, and yet the projects did not get faster. Not really. More code shipped, more PRs merged, and somehow the same features took roughly the same number of weeks to actually land. That gap is what this guide is about. When machines write the code, the scarce thing is no longer the writing. It's the specifying, the slicing-up, and the reviewing. Project management stopped being about handing out work and started being about feeding agents instructions clear enough that their output is worth keeping, then catching the parts that aren't. I've been running this way for a while now: specs before code, work cut into agent-sized pieces, a small fleet on separate worktrees, and a review loop that assumes the machine got something subtly wrong. This is the playbook I wish someone had handed me. It covers spec-driven development, decomposition, acceptance criteria an agent can test against, parallelism without chaos, the review loop, governance for code you didn't write, and the handful of metrics that tell you whether any of it is actually working. It's written for engineers and tech leads who already use agents to write code and want to run real projects with them, not demos. _This is a living document and will be updated as the tools and the workflows keep evolving._

Read guide

Agent Memory: A Field Guide

Two people give the same agent the same task and get wildly different results. Most of the time it isn't the prompt. It's that one of them gave the agent a memory and the other is re-explaining themselves at the start of every session. A model is stateless by default: brilliant for ninety seconds, then a blank slate. Memory is the layer that turns a clever one-off into a teammate that knows your codebase, remembers the decision you made last week, and gets better the longer it works with you. This is a field guide to building that layer on purpose. We start with why agents forget and the taxonomy that makes the rest make sense (working, episodic, semantic, procedural memory) then build it the way you actually should: plain files first, one fact per file, before any vector database. From there we get into the parts everyone underestimates: deciding what's even worth remembering, getting the right memory back out (retrieval is the hard half), and what to do when a memory goes stale and starts lying to you. We cover the scoping decisions, shared brain vs. per-agent, per-user vs. per-project, the read-before-act / write-after loop that makes memory compound, and when to graduate from files to a real store with versioning and redaction. It's a companion to [Building Your Agentic OS](/guides/building-your-agentic-os) and [Running the Fleet](/guides/running-the-fleet), where those build the system around the agent, this one goes deep on the single pillar that most changes how an agent feels to work with. By the end you'll have a memory you can stand up this afternoon, and the judgment to know what to put in it and what to leave out. _This is a living document and will be updated as the tools and patterns evolve._

Read guide

Agent Skills: A Field Guide to the Third Pillar

Your agent can write code. But does it know how your team cuts a release? Can it run your incident playbook the same way twice, or does it improvise something a little different every time? That gap, between raw capability and a repeatable way of doing one specific job, is exactly what skills fill. A skill is procedural memory you write down once: a packaged, reusable how-to that the agent loads when it's relevant and runs the same way every time. This is the third leg of a trilogy with [Agent Memory](/guides/agent-memory-field-guide) and [The Agent's Self](/guides/agent-self-personality-identity), the three pillars from [Building Your Agentic OS](/guides/building-your-agentic-os). Identity is who the agent is, memory is what it knows, skills are how it does things. We start with what a skill really is, and what it isn't, then build one from a plain folder and a single file. We dig into the two halves of the craft that actually matter: writing a description that makes the agent reach for the skill at the right moment, and writing a body that makes it succeed once it does. We cover progressive disclosure (why the whole skill isn't sitting in context all the time), how to tell a skill apart from a memory or a tool, and how to version and share skills across a fleet without letting them rot. By the end you'll be able to take a capable, general-purpose agent and turn it into a specialist that does your specific jobs your specific way, on demand, every time. _This is a living document and will be updated as the tools and patterns evolve._

Read guide