Risk-Adaptive Authorization for Hybrid Cloud IAM

Catching an attacker who has a real password

A research paper from my eighth semester, with a demo you can click through. It asks two things about every request. Is this account acting normally, and how much power would this action hand it? Then it allows, questions, or refuses. The paper is unpublished.

Read the paper (PDF)Open the demonstration Source on GitHub Read the write-up Back to projects

Unpublished research · eighth semester

Most cloud break-ins involve no breaking. The key works, the request is signed, and the command is one that normal deploy tools run every day. The real question is not whether the request is allowed, but how much it hands over and whether this account usually asks for it.

Role: Co-author with Ashal Pandey and Famous Dhungana. I wrote up the design and built the browser demo.
Organization: BSc CSIT eighth semester · Madan Bhandari Memorial College, Tribhuvan University
Live: Open the demonstration Source on GitHub

Built with

Next.js 16React 19

100: permissions in the model, worth 412 points of damage between them, of which the deploy account can already reach 12
3: things checked on every request, added up with the paper's starting weights of 0.4, 0.4 and 0.2
7: situations the demo runs, six attacks and one honest engineer doing the same privileged work
0: measurements. The tests described in the paper have not been run, so nothing on the page is a real-world result.

The key is real, the login is clean, and the account is quietly giving itself more power

An attacker with a stolen key does not break anything. They use it the way its owner would, taking one normal command at a time towards admin rights. Nothing looks wrong, because at the level the request is checked, nothing is wrong. The paper says one request actually tells you two separate things, and that both are worth reading before you say yes.

Is this account doing what it usually does, judged against its own past behaviour and not against everyone else's.

How much power would this one action give it, measured as the gap between what it can reach now and what it could reach afterwards.

A lighter third check on the situation, such as a strange location, an odd hour, or a jump from the office network into the cloud.

Three answers instead of two, because the interesting case is the request you want to question rather than block.

Watching behaviour alone and checking permissions alone fail on opposite cases

Watch behaviour alone and a patient attacker walks straight past you. After a few weeks of quiet activity they look normal, so the request that finally grants admin rights looks no stranger than the hundred harmless ones before it. Check permissions alone and you block the wrong person, because the engineer fixing an outage at night runs the very same command. Neither check can tell them apart. Together they can.

The patient attacker looks normal but asks for a big jump in power.

The engineer fixing something asks for the same jump, from an account that does this kind of work.

The middle answer, questioning the request, is what separates them at the moment it is made.

A machine account cannot answer a question like that. The paper covers this case, but not consistently, and that is written down rather than hidden.

One score, four levels, and a table that never goes easier on you

A broker sits in front of the cloud and sees every request. One check scores recent activity for how unusual it is, one works out how much more the account could reach if the request went through, weighted by how much damage each permission can do, and one looks at the situation around the request. The three are added with weights of 0.4, 0.4 and 0.2, the total lands in one of four levels at 0.35, 0.55 and 0.75, and that level is read against how sensitive the target is.

The table only gets stricter. A higher level, or a more sensitive target, never gives back an easier answer.

Requests against low-value targets are never refused outright, only questioned. That is a deliberate choice, not an oversight.

The weights and cut-off points are starting values from the paper. They were not tuned, and the work to replace them has not been done.

The design also has to survive its own parts failing. The demo can switch each one off and show what the answer falls back to, including the case where the broker is not the only way in and the whole thing protects nothing.

A demo that works the paper out rather than playing it back

The page runs entirely in the browser. There is no server, no database and no network calls once it loads. The model trains when the page first opens, and trains again if you change the settings behind it. Every number on the page can be adjusted, and one switch opens up the full working behind any answer, along with the permission map it came from.

A hundred permissions worth 412 points of damage, with the account rights, the wildcard rules and the reach worked out live rather than stored.

Seven situations, from a stolen key climbing towards admin rights, to the same climb done honestly, to an attack that looks harmless from either side on its own.

Every answer is also written in plain English, so the page still makes sense to someone who never opens the maths.

Four switches that break parts of the system on purpose and show what it costs, plus the four attacks it cannot catch at all.

The numbers check out without opening a browser

Two scripts run the same code from the command line. One checks the worked examples in the paper against the build, covering the permission count, the damage total, the twelve permissions the deploy account can reach, the four worked figures and the comparison between cut-down versions. It works each one out instead of comparing against a saved answer. The other prints every situation request by request, with each part of the score, the total, and the rule that decided it.

Building it turned up a contradiction between three parts of the paper about whether a machine account gets blocked instead of questioned. The demo makes that a labelled switch, and turning it off reproduces the paper exactly.

It also showed that the training data has to include honest privileged work. Without it, two of the checks almost never fire while training, and the honest engineer gets flagged.

And a rounding difference, 0.67 and 0.33 against exact thirds, which moves two figures in the third decimal place and changes no answers.

None of the three were visible while reading the paper. They showed up when it had to run.

What this does not prove

The paper is unpublished, nobody has reviewed it, and the tests it describes have not been run. There is no test setup behind it, no containers, no proxy, no stand-in cloud, so there is no timing figure of any kind. The speed tables are a plan with the results still empty, and they are published that way.

The example traffic was written by the same design it is testing. The paper says so in its own limits section, and the demo does not get around it.

Nothing on the page is measured, and the page says that at the top rather than at the bottom.

The accuracy figures, precision, recall and the rest, are defined and still empty.

Everything that depends on running the tests, which is most of what would be worth claiming, is still to do.