Every new hire gets a badge, and enterprises have spent decades deciding which doors that badge opens. AI agents show up without one, so the quickest fix is to clip the agent onto the badge of the person whose work it automates and let it through every door that person can open. That person's access was built for an entire job, from payroll questions to the occasional favor for a colleague in finance, while the agent was brought in to do one bounded task very quickly and very often. The standards world is already treating borrowed access as a security problem. This year NIST began gathering input on identity standards for agents, and OWASP now ranks identity and privilege abuse among the leading risks in agentic systems. In energy and health care, an agent wandering through borrowed doors can end up at the power grid or a patient chart.
Dr. Nell Meshcheryakov is the Strategic Advisor of Responsible AI at Dominion Energy, where she works within the CTO organization on AI governance and risk as projects move from experimentation into production. She previously founded and led the global AI Center of Excellence at Strategic Education, Inc., setting standards for Responsible AI and model risk management, and wrote her doctoral dissertation on algorithmic bias. Her working rule is that an agent gets the data and systems its task requires, and nothing beyond them.
"We're shifting from managing models, which is what we've done traditionally, to managing the actions of agents," Meshcheryakov says. This means deciding what an agent can touch before it touches anything, and she made that case on stage at Ai4 this year against the shortcut that looks harmless the week before launch.
An agent isn't its human operator
Mirroring is the shortcut she warns against, where an agent automating someone's work simply inherits that person's access along with everything attached to it. "I put forward in that panel that we really cannot just mirror a human's access, because the amount of context the human has, and the amount of access they have, might be much larger than what the agent needs."
Her alternative gives each agent a defined persona of its own, built around a single function and the specific data sources and systems it requires. "You might have a persona that's very specific to invoice tracking and finance. That persona needs these specific data sources, these specific places of access, and you don't give it anything beyond what it needs," she says. The persona becomes the boundary an agent operates inside, much narrower than a human role. Some security architects apply similar logic when they tie approvals to one use case and let them expire when the work changes.
She illustrates it with a hypothetical university admissions process run by a chain of agents, where one agent's only task is checking each application and passing it along. The admissions staffer who once did that work carried a footprint shaped by an entire role. "You can't just mirror their access, because they need access to HR, they need access to their peers, they need access to different databases that don't have to do with application processing," Meshcheryakov explains. Once defined, a persona like that can be reused wherever the same task appears across the business. "If you create repeatable personas, then you don't have to reinvent the wheel."
Consequences set the strictness
Working inside a utility shapes how far she pushes the principle. "If I were a financial services company and an agent did something it wasn't supposed to, you're probably going to ruin a day for a couple of people. There might be some zeros missing. That's definitely not ideal, and I'm not saying that's low stakes, but it's different from lives on the line," she says. The consequence of a wrong action should set how tightly an agent is bounded, and in health care and energy, that means thinking much harder about what an agent could set in motion and how to contain it. Banking leaders have reached a similar conclusion, drawing autonomy limits around mistakes that can't be undone.
Companies already running multi-agent systems don't need to start over. Their first move is locating the highest-risk data and systems and walling agents off from them, regardless of what the humans nearby can see. "Even if the human had access to that data, if that's not a part of what the AI needed, you're not giving it access," Meshcheryakov says. A tight starting scope also matters as tasks run longer, since an agent's access can outlast its authority once conditions shift mid-workflow.
Scoping access costs hours up front
Governance for autonomous agents is still young, with only one in five companies reporting a mature model for governing them. Meshcheryakov describes persona design as part of planning work teams already do, alongside process maps and data access decisions. "It might take a longer time in the short run, but in the longer run you'll have assurance that it's not going to go off and do anything crazy outside the bounds of what you've given it."
When teams balk at the extra setup, she asks them to weigh what happens without it. "That often makes people say it's probably worth the extra two hours we'd spend thinking about what access it needs, over coming back and cleaning up an incident later." A clear problem statement shortens the work further, she adds.
The most restrictive permission setting of all is leaving an agent out of a workflow entirely, and she pushes teams to consider it first. "Make sure that you're not using a Lamborghini to transport your lumber," she says, noting that a traditional ML model or a plain application sometimes handles the job at lower cost and risk. When a conventional tool can do the work predictably, the permissions question never has to be answered at all.
As agent chains grow longer, every handoff becomes another decision about what the next agent gets to see, and each one reopens the question of whether that seat needs an agent in it. "You want to make sure that AI doesn't have any way to get to the places that are non-negotiables for you," Meshcheryakov says.
