From LinkedIn · · 1 min
Permissions look like settings
Permissions don't look like decisions when you make them. They look like settings. What the next owner inherits is every grant, and almost none of the reasons behind it.
By Olha Shevchenko. Audits production systems on AWS and Node.js.
There is always one permission nobody can explain.
A service account with admin rights and a name from two CTOs ago. An API key nobody dares revoke because nobody knows what would stop working. A deploy role that can also read the customer database because, at some point, that was convenient.
They all had a reason. Permissions don't look like decisions when you make them. They look like settings. So nobody records the reasoning.
Then the product grows. The team changes. The threat model changes. The person who made the decision leaves. The permission stays. It does not expire when its justification does.
That is what the next owner inherits: every grant, and almost none of the reasons behind it.
Not an access model. More like sediment. Years of decisions that made sense locally, still enforced perfectly by systems that have no idea why they exist.
The logs start after the decision. They can show when a key was used, when a role was assumed, and what happened next. They cannot tell you why the access exists or whether it is still needed.
In a technical review, "is this permission correct?" is too small a question. I want to know why it exists, what depends on it, and whether it can be removed without discovering the answer in production.
If nobody knows what breaks, revoking it is not remediation. It is an outage test.
A forgotten permission doesn't have to break to become a risk.
It just has to keep working.