AI Agents Avoid Privilege Creep When Every Permission Traces Back To A Person

Enterprises are putting AI agents into production faster than they're deciding what those agents can touch. Many of them now run with credentials, reach the systems they're pointed at, and return what they find. Setting a ceiling on that reach is an access control problem, and the toolkit for it was built long before agents existed.

Itay Kozuch is Chief Information Security Officer at Navan. A veteran security executive, he previously served as Senior Director of Security at ZoomInfo where he led security engineering, architecture, red team, and the global AI security program, he served as CISO at Outseer and CISO at Cellebrite. His expertise spans modern enterprise defense, AI security governance, and scaling security and compliance architectures across hyper-growth tech environments.

"An agent is another identity, and you need to treat it as an identity. It's not a magic employee that can do anything for you or that has no restrictions. You have the same restrictions as any other user in the company," said Kozuch. Each agent acts for a person, and Kozuch limits it to what that person can already reach. After that, he manages it like any other identity in the company.

• Inherited permissions: An agent built at Navan receives the token of the user who created it and is authorized against that user's access. When someone asked to connect Workday to AI, Kozuch approved it on one condition: the agent could do only what the person building it could. He used his own permissions as the example. "If I build an agent and I give him almighty permissions, he can see everybody's salaries, which I as an executive in the company cannot see, I can only see my group," Kozuch said. "The idea is that we won't use an agent to bypass us or bypass other restrictions."

• An accountable owner: An agent that loses its creator either retires or transfers to another user and runs on the new user's token. Kozuch made the case for this rule with a thought experiment: a thousand people building agents then leaving would leave a thousand agents still running after them, at a cost he counted in money as well as risk. "If I created an agent and then decided to leave the organization, the agent will die with my identity, because it needs to be associated with someone," Kozuch said. "It's mainly a safeguard to make sure we won't end up with thousands of agents that no one knows."

Kozuch expects inherited permissions and accountable ownership to be tested from inside the company. An employee turned down for access can build an agent to do the job instead, and the agent would then have the access that person was refused. "We bypass the whole identity model and permission model," Kozuch explained. "Eventually you'll end up with a huge security debt, because agents are running everything. Agents can reach anything, agents can do anything, and those agents become one of the huge risks you're not really in control of."

• Reviews and approvals: Kozuch would put agent permissions through the same quarterly review as any other identity, and cut permissions that go unused back to what the agent requires. He expects thousands of agents to need a lot more automation, with some data getting a further gate on top of the review. "Accessing highly sensitive information will require more permissions, sometimes just-in-time access, even if it's an agent," Kozuch said. "Sometimes the admin of the data will need to approve you, even if you're an agent."

• One description per agent: Every agent has to say what it's for, and Kozuch wants his team checking behavior against it. As an example, he described an agent that was built to pull a job report and could instead move data out of a CRM and send it outside the company. "Each agent needs a description, because in many cases they're doing a lot of things," Kozuch noted. "If something happened, you want to make sure that your agent actually does what it was supposed to do, and no one managed to hijack the agent and reconfigure it."

Approving each integration on its own is only half the review at Navan. Kozuch runs a second pass across everything an agent would hold at once. Permissions that each look reasonable can combine into something he ultimately wouldn't approve. "We evaluate each integration by itself, and eventually we do all kinds of toxic combinations," Kozuch said. "It's not just about collecting permissions. It's about what you're actually trying to do, and making the right adjustments."

Kozuch treats AI oversight as a company-wide job, with security holding one part of it. He outlined a structure that includes an executive team sponsor and a committee under that sponsor where security, IT, DevOps, and engineering each own a piece. He also wants the steps spelled out, from risk evaluation and threat modeling to how long a review takes. "Eventually you need someone to own it," Kozuch concluded. "Once everybody understands the risk based on what exactly we're trying to do, then we can really move forward."