TL;DR: Extend what you already run instead of building a separate AI security program. Small teams win by treating AI as a change to identity, data protection, software delivery, and network access, then approving one AI building platform rather than governing several. The same guidance showed up on client calls from March through September 2026.
One person. That's the entire security staff at a well-funded company I saw described in September 2026, and the manager above that person splits time with infrastructure and IT operations.
The AI mandate on that desk is the same one landing on hundred-person security teams. Inventory the agents. Approve the use cases. Say yes fast enough that nobody routes around you.
That profile keeps repeating. A credit union with three people in August 2026. A law firm with six at the end of that month. A CISO in 2026 facing a 24-month rule that every department had to adopt AI, with one full-time person as the whole intake gate and a plan to hire a second.
I've watched a lot of these teams start by asking what an AI security program should look like. That's the wrong first question, and it's an expensive one.
Should a small security team build a separate AI security program?
No. Build the AI work as a change to programs you already run. A standalone AI security program needs its own policy set, its own review board, its own tooling budget, and its own headcount, and you have none of those to spare.
So stop scoping a new program and start scoping a delta. Ask what's different about an AI agent compared to the things you already govern, then change those specific controls.
That advice showed up across client calls for six straight months in 2026. A federal financial regulator in March was told to fold AI into existing DevOps and identity and Zero Trust work. A railway in July was told to extend the identity governance and privileged access platforms it already owned. A regional bank in July got the same answer for identity. The guidance stayed the same as the team sizes changed.
Here's the sizing that made it concrete. For a team of seven to ten people, AI security is a delta to established practice, not a parallel track. The investments you already made in identity governance, in conditional access acting as your policy decision point, and in zero trust network access are directly reusable for agents, which is why it pays to check what you own before buying an AI security tool. A policy decision point is just the thing that sits in the path and decides whether a request goes through. It doesn't care whether the requester is a person.
What existing work does AI security actually attach to?
Four places, and you almost certainly have some version of all four already.
Identity. An agent needs its own identity, not a shared service account and not the credential of the person who launched it. That's your identity governance system doing what it already does, with a new kind of account in it.
Data protection. Classification and access rules decide what an agent can read and what it can write. Your existing labels apply. The new part is that an agent reads far more of them per hour than a person does.
Software delivery. Agents write code and pull packages now. Your code review, your pipeline controls, your approved package sources, and your release gates all still apply. The reviewer changed, not the review.
Network access. Agents reach outside systems. Your zero trust network access investment gives you a single controlled path, and a single controlled path is where policy can actually be enforced.
Notice what's not on that list. There's no new platform to buy and no new committee to convene. You're adding agent-shaped rows to systems that already have owners and budgets.
That's what makes it survivable at three people. Every one of those four already has somebody accountable for it. You're editing their scope, not creating a fifth thing with nobody's name on it.
How do you handle AI intake without a review board?
Fold it into the risk review you already run, and add an AI-specific form plus a simple registry. That's it. A small team at a financial firm in July 2026 did exactly that and it held.
Don't create a separate AI approval committee. Committees produce deliberation, and deliberation is the thing you can least afford when one person is the gate.
The form does the work a committee would have done, and it can be short. Who owns this agent by name. What data can it reach. What can it change. What happens if it goes wrong and can you undo it. Those questions are how you settle what approving an AI agent actually means, and a form gets them in writing without a calendar invite.
The registry can be a spreadsheet at first. What I care about is that every agent has one accountable human and a scope written down. You can upgrade the tooling later. You can't retroactively assign ownership to fifty agents nobody claimed.
Should you approve one AI platform or govern all of them?
Approve one and govern it well. That same small team approved a single agent-building platform rather than trying to write governance for several competing ones, and it was the right call for their size.
This is a real tradeoff and I want to be honest about the cost. You'll get complaints. Somebody's preferred tool won't be on the list, and they'll have a decent argument. You're trading a little goodwill for the only thing that makes the math work.
Because governing two agent-building platforms isn't twice the work. Each one has its own identity model, its own logging format, its own permission scheme, and its own release cadence that breaks your assumptions on a schedule you don't control. A three-person team can hold one of those in their heads. Two is how programs stop being real without anyone announcing it.
Large teams can afford heterogeneity and often can't avoid it. If you're small, single-platform is a real advantage, and it's temporary. You can add the second one after the first is boring.
How do you decide what work AI should touch first?
Use a simple gate. If your team can describe the work, measure it, and check it today, AI can speed it up. If you can't do those things with humans doing the work, an agent can't be trusted or audited on it, and it isn't ready.
That gate came out of a 2026 call and I've used it since, because it cuts through the demo-driven conversation fast. It's not about whether the technology can do the task. It's about whether you'd be able to tell if it did the task badly.
Then move in stages rather than jumping to autonomy.
Augment. The assistant drafts and suggests. A person does everything else. Low risk, and it generates the telemetry you'll need later.
Supervise. The agent proposes an action and a human approves it. This is where most production work should sit right now.
Automate. Only after you have evidence from the supervise stage that the agent is right often enough to rely on, for this specific task.
Treat a new agent the way you'd treat an intern. Narrow scope, and immediate demotion when it gets something wrong. An intern who makes a bad call doesn't get their access reduced next quarter. It happens that afternoon.
What should a three-person team do in the next month?
Write down which existing program owns each piece. Identity, data protection, software delivery, and network access each get a name next to them. Ten minutes, and it prevents the "we need an AI program" conversation from restarting every month.
Add four questions to the risk intake form you already use. Owner, data reach, change authority, and undo path. Don't build a new form if you have one.
Pick one agent-building platform and publish the decision. People route around silence faster than they route around a no.
Start the registry as a spreadsheet today. Named owner and scope per agent. Perfect is the enemy here.
Run the describe-measure-check gate on your top three requested use cases. The ones that fail the gate aren't rejections, they're a list of what to instrument first.
Count your approval turnaround. If saying yes takes more than a week, that number is your real governance problem, and no amount of policy fixes it.
Key takeaways:
Small teams should treat AI security as a delta to existing practice, not as a standalone program with its own board and budget.
Guidance to extend existing identity, DevOps, and Zero Trust work rather than build parallel programs repeated across client calls from March to September 2026.
The four attachment points are identity, data protection, software delivery, and network access, and each already has an owner you can extend.
Fold AI intake into the risk review you already run, with an AI-specific form and a simple registry, instead of forming an approval committee.
Approving one agent-building platform is a real advantage at small scale, because each additional platform brings its own identity model, logging format, permission scheme, and release cadence.
Use the describe-measure-check gate before automating anything, and move through augment and supervise stages before granting autonomy.
Frequently asked questions
Isn't "extend what you have" just an excuse to not invest in AI security?
No, and the distinction is where the money goes. Extending means you fund agent-specific changes inside identity governance, data classification, pipeline controls, and network access policy. That's real spend with real work attached. What it avoids is funding a parallel program that duplicates governance you already pay for.
What if leadership wants to see an AI security program?
Show them the four attachment points with owners and dates next to them, and call that the program. Leadership usually wants evidence that somebody's accountable and that work is scheduled. A one-page view of extended controls delivers that faster than a new org chart does.
At what team size does a dedicated AI security function make sense?
There's no clean threshold, and anyone who gives you one is guessing. What I'd watch instead is whether the agent population has outgrown the intake path. When your existing risk review can't absorb the volume without slipping past a week, that's the signal, regardless of headcount.
How do you handle a mandate that every department must adopt AI?
Get the single approved platform published early, because a broad mandate with no sanctioned path produces shadow adoption within weeks. Then make intake fast enough that compliance is easier than avoidance. One CISO facing a 24-month mandate across HR and legal and every other function was running it through a single full-time gate, with the second hire as the plan.
Does a spreadsheet registry really work?
For a while, and better than the alternative of waiting. A spreadsheet with a named owner and a written scope per agent gives you the two facts you'll need in an incident. Move to a real registry when the spreadsheet stops being accurate, which it will, and you'll know exactly which fields you actually need by then.
Where does Zero Trust fit for a small team?
Zero Trust is the foundation, and for a small team it's also the budget argument. Verify every request and grant the least access needed. Assume something inside is already compromised. The conditional access and network access work you already funded applies to agents with almost no change, which is the cheapest security you'll get all year. Agents need one more check on top of that foundation, which is a judgment about how much autonomy a given agent has earned.
The hardest part of this isn't technical. It's holding the line on a single platform while somebody with more political weight than you explains why their tool should be the exception.