Those permissions were sized for 40 tickets a day

Opsin Labs put out its first State of Agentic Adoption report on August 5, and one line in it does most of the work. Of the agents that were provisioned past default settings, 60 percent were given allow-all access instead of the permissions their task actually needed. The same report counts roughly one agent per employee across the environments it looked at, with 67 percent of them built by people who do not work in engineering.

The interesting question is not why so many agents ended up with everything. It is where the permissions came from in the first place.

At RSA this year, Zenity’s Chris Hughes described the pattern plainly in an interview on the show floor. Organizations are taking the identities from humans, he said, and inheriting those permissions to the agent. Nobody sat down and wrote a policy. Somebody wired the agent into the tools using the access a person already had, because that access already existed and already worked.

What a support rep’s access actually is

Picture the shipping and returns rep at a 40 person ecommerce company. Four years in, their account can issue refunds, edit a shipping address, cancel and reissue an order, apply store credit, change the email on file, and pull up any customer record by name.

None of that was designed. Each permission got added on some Tuesday when a ticket was stuck and a manager said fine, just give them the button. The set is a sediment of small unblocking decisions, and it is completely normal. Almost every support team in the country has one.

That set was safe, and it is worth being precise about why, because none of the reasons are the permissions themselves.

It was safe because the rep handles about 40 tickets a day, so the worst possible Tuesday has a ceiling. It was safe because they can smell a refund request coming from an account whose email changed nineteen minutes ago. It was safe because a manager sits ten feet away, and 300 refunds in one hour gets noticed before lunch. It was safe because a person who is unsure stops and asks.

Copy that account onto software and every one of those conditions disappears. The permissions are the only part that survives the move, and they were the part carrying the least weight.

The failure mode is already measurable

This has stopped being a thought experiment. The Cloud Security Alliance and Token Security surveyed enterprises for a report published in April and found 65 percent had at least one security incident involving an AI agent in the prior year. Sixty-one percent of those led to data exposure, 35 percent to financial losses. Eighty-two percent of respondents discovered agents running that they had not known about. Only 20 percent had any process for decommissioning an agent, which means retired agents keep their credentials.

Microsoft’s security team published guidance in July that says the right thing: give every agent its own identity, build roles around discrete units of work rather than around a team, and expose only an approved list of tools. Good advice. It is also asking a 40 person company to run an access review program, and that company does not have a security team. It has an owner who wanted the returns queue to stop eating her Sundays.

Grant the topic, not the login

The version of this that works for a small business is not an audit. It is refusing to hand over the keyring in the first place.

Access should be granted the way the work is actually shaped: one topic at a time. Where is my order gets read access to order status and nothing else. It gets that only after the agent has practiced on the company’s own past tickets and the owner has looked at what it would have said. Refunds are a separate decision, made later, on purpose, by someone who understands that refunds move money.

Underneath the topics, every tool gets classified before the agent may use it, and a tool that writes is not the same object as a tool that reads. If nobody has said what a write tool does, the agent does not get to find out. It drafts, and the action is held.

That is the design of how Celeste works. Practice first, live one topic at a time, and the agent never grades its own homework. The agent proposes an action and ordinary code, not the model, decides whether the action is allowed. An owner graduating a topic is making a small, reversible decision about a bounded thing, which is a decision a person without a security team can actually make well. What that looks like day to day is a list of topics the agent has earned and a list it has not.

The industry spent this year measuring how capable these agents are. The number that predicts your bad week is the other one. Not what the agent can do. What it is allowed to touch, and who decided.

Go look at whatever account your support automation is running as. Somebody chose those permissions, years ago, for a person who could only work so fast.