If you ask a software security auditor what they are looking for, you will often get the same two things: how long each person has had access to data, and when they last used that access. Why those two? Because somewhere in every enterprise, there is a profile with access granted for a project that ended two years ago, sitting untouched and vulnerable.
That was, and is, the sorry state of enterprise permissions long before anyone pointed an AI agent at sensitive data.
I believe that permissions in Enterprise Apps are bankrupt. I am not going to sugarcoat it, and I am not saying anything a working admin doesn't already know. If you try to solve access by adding profiles and permission sets, it never scales. You end up granting more than someone actually needs, or less than they need to actually get their job done.
It is always broken, and nobody is ever happy. Security is unhappy because too much is granted. The business is unhappy because somebody is constantly mucking around with access or holding back a project because they can’t do what they need to.
Tighten, loosen, exception, exception, exception…and what you are left with is security Swiss cheese: anything can walk right through it.
Now you’re adding AI in, and it gets even scarier (yes, we security people have a flair for the dramatic). Security teams are being pushed to move faster, and more often than not they are being asked to accept a less secure solution to do it.
The current view in the industry is that your AI should mirror the access people already have in the source system. But the source system is already broken. People have too much access for too long, and mirroring that just moves the problem somewhere else; it can cause huge problems, even faster.
It’s worth being precise about where the risk actually is, because the problem is not the agent itself. A well-written agent can be often predictable: it reads one table, at one time, and moves that data to one place. Human beings are the unpredictable ones. You don't know what somebody is going to do today, never mind tomorrow. The real problem is that an application isn't smart enough to know the user shouldn’t have that specific access in the first place.
I am living in the thick of this problem, not just observing it.
Whirl reads configuration data from customer systems today, and to help them be even more productive, we do need occasional access to the business data that actually runs the business.
When I take that ask to a security team, I know exactly how it sounds, because I spent most of the last 30 years on their side of it. If any vendor brought me that request at Snowflake, it would not have sat well with me either.
So the conversation I have started having is a completely different one. We can stop arguing about how much access somebody has, and start asking how long they have it, and what for.
Let’s say one user is not on the finance team but needs financial data for a project. The conventional move is to build her a profile and start subtracting permissions. The alternative I am pushing for is to give her access to everything that project requires, tied to a Jira, Linear, or Salesforce ticket that says, “this is approved, and this is why,” for five days or ten days or whatever the work takes. There is a trail of what was done with that access.
When the time is up, the access comes off.
If she needs five more days, she asks, it gets approved, and the trail continues.
Security people can and should be more comfortable granting deeper access when it is time-bound, documented, and approved in the right place.
Every enterprise already runs this model somewhere. Nobody at a public company can touch financial data in the days before earnings are published, and the second it is public, they can. That is temporal access with context, and it works.
Whirl is not fully there yet, but we’re working on it.
It is where I think this has to go, and it is buildable for us because a customer's deployment belongs to that customer: it is not a multi-tenant environment. It is theirs, which is why we can offer visibility and controls that are genuinely configurable rather than a policy statement.
Almost nobody is talking about the time dimension of access right now.
But that is the conversation I want to be having, and we all should be having.