verifiedagents.ai
All posts

7 min readAI Agents · Cybersecurity

How a Three-Person Security Team Governs AI

By Michelle Savage, Experience Design Director, PayPal

Hero: Small Team AI Governance

TL;DR: A small security team shouldn't build a separate AI security program. Treat AI as a change to four things you already run: identity, data protection, software delivery, and network access. Fold intake into your existing risk review and approve one agent-building platform. Keep a registry with a named owner per agent.

Last updated October 6, 2026. This piece was rebuilt from the ground up for the teams of one to six who keep getting the same mandate as teams of a hundred.

One person. That's the entire security staff at a well-funded company 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 reaching hundred-person teams: inventory the agents and approve the use cases, and say yes fast enough that nobody routes around you. The profile keeps repeating. A credit union with three people in August 2026. A law firm with six. A CISO facing a 24-month rule that every department adopt AI, with one full-time person as the whole intake gate. Most of these teams start by asking what an AI security program should look like. That's the wrong first question, and an expensive one.

Should a small team build a separate AI security program?

No. Build the AI work as a change to programs you already run. A standalone 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 what you already govern, then change those specific controls.

That advice held across client calls for six straight months in 2026. A federal financial regulator in March was told to fold AI into the identity and Zero Trust work it already ran, alongside its existing DevOps controls. A railway in July was told to extend the identity governance and privileged access platforms it already owned. A regional bank the same month got the same answer. The team sizes changed. The guidance didn't. For a team of seven to ten, AI security is a delta to established practice, not a parallel track, and the conditional access and network access work you already funded applies to agents with almost no change.

What existing work does AI security attach to?

Attachment point

What changes for agents

What stays the same

Identity

Agents get their own accounts, never shared service credentials

Your identity governance system and its owner

Data protection

An agent reads far more labeled data per hour than a person

Your classification labels and access rules

Software delivery

The reviewer changed, not the review

Code review, pipeline controls, approved package sources

Network access

Agents reach outside systems constantly

Your zero trust network access path, where policy gets enforced

Notice what's not on the list: no new platform to buy, no new committee to convene. You're adding agent-shaped rows to systems that already have owners and budgets. That's what makes this survivable at three people. Each of the four already has somebody accountable. 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, with a short AI-specific form and a simple registry. A small team at a financial firm did exactly that in July 2026, and it held. Don't create a separate AI approval committee. Committees produce deliberation, and deliberation is what 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, and what happens if it goes wrong, including whether you can undo it. Those are the same questions behind AI agent approval criteria, and a form gets them in writing without a calendar invite.

The registry can start as a spreadsheet. What counts is that every agent has one accountable human and a written scope, because you can upgrade tooling later but you can't retroactively assign ownership to fifty agents nobody claimed. The ownership model is in who owns your AI agent.

Should you approve one AI platform or govern several?

Approve one and govern it well. The same small team approved a single agent-building platform instead of writing governance for several competing ones, and at their size it was the right call.

Be honest about the cost: you'll get complaints, because somebody's preferred tool won't make the list and they'll have a decent argument. You're trading a little goodwill for the only thing that makes the math work. Governing two platforms isn't twice the work. Each one brings its own identity model, its own logging format, its own permission scheme, and a 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. And the constraint is temporary: add the second platform 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 three things with humans doing the work, an agent can't be trusted or audited on it either. The question isn't whether the technology can do the task. It's whether you'd be able to tell if it did the task badly.

Then move in stages. Augment: the assistant drafts and a person does everything else, which is low risk and generates the telemetry you'll need. Supervise: the agent proposes and a human approves, which is where most production work should sit right now. Automate: only after the supervise stage proves the agent is right often enough, for this specific task. Treat each new agent like an intern with a narrow scope and same-day demotion when it gets something wrong, the model we walk through in onboard your AI agent like an intern.

What should a three-person team do in the next month?

  1. Write down which existing program owns each piece.

    Identity, data protection, software delivery, and network access each get a name. Ten minutes, and it stops the "we need an AI program" conversation from restarting monthly.

  2. Add four questions to your existing risk intake form.

    Owner, data reach, change authority, undo path. Don't build a new form.

  3. Pick one agent-building platform and publish the decision.

    People route around silence faster than they route around a no.

  4. Start the registry as a spreadsheet today.

    Named owner and scope per agent. Perfect is the enemy here.

  5. Run the describe-measure-check gate on your top three requested use cases.

    The ones that fail aren't rejections. They're the list of what to instrument first.

  6. Count your approval turnaround.

    If saying yes takes more than a week, that number is your real governance problem, and no policy fixes it.

Frequently asked questions

Isn't "extend what you have" an excuse not to invest in AI security?

No, and the distinction is where the money goes. Extending means funding agent-specific changes inside identity governance, data classification, pipeline controls, and network policy. That's real spend with real work attached. What it avoids is 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 the work is scheduled. A one-page view of extended controls delivers that faster than a new org chart.

At what team size does a dedicated AI security function make sense?

There's no clean threshold, and anyone who offers one is guessing. Watch whether the agent population has outgrown the intake path instead. When your risk review can't absorb the volume without slipping past a week, that's the signal, whatever your headcount.

Does a spreadsheet registry really work?

For a while, and better than waiting. A named owner and written scope per agent are the two facts you'll need in an incident. Move to a real registry when the spreadsheet stops being accurate, and by then you'll know exactly which fields you need.

Key takeaways

  • Small teams treat AI security as a delta to existing practice, not a standalone program with its own board and budget.

  • The four attachment points are identity, data protection, software delivery, and network access, and each already has an owner.

  • Fold intake into your existing risk review with a short AI form and a spreadsheet registry. No committee.

  • One approved agent-building platform is a real advantage at small scale, and the constraint is temporary.

  • Describe, measure, check: if you can't do all three on a task today, an agent isn't ready to automate it.

Want to see which of the four attachment points needs work first? The free self assessment takes about ten minutes.

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. Hold it anyway.

See where your agents stand.

The free assessment takes ten minutes and scores you on the five elements of the Agentic Trust Framework.