It's possible to turn that second thing into a sort of "risk score" but it's very hard and a model is going to potentially be better at it.
Heck, many websites I visit on the web cannot understand why I, a Ghanaian living in Ghana, might be interested in the service offered or the information therein. I am sometimes blocked for no good reason.
If you are in a third world country, the web is extra hostile. This is going make things worse.
Plenty of US websites are blocking access from EU IP addresses because of our data protection laws.
Local news companies are the biggest offenders in this regard.
Isn't this for enterprises managing access to corporate resources?
I don't think once this is established in enterprises it is going to stop there.
I can't wait to fill out a form describing why I want to do something I have permission to do but the AutoBureaucrat5000 says no anyway.
Okay, but that's why there are always loud "breakglass" escalation options for access.
> that would hopefully be an auto-deny anyway until someone on-site whitelists their IP
About as far from "zero trust" as any solution could be.
This reads to me to be more for continuous behavioral monitoring once the access is gained via the deterministic controls. You wouldn't leave "Can person X access resource Y" up to the AI model, that's already decided based on the existing rules. Where the model comes in is "Is person X behaving in an expected way while using resource Y." Like, downloading a bunch of data when they've never done that before, might get flagged for either a session revocation, or a human review, or prompt for additional authentication, etc.
Even if the middle is deterministic, if one end is just going to be lazily hooked up to an AI, it's the shitty dystopian future.
What will really happen: You can’t really perform your work, so you are slower than others, so they fire you based on bad performance.
Horrible startup idea: Discrimination as a service, by means of IA without pretending it’s IA.
Let's say I had a promotion, who changes my title in the system, who changes my responsibilities and my place in the org chart, more importantly, will they do it or is <HR_NAME_HERE> on leave and forgot? those are data points required by the agent to determine if I'm "good enough" to access a certain resource.
What if... someone spoofed my address and did a flood in one of the resources that are lateral to what I'm allowed to access (let's say I don't have access to company sales but I do to department sales and the attacker floods company sales with requests under my address), would the AI determine that I'm a high-threat actor and not allow me to access legitimate files going forward?
Will exceptions be made by humans? In which case we go back to human-managed permissions.
Sorry, I might be barking up the wrong tree but I think these are questions that are not meant to be solved during implementation. And they add to what @firasd said about legitimate-but-odd behaviour
So yeah you're right in that it does add more probabilistic randomness just by virtue of changing the boundary of when the permission gate kicks in
In Entra where I work we already check things like "Is this person on a managed device? Is it compliant? Where are they? What MFA methods do they have registered/did they use?" on top of existing RBAC, etc. and its continuously evaluated. Entra watches for leaked passwords, assigns risk scores, etc. and you can make access decisions based on user risk or sign in risk, force password changes, require different MFA methods depending on the resource and the risk level, etc.
"Should this API call on this resource be allowed right now?" is mostly already determined by the above.
Where I see adding AI into the evaluation is to watch for unusual behavior that's not picked up by the deterministic signals. "Alice is trying to download gigs worth of data from the company file share, however she has never done that in the past, and there hasn't been any recent role/job changes" and so the LLM flags it or denies the request, or pushes it for a human approver, etc.