Most people building with AI agents right now came from AI. They learned prompting, then RAG, then agents, then — usually the hard way — that an agent with tool access and no guardrails is a liability wearing a demo. I came at it from the other direction. Twenty years in security operations, then agents. The order matters more than it sounds like it should.
the failure mode nobody demos
Every AI agent demo shows the happy path: the agent reads a ticket, calls a tool, resolves the issue, done. What it doesn't show is the agent that gets a malformed input, retries in a loop, burns through an API budget, or — worse — takes an action it shouldn't have because nothing was watching for that. Security work is entirely about that second category. Not "does the system work" but "what does it do when it's attacked, confused, or fed something it wasn't built to handle."
That's not a mindset AI experience teaches you. It's one incident response teaches you, one bad patch Tuesday teaches you, one social-engineering call that almost worked teaches you.
what actually transfers
A few specific habits from security ops carry over into agent design almost unchanged:
- Least privilege, applied to tool access. An agent that can read a database doesn't need write access to it. An agent that drafts emails doesn't need permission to send them unsupervised. This is the same principle as scoping a service account — just applied to an LLM instead of a daemon.
- Assume the input is hostile, even when it isn't. Prompt injection is phishing with extra steps: content designed to make a trusted actor do something it shouldn't. Anyone who's built email filtering rules already has the right instincts here.
- Logging as a first-class requirement, not an afterthought. You can't investigate what you didn't record. Every agent action on this fleet is logged for the same reason every firewall rule change used to be logged — because six months from now, someone (possibly future-me) needs to know what happened and why.
- Guardrails that fail closed, not open. A security control that silently disables itself under load is worse than no control at all, because it creates false confidence. The same is true of an agent's safety checks.
None of this is exotic. It's the boring, unglamorous 80% of security work that never makes it into a conference talk — and it's exactly the 80% that's missing from most agent deployments right now, because the people building them have never had to clean up after an incident.
the fleet as a case study
The fleet running this site is the practical version of that mindset: agents that plan and execute work in the background, with permission boundaries, action logging, and a design that assumes something will eventually go wrong and asks "what happens when it does" before asking "what can it do." Sentinel Prime exists because "let the agent do whatever it wants" is not a security posture, it's an incident waiting for a postmortem.
why this matters for hiring
If you're evaluating who to bring in for AI agent work, the honest question to ask isn't "have they built an agent." Plenty of people have built an agent. The question is whether they've ever been on call at 3am for something that went wrong in production, because that's the experience that actually predicts whether the agent they build for you fails safely or fails expensively.
Twenty years doesn't make the AI part easier. It makes the part where things go wrong survivable — and that's the part that actually costs money when it's missing.