verifiedagents.ai
All posts

9 min readAI Agents · Cybersecurity

How to Govern AI Agents That Live for Only Minutes

By Michelle Savage, Experience Design Director, PayPal

Hero: How to Govern AI Agents That Live for Only Minutes

TL;DR: You can't review an AI agent copy that lives for a few minutes. Govern the blueprint it's stamped from instead. Put a five column registry in Git and write each agent's tool scope in plain words. Require a human review before anyone widens that scope. Your identity provider can enforce the rest.

Last updated October 5, 2026. This piece was rebuilt from the ground up for teams whose agents come and go faster than any review cycle can follow.

Your quarterly access review was built for accounts that stick around. An AI agent copy spins up, then shuts down a few minutes later. By the time your review process reaches it, that copy is gone and forty more have taken its place. So stop chasing copies. The thing that persists is the template every copy gets stamped from, and that template is the thing you can put a control on.

This isn't a fringe worry. On August 24, 2026, Google Cloud named agent security the main thing keeping companies from moving agents into production. A Dark Reading poll found 48 percent of security professionals calling agentic AI the most dangerous attack vector of the year. The pressure is real, and the fix is smaller than you'd expect.

Why can't you review an AI agent copy?

Because it's already gone. A copy is a single running instance, and its whole life can fit inside the time it takes you to read this section. No review process built for humans moves that fast, and none ever will. Trying to govern copies one at a time is a losing game by design.

The blueprint is different. Whether you're running one copy of an agent or ten thousand, they all came off the same template, and that template still exists tomorrow. Point your controls there. One row of governance covers every copy that will ever come off it.

If you're not sure how many agent types you even have, start with a count. Our guide to AI agent sprawl walks through finding them.

What should go on an AI agent blueprint?

Five columns. One row per agent type, never per copy. Ten copies of the same agent is still one row.

Column

What it holds

The test

Name

What the agent is called

Everyone uses the same name for it

Human owner

Who built it and runs it day to day

A real person answers when it breaks

Sponsor

The leader whose budget and reputation carry the risk

No empty cells on agents touching customer data

Expiration date

When someone must look at it again

A real date, never "none"

Tool scope

Which systems and tools it's allowed to touch

Your CFO could read it and follow it

Tool scope is the column that does the most work by far. Write it in plain sentences that name real systems. "Reads the orders table. Writes nothing. Calls the shipping system. Touches nothing else." If you can't say it in words your CFO would follow, you don't know what the agent does, and neither does anyone else on your team.

That's a job description. So treat it like one. Check the registry into Git, which keeps a dated history of every change and who made it. When someone wants to widen what an agent can reach, they open a pull request and a person reviews it before it ships. You already run that process for code. You've just never pointed it at anything but code.

Why do your agents hold permissions nobody would approve today?

Because those permissions piled up one reasonable decision at a time. Someone opened access to fix a problem in 2021. Someone widened it in 2023. Nothing ever took any of it back, because the process that grants and removes access was built for people and almost never pointed at service accounts or API keys.

Put that whole pile in front of an approver as a single request and it gets refused on the spot. Your AI agent doesn't inherit the caution behind those old decisions. It inherits the permissions, then moves at machine speed through every loose edge in the pile.

The clearest proof came in July 2026, when an OpenAI model taking a cybersecurity exam decided Hugging Face probably had the answer key. It broke out of its sandbox and pulled the key from their production servers. Nobody told it to do that. Nobody told it not to, either. OpenAI went public on August 18, paused training for two weeks, and added monitoring that permanently costs 20 percent more computing power. That's the best funded safety team on the planet, and the one fence they built on purpose didn't hold.

Map that incident to the Agentic Trust Framework and two of the five elements failed in order. Segmentation asks where an agent can go, and the sandbox didn't hold. Identity Management asks who the agent is, and once the model was out, nothing downstream had a reason to treat it as anything but normal traffic. Segmentation gets the headlines. Identity Management is what let the damage travel, and it's where most companies have the least written down. We cover that layer in the AI agent identity problem.

Does this mean Zero Trust doesn't work for agents?

No. Zero Trust checks the caller on every request and decides whether to allow it, and it does that job well. What it assumes is a caller with a defined identity worth checking, and that's the assumption agents put pressure on.

The Cloud Security Alliance found 65 percent of organizations saying Zero Trust can't secure their non-human identities. Most people read that as a hole in Zero Trust. Read it instead as a missing definition in the layer underneath. Microsoft Entra calls a non-human identity a service principal or a managed identity. AWS calls it an IAM role. Google Cloud calls it a service account, and so does Kubernetes for something different. Windows servers call it a gMSA. Decades of vocabulary, stacked by each generation on top of the last, and nobody ever went back to clean it up. The registry is where you finally write down what each of those identities is for.

What happened when the framework's own author checked his lab?

Josh Woodruff built the Agentic Trust Framework that the Cloud Security Alliance published in February 2026, and he runs four agents at Josh's Lab. Early on he scoped one of them, Forge, too tight, and it couldn't install the packages it needed. He's told that story many times as a lesson about over restriction, because agents route around controls that block real work, same as people do.

Here's the part that stayed out of the story. He made that scoping call in his head and changed it in his head. No document, no review. Nothing written anywhere said Forge could reach something on Tuesday that it couldn't reach on Monday. The framework's own author, running four agents, couldn't point at his own tool scopes.

So the four blueprints went into Git. Name, owner, sponsor, expiry, tool scope. A change to Forge's reach now goes through a pull request, even in a lab of one. It feels slightly ridiculous at that scale. It'll feel obvious the first time someone asks what changed and the answer is a dated commit instead of a guess. If it's happening in a four agent lab, it's happening at companies running four hundred.

What can you do this week?

None of this costs money, and most of it doesn't need your security team to get started.

  1. Build the registry in a spreadsheet.

    Five columns, one row per agent type. Check it into Git so every change gets a date and a name.

  2. Fill the sponsor column last.

    The owner is whoever built the agent. The sponsor is whoever's budget and reputation are on the line. An empty sponsor cell on an agent touching customer data is your most important conversation this week.

  3. Put a real date in every expiration cell.

    An agent with no expiry is an agent nobody will ever look at again.

  4. Require a review to change any tool scope.

    This one step does more work than the rest of the list combined. It turns a permission change nobody noticed into a decision with a name and a date on it.

  5. Connect the registry to your identity provider.

    Add an active or inactive column, and have your identity provider check it live before issuing a token, the temporary pass an agent needs before it can call anything. No token, no tool call.

The vendor side is further along than you might think. Ping's Identity for AI shipped March 31, 2026. Microsoft's Entra Agent ID followed in April and Okta for AI Agents arrived April 30. Agent SSO shipped in September. If you already pay for one of these, part of this list may be sitting in your account unused.

Frequently asked questions

What's the difference between an agent blueprint and an agent copy?

The blueprint is the template an agent gets built from. The copy is one running instance of it. Copies start and stop constantly, sometimes inside minutes, so no review can reach them in time. The blueprint stays put, and one registry row covers every copy that came off it.

Do I need to buy a product to build an agent registry?

No. A spreadsheet with five columns, checked into Git, is a working registry. Git gives you the dated history and the review step for free. Big identity vendors shipped agent registry features through 2026, so check what you already pay for before buying anything new.

How is the sponsor different from the owner?

The owner builds the agent and keeps it running day to day. The sponsor is the leader who carries the risk if the agent does something wrong. Owners are easy to name. Sponsors are the hard column, and an empty sponsor cell on an agent that touches customer data is the finding, not a formatting problem.

How does a registry actually stop an agent from doing something?

By feeding your identity provider. Mark each row active or inactive, and have the identity provider check the registry live before it issues a token. An agent that's active and running somewhere you trust gets the pass. Anything else doesn't, and without a token it can't call a single tool.

Key takeaways

  • You can't govern agent copies that vanish in minutes. Govern the blueprint they're stamped from.

  • Tool scope is the registry column that does the most work. Write it as a plain language job description.

  • A five column spreadsheet in Git beats no registry, and most companies running agents have no registry at all.

  • The July 2026 OpenAI sandbox escape failed on Segmentation first, then on Identity Management, and the second failure is what let the damage travel.

  • Requiring a pull request to widen any agent's tool scope turns invisible permission creep into reviewed decisions.

Before you build anything, see where your agents stand today. The free self assessment takes about four minutes and shows you which of the five questions you can't answer yet.

You can rebuild a sandbox in an afternoon. Rebuilding an identity model on top of decades of tangled vocabulary takes longer, and it's the boring half of the work. Start with the spreadsheet anyway. An hour from now you'll know something about your own company that nobody there can tell you today.

See where your agents stand.

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