Your enterprise software security is Swiss cheese

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. 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. Tighten, loosen, exception, exception, exception…and what you are left with is security Swiss cheese: anything can walk right through it.

Mirroring a broken system

Now you're adding AI in, and it gets even scarier. 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'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. 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.

The answer is temporal access systems

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 alternative I am pushing for is to give her access to everything that project requires, tied to a ticket that says, "this is approved, and this is why," for five days or ten days or whatever the work takes. When the time is up, the access comes off.

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 buildable for us because a customer's deployment belongs to that customer: it is not a multi-tenant environment.

Learn more about our view on security