There's a thought from SailPoint Navigate 2026 that hasn't fully baked in my mind yet.
Many AI agents today inherit the permissions of the person who runs them, which is usually far more than the task needs. A cleaner model ties access to the job function: the agent gets what that function requires, and the human gets the right to work with that agent and that function.
The question I left Navigate with
A primary takeaway from the conference was simply that we need to manage both humans and non-human identities, including AI agents. Having spent over a decade as an identity practitioner, helping organizations grant least-privileged access automatically, I started to wonder whether we're approaching this the wrong way as an industry. Maybe we need to adjust our thinking.
To be fair, tying an agent to its human is the obvious default. It's simple, there's a clear owner, and it matches how delegated access already works. I just don't think it's the whole answer.
One person, many hats
GCA isn't an enterprise-sized organization, so many of us wear multiple hats. I might wear the blogger or marketer hat, as I am here. I'll wear the sales engineer hat and lead a demo. I'll wear the contracts hat and do a first-pass review of an agreement before it goes to counsel. In 2026, Claude is at my side helping with each of them.
My thought is that maybe the focus shouldn't be on what access I have and what access my AI agents have, but on what access the job function has: what access that particular hat needs. I think the architecture is cleaner, and it aligns better with modern reality.
As we continue on this AI journey, or more accurately, as AI drags companies along while we scramble to keep up, more and more of the human role will shift to AI oversight. Take writing a BeanShell rule in SailPoint IdentityIQ. For a decade, I was one of many on the team who wrote that code by hand, sometimes typing every character, more often grabbing snippets and piecing them together. Then I would manually deploy it to a lower environment, manually test it, and hand it to a peer to test. Today, that same code is more likely authored by Claude at my direction, tested by automated scripts Claude wrote, and reviewed by us humans, with an engineer still deciding what gets promoted and porting it by hand. We move much faster, and as the job shifts, I can see it continuing in the direction of humans as guides and supervisors.
In practice, with work getting done faster, I can wear more hats.
What an agent inherits today
Here's a concrete example. If I have an AI agent for my marketing function that inherits all of my permissions but is tuned to edit my blogs, why does it need access to our code repositories, which I have as a human for my other job functions?
Play it out side by side:
- Inherited from me: the blog, plus everything my other hats need: code repositories, agreements under review, demo environments, and anything else my account can open.
- Scoped to the marketing function: the blog and the images that go with it. Nothing else.
The agent didn't need more to do its job. It got more because it was attached to me. And if it misreads an instruction or follows a bad prompt, it can only damage what it can reach.
Scoping access to the job function
None of this is brand new, which I count in its favor. It builds on things identity teams already do:
- Job-function roles. Role-based access control already groups permissions by job function instead of by person, and it sits at the core of most identity governance programs. A hat is narrower and more fluid: one person may switch between several in an afternoon, and an agent can hold a hat without being a person at all.
- Delegated access. Standards such as OAuth 2.0 Token Exchange (RFC 8693) can already record who is acting and on whose behalf. The job-function model asks a different question: not whose rights the agent borrows, but which function's rights it was given.
- Just-in-time access. The industry has been moving toward granting privileged access only when it is needed and removing standing privilege. Putting on a hat is a natural trigger: access activates when I take on the work and falls away when I'm done.
Hats don't remove the governance work; they move it. Someone still has to decide what each hat contains, who may wear which hats, and whether two hats held by one person create a segregation-of-duties conflict, then review those decisions and catch any access an agent picked up outside a hat. Turning access on when a hat goes on is the provisioning half. That review is the governance half, and it has to move fast enough that people don't route around it.
So if we think about that shift toward just-in-time provisioning and removing standing privilege, wouldn't the best-aligned approach be to secure the job function? Instead of asking what privileges my AI agent inherits from me, maybe AI agents should have access tied to a job function, and I as a human should have the access to work with that agent and that function. Similarly, when I put on a specific hat, my access should be tied to the hat, and the hat tied to me.
To me, that is what AI agent access control should mean. It also reads closely to least privilege in NIST SP 800-53 Rev. 5 control AC-6, which limits users, and processes acting on their behalf, to the access needed for assigned organizational tasks. An agent's assigned task is its function, not its owner's whole job.
Getting there on purpose
I believe we're naturally headed toward this kind of model, and I offer it here as food for thought. Instead of stumbling our way into this shift in permission architecture, maybe we should get there with intention, using an Identity Practice Subscription to keep adjusting as the model matures.
A reasonable first step is knowing what your AI agents can reach today, and through whose account. The next is testing any new permission design somewhere a mistake is cheap before it touches production, which I wrote about in the Mojave Desert test for AI agents.