Every agent needs an owner
If nobody can say who owns an agent, nobody can say what it is allowed to do. Give each one a name, an owner, a short list of tools and access that runs out.
The 60-second version Open
- Ask a team how many agents they run, then ask who owns each one. The second answer is usually shorter.
- An owner is the person who answers for an agent: its thresholds, its tools and its mistakes.
- Write four things down for every agent: its name, its owner, the tools it may call, and when its access ends.
- Give access per task, and let it expire. An agent should hold what one step needs, not everything it might need.
- Any agent without an owner goes back to read-only until someone claims it.
Ask a team how many agents they run and you'll get a number. Ask who owns each one and the answer gets shorter. One was built in a hackathon, one came with a vendor tool, one belongs to someone who has moved team. They all still run.
That gap matters because an agent that can act is making decisions on someone's behalf. If nobody can say who owns an agent, nobody can say what it is allowed to do, and nobody notices when it starts doing something else.
An owner is a person, not a team
The owner is the one person who answers for the agent. They chose its thresholds: when it acts on its own, when it asks for review, when it escalates. They approved the tools it may call. When it makes a mistake, they are the one who reads the log and decides what changes.
A team name doesn't do this job. "Platform owns it" means everyone can assume someone else is watching. Put a name on it, and a second name for when that person is away.
An agent nobody owns is an agent nobody is checking.
Four things to write down
This week IBM made its Agent Identity product generally available. The details are specific to IBM, but the shape is worth copying whatever you use: register each agent in one inventory, record who owns it, classify its risk, and list the tool connections it is approved to use.
You can start with a spreadsheet. For every agent that can change anything, write down its name, its owner, the tools it may call, and the date its access should be reviewed. If a row has an empty owner, you have found your first problem.
Access that runs out
The second idea in IBM's design is the more useful one: short-lived, task-scoped tokens. Instead of a standing key that can do everything the agent might ever need, the agent gets access for one step, and it expires. Where a system can't accept that kind of token, a vault hands out a credential for that one target, just in time.
This is the same rule as giving a person access. You wouldn't give a new hire the admin password on day one in case they need it later. An agent earns wider access the same way: by showing, in its logs, that it decides well with narrow access first.
What to do this week
List every agent that can write, send, pay or delete. Give each one an owner by name and a review date. Any agent nobody claims by Friday goes back to read-only until someone does. Then look at the tools column: anything an agent can call but hasn't called in a month is access it doesn't need.
A new essay arrives every Sunday.
Discussion