Running Security with a Lean Team in the AI Era

When people say the attack surface has exploded, it can sound like a slogan. But it's real, so let's make it more concrete.

A couple of years ago, everyone on your team quietly got the ability to build software and host it, using tools you cannot govern the way you used to.

Here's how that looks:

• Proprietary company data is running through models on personal accounts. No enterprise controls, no retention settings, no idea where it lands. It is ordinary convenience, and convenience is exactly how these things spread.
• People are building real software on top of your company data and shipping it overnight, using hosting that is trivial to stand up. The old name for this was shadow IT. It used to be a spreadsheet macro and a rogue server. Now it is a full application with a public URL.
• Agents are operating inside production with real credentials, making infrastructure changes and clicking the buttons a person used to click. That breaks the question you have always relied on: who did this, and who is accountable for it. Identity gets its own play in Chapter 4.

Meanwhile, AI-generated code fails in ways human code does not, in three distinct ways:

• Frontier models are verbose and defensive, and they gold-plate things you did not ask for, burying the real logic under a layer of detail you no longer understand well enough to defend.
• Open-source models can be fine-tuned to introduce a specific weakness on purpose. Pull one from a third party you do not really know, and you are trusting them the way you would trust a new hire, with less ability to tell.
• Even setting intent aside, these models learned from software that was itself insecure, so they produce the same old vulnerabilities, and now they produce them faster than ever.

What these share is that none of them came through the front door. Data going into personal model accounts, an app spun up overnight, an agent holding production credentials, model-written code merged at speed: each one adds to what you have to defend, and each one arrives without passing through you first.

That is why the surface is both bigger and harder to see, and why it grows again every week. Keeping pace with it by hand stopped being realistic a while ago, and that is the problem the rest of this guide is built to solve.

When the surface grows faster than you can cover by hand, the obvious move is to hand the work to AI: the scanning, the triage, the fixing. That instinct is right. Just aim before you fire, because automation pointed at the wrong work only gets you to the wrong place faster.

Start by deciding what actually matters.

Start with understanding where the damage actually comes from. For all the energy we spend on models that can find some deep, esoteric bug in a library you may not even use, the companies I watch get hurt are still getting hurt the old way. Ransomware. Phishing. Someone on the team handing over their password to a person posing as IT. These problems have been here forever and they will be here for a long time. The thing that is broken, more than any single control, is our perception of where the risk lives. While we are looking at the exciting new threats, we're getting hit by the old boring ones.

The second thing I want you to sit with is that the hard part of this job was never fixing issues. It was deciding what to fix. When I could not prioritize, the highest-signal thing I could do was pay someone to actually attack me, because an attacker's critical findings break the tie for you. Fixing the thing, once you know it matters, is usually the easy part. Choosing the thing is the work.

That leads to the order of operations I would give anyone standing up or rebuilding a function right now.

What this looks like in practice

Say you are a fintech that handles payments. Your real risks are concrete: PCI compliance, fraud, and the integrity of what you process. That is step one, the business and its risks.

The controls follow from there. You make sure inputs are validated and well tested, you segregate duties, and you keep your keys and secrets away from the people writing the code. Those are the control points your risks demand, step two.

Only then do the tools earn their place: QA tooling, high unit-test coverage, and proper secrets management. Each one is there because a specific risk called for it, step three.

The mistake I see, and it is the tell of someone earlier in their career, is coming at it from the other end. "Here are the tools I love from my last job, I will set them up, now I feel secure." That is the tool angle, and it feels productive. The risk angle is slower to start but it is the one that holds up long term.

Once you know what matters, the next question is who does what. Some of the work can run without you, and some of it should never leave your hands. Telling those two apart, and drawing the line deliberately, is what lets a small team keep pace without giving away the decisions that carry its name.

The line itself is simple to say and harder to hold: give the machine the throughput, and keep the judgment for yourself. Draw it on purpose, and build the function around it instead of around your queue.

Give the machine the throughput:

• Continuous scanning across your surface
• First-pass triage against the context you've written down
• Prepared responses to routine events, where a known trigger fires an action you defined in advance
• The fix itself, more and more of it

Keep the judgment for yourself:

• What the business is and where its real risk lives
• Where your attention goes this quarter
• The bounds the machine operates inside
• The calls that are expensive to get wrong

I will tell you where I personally hold the line, because it is maybe more conservative than you would expect from someone who runs as much through models as I do. We are an AI-native company. Nearly all of our code, a lot of our detection rules, just about everything we produce goes through a model first. We describe goals, we build loops, we let agents respond to events and act on their own. And I still have a human approve every pull request. I do it so that I know a person looked, and so the change that just went into production has a name attached to it. That is my line. Yours might sit somewhere else. The point is that you draw it on purpose, and you draw it around decisions, not around tasks.

This is the chapter I would have wanted when I started. It is the how. Five plays, roughly in the order I would do them.

1. Write your context down so a machine can reason with it

This is the highest-leverage thing you will do, and almost no one does it. If you want a model to triage your findings well, it needs to know what you know: what your business does, how your systems fit together, what you actually care about protecting. So write it down. Put your threat model in a markdown file. Be explicit about what would hurt and what would not. I have long believed policies should be treated like code, written in Markdown, versioned in Git, reviewed in pull requests. This is the same idea, pointed at triage.

Do this now

Open one file today and write the first page of your threat model in plain language: what the business does, the two or three things that would genuinely hurt, and the systems that touch them. That page is what lets a machine ignore the noise that does not apply to you.

2. Design the loop and the gate

Automation without a check is just faster guessing. For any job you hand a machine, define the goal, and then build an automated gate that inspects the result. The gate is what lets you compare: when a model changes, or a new tool arrives, is the outcome better than before or worse. Without the gate you are trusting a vibe.

Do this now

For one workflow you want to automate, write the goal in a sentence and the single automated check that proves it worked. Do not automate the workflow until the check exists.

3. Verify without reading every line

People freeze here, because trusting a machine to fix security feels like too much. Here is how I think about it. I write a lot of code I do not read line by line anymore. I trust the result, and I test that it works.

Securing code is the same. You do not need to trust every step, you need to trust the final state, and you build the system that proves the final state. In code, that is a pull request with CI running your tests. In security work, it is your scanners and detectors confirming two things: you did not open anything new, and the hole you meant to close is actually closed. As long as that holds, and the path the machine took stayed inside the bounds you set, that is a result I will put my name on. Trust, but verify, and make the verification automatic.

Do this now

For an automated fix, define the exact evidence you need before you sign off. Usually it is nothing new exposed and the original finding no longer reproduces. Wire those checks so they run every time.

4. Label what's good and what's bad, and feed it back

The skill that compounds from here is not doing the work, it is teaching the system. You get good at labeling: this finding mattered, this one did not, this fix was right, this one missed. Feed those labels back so the next pass is better than the last. Over time that is most of the job, and it is worth getting deliberate about early.

Do this now

Keep a running record of your triage decisions with a one-line reason. That record is training data, and it is how you onboard the next person, human or otherwise.

5. Give agents their own tight identity

Because agents now act in production, treat their identity as seriously as a person's. There are two patterns, and you pick one per agent, on purpose.

Delegated. The agent acts on behalf of an employee, and that employee stays accountable. In AWS terms, think delegated roles: a human authorizes the agent, and if it goes off the rails, you still know whose responsibility it was. Simpler, because there is always a person on the hook.

Autonomous. The agent lives in your chat tools and acts on its own, like the Hermes and OpenClaw style bots, or something like Claude Tag. Treat it like a new employee: its own account, its own tightly scoped access, isolated to exactly what it needs.

Do this now

Inventory every agent with production access. For each one, decide delegated or autonomous, and scope its access to match.

As more of the security work runs on machines, the job itself starts to change shape. Day to day, you do less of the work by hand and more of the work of building and running the system that does it. That is a real shift in what the role is, and it is already the direction the strongest lean teams are heading.

The shift I see, in my own work and everywhere this is done well, is that you end up doing two distinct kinds of work: you get very good at labeling data, and you get very good at building systems. You define the goal and the loop, you build the gate that checks the result, and you say what is good, what is bad, what is better, what is worse, and feed that back. Over time, that is most of the job.

Your week shifts toward:

• Writing and maintaining the context a machine reasons from.
• Setting the goals and the bounds, then tuning them as things change.
• Labeling outcomes so the next pass is better than the last.
• Making the handful of calls that genuinely need a human.

That is also how a team of one or two stays a team of one or two and keeps pace anyway. You do not scale by adding people. You scale by moving your effort up a level, from doing the work to building the thing that does the work. Stay lean on purpose.

The way you get ahead of all this is one small thing at a time. Security has always worked this way, as a steady stream of small improvements that compound, and the teams that stay ahead are the ones that keep making them instead of waiting for a perfect redesign.

Two habits carry most of the weight. Get your non-negotiables in early, because they are far easier to put in place at the start than to retrofit later. And do not let the big unfinished thing block the small one you could finish today. If you are staring at a secrets migration that will take a month, but there is a setting you could fix in twenty minutes, fix the setting. It is the same idea as brushing your teeth for two minutes a day. Individually trivial, and over time it compounds into the thing that actually keeps you safe.

So if you take one thing from this guide, make it a small move you make now:

• Write the first page of your threat model today: what you do, what would genuinely hurt, and the systems that touch it.
• Write the one check that tells you an automated job did its work.
• Hand a machine its first job, inside the bounds you set.

That is the whole method, and it starts with a page you can write this afternoon. The hardest part is starting. So start small, and let it compound.

Everything in Chapter 4 leans on one artifact, so here it is. This is the page a machine triages against, and it is the fastest way to make automated triage stop wasting your time on things that do not apply to you. Keep it short and honest: a rough map that exists beats a perfect one that does not. And treat it like code. Put it in your repo, version it in Git, and revise it in pull requests as the business changes, the same way you would treat a policy or any other artifact you actually intend to maintain.